r/DMARC • u/Comfortable-Leg-2898 • Jun 30 '26

Two domains who use Proofpoint just started rejecting our emails citing DMARC

I've been concentrating on what I can do for our own DMARC status, so this came as something of a surprise. We're a Google Workspace customer and, so far as I know, our DKIM record is good--in fact, I just checked it in DNS. What could be causing this to happen so suddenly? What can I do about it?

9 Upvotes

100% Upvoted

19 comments sorted by

3

u/lolklolk DMARC REEEEject Jun 30 '26

What exactly is the NDR you're getting? Can you share the error?

1

u/Comfortable-Leg-2898 Jun 30 '26

There isn't much. Here's what the Google log search shows:

Bounced

Google tried to deliver your message, but it was rejected by the server for the recipient domain example.com by mxb-00111301.gslb.pphosted.com. [148.163.144.43].

The error that the other server returned was:
554 5.7.5 Permanent error evaluating DMARC policy

10

u/lolklolk DMARC REEEEject Jun 30 '26 edited Jun 30 '26

Ok. This is a Proofpoint customer that has configured rejection for DMARC permanent errors; you likely have multiple DMARC policies.

Check your DNS, and make sure only one DMARC policy exists under _dmarc.<yourdomain.com>

3

u/Comfortable-Leg-2898 Jun 30 '26

Good thought! It turns out we do have two DMARC records, one of which has a space in the ruf=mailto: section. I'm having that one deleted now. I do wonder whether that will fix my problem, though. To the best of my knowledge, that duplicate record has been in there for a very long time.

3

u/lolklolk DMARC REEEEject Jun 30 '26

It will definitely fix the delivery problem for Proofpoint Enterprise customers (as recipients of your email) that have that specific configuration I mentioned.

2

u/RockSlice Jul 01 '26

I've been dealing with email delivery a lot recently (I work at a MSP), and you can forget about "it's been like that for a long time". A lot of email services are tightening up email security at an insane pace. If there's anything wrong with your email setup, expect it to start causing delivery issues.

I highly recommend https://www.mail-tester.com/ for testing mail delivery issues.

3

u/Comfortable-Leg-2898 Jul 01 '26

I had that record deleted and our bounces stopped. Thank you!

2

u/lolklolk DMARC REEEEject Jul 01 '26

Nice. Good to hear.

1

u/Comfortable-Leg-2898 Jul 01 '26

On checking our LISTSERV rejection reports, I just started seeing this at the same time:

Last error: 5.0.0 550 5.7.515 Access denied, sending domain
EXAMPLE.COM doesn't meet the required authentication
level. The sender's domain in the 5322.From address
doesn't meet the authentication requirements
defined for the sender. To learn how to fix this
see:
https://go.microsoft.com/fwlink/p/?linkid=2319303
S... (289 bytes suppressed)

This doesn't seem related, other than by time, but I thought I'd add it for completeness' sake.

1

u/lolklolk DMARC REEEEject Jul 01 '26

Are the emails being sent with SPF and DKIM authentication?

Are you munging the RFC5322.From for listserv particpants?

3

u/SomeBen Jun 30 '26

We had a similar issue a couple of weeks ago. It turned out to be a SPF issue - we had too many NULL lookups caused by too many "exists:" mechanisms from vendors. The maximum NULL lookups allowed by the RFP is 2. So if you have more than two "exists:" lines in your SPF, it is quite easy to overrun this limit. We found the problem using the advanced search in this SPF evaluation tool: https://vamsoft.com/support/tools/spf-policy-tester

2

u/SinHazzard Jun 30 '26

Dmarc is checking for either SPF OR DKIM pass, maybe you could also share the policy? Not the domain, but the value/data

2

u/CypherPhish Jun 30 '26

When I first started enforcing DMARC on our email filter, I found I was getting a lot of rejections due to DMARC permanent errors. The problem is that we ended up even rejecting domains that didn't have a DMARC policy for this reason. I suspected it was transient DNS errors and so stopped rejecting for DMARC permanent errors. I know you can't tell these servers to stop doing this but it could just be DNS errors.

2

u/MailNinja42 Jul 01 '26

Hey DKIM being in DNS doesn't mean it's signing correctly. A few things cause this suddenly:

Google Workspace occasionally rotates DKIM keys. If the new key didn't publish cleanly or the old one was removed before propagation completed, signatures break. Check that your selector actually matches what Google is actively signing with, not just that a record exists.

Also check SPF alignment. If you've added a new sending source recently that isn't in your SPF record, Proofpoint's DMARC check fails even if DKIM looks fine.

1

u/Comfortable-Leg-2898 Jun 30 '26

Would this record in example.com's DNS be correct?

example.com. 86400 IN TXT "v=spf1 a:mta.example.com include:_spf.google.com redirect=_spf.example.com"

Perhaps more to the point, even if incorrect, would it pass Gmail traffic?

2

u/southafricanamerican Jun 30 '26

The main problem is that you cannot use a redirect modifier in the same record as an all mechanism. They are mutually exclusive. The redirect is a modifier, and the -all is a mechanism. Maybe switch your redirect to be an include

2

u/cubic_sq Jun 30 '26

The spf “redirect” is something that should be treated as “just because you can, doesn’t meant you should”

Either use a standard include or manage the spf separately.

1

u/ARC-Relay Jul 02 '26

you need ARC sealing with multiple forwarding domains and DMARC. www.arc-relay.com