This is the only one your having issues with? My queues are filled with
dmarc@ and abuse@ report messages that finally timeout or get denied
because the users don't exist, the mailbox is full, on and on and on. At
first I would reach out to postmaster@ and other management addresses,
but in a lot of cases those don't exist either, or the mailbox is full,
or something else, on and on and on. So now I have a generic zone file
that is _dmarc for the domain without an rua, and I point _dmarc.<domain
name> to this file as authoritative so I don't send them anything since
they don't want it.
David
--
https://dprall.net
On 5/17/2026 1:16 PM, Dan Mahoney via mailop wrote:
Hey folks,
I'm doing a lot of work on cleaning up openDMARC's reporting (we've been
behind, I know, but with a DMARCbis RFC close to drop, the code needs some love)
Anyway I've seen some interesting misconfigurations -- to the point that I'm
both considering adding a backoff delay to the DMARC reporting scripts (which
would be triggered via a VERP-like tool), and also...surveying the top 1M
domains for obvious misconfigures (which wouldn't necessarily spot this).
With Big Mailbox now requiring DMARC, lots of people are going to various dmarc
record generators, pasting stuff in their DNS, and not following through on the
rest of the requirements.
Here's one:
* Wayfair (a big etailer who ostensibly sends lots of mail) has an rua address. It's
[email protected] <mailto:[email protected]>
_dmarc.wayfair.com. 1800 IN TXT "v=DMARC1; p=quarantine;
rua=mailto:[email protected]; fo=1; pct=100; adkim=r; aspf=r"
* They have proofpoint in front of their mailer:
wayfair.com. 1800 IN MX 10
mxa-00180701.gslb.pphosted.com.
wayfair.com. 1800 IN MX 10
mxb-00180701.gslb.pphosted.com.
* When I send reports to them, proofpoint accepts all the messages, and
internally routes it to...a gmail box. Not sure what you're doing with those
[wait for it], but there are LOTS of services you can put in your RUA/RUF
fields that can handle this for you and put it in a nice dashboard and help you
act on it. (Dmarcian, valimail, etc).
But also:
A) proofpoint is blasting the gmail box so hard that the backoff delay is
sending errors to me
And B) proofpoint ignores google's 45x series error and continues trying to
send in the same SMTP connection so they also get 500-series errors.
And C) Somewhere in this lunatic chain reports:
550 5.1.1 <[email protected]>... User unknown. So not only are wayfair routing
their reports to a gmail box, they're routing it to one they never set up.
(slow clap)
Gmail (masters of "do weird black-boxy stuff") could totally detect DMARC
messages and exempt them from the filter, or perhaps query the _dmarc records from their
hosted zones and learn from this. Or maybe they could have their FIRST MTA report
user-unknown before it does all the rate-limiting?
And, bonus, I get longer reports because proofpoint tries all six of the
internal gmail mxes, with mixed 45X and 50X responses.
... while talking to alt1.aspmx.l.google.com.:
DATA
<<< 450-4.2.1 The user you are trying to contact is receiving mail at a rate
that
<<< 450-4.2.1 prevents additional messages from being delivered. Please resend
your
<<< 450-4.2.1 message at a later time. If the user is able to receive mail at
that
<<< 450-4.2.1 time, your message will be delivered. For more information, go to
<<< 450 4.2.1 https://support.google.com/mail/?p=ReceivingRate
46e09a7af769-7e55b801ff8si5191570a34.44 - gsmtp
<[email protected]>... Deferred: 450-4.2.1 The user you are trying to contact
is receiving mail at a rate that
<<< 503-5.5.1 RCPT first. A mail transaction protocol command was issued out of
<<< 503-5.5.1 sequence. For more information, go to
<<< 503-5.5.1 https://support.google.com/a/answer/3221692 and review RFC 5321
<<< 503 5.5.1 specifications. 46e09a7af769-7e55b801ff8si5191570a34.44 - gsmtp
... while talking to alt2.aspmx.l.google.com.:
DATA
<<< 450-4.2.1 The user you are trying to contact is receiving mail at a rate
that
<<< 450-4.2.1 prevents additional messages from being delivered. Please resend
your
<<< 450-4.2.1 message at a later time. If the user is able to receive mail at
that
<<< 450-4.2.1 time, your message will be delivered. For more information, go to
<<< 450 4.2.1 https://support.google.com/mail/?p=ReceivingRate
46e09a7af769-7e55bbdbd9csi5088545a34.77 - gsmtp
<[email protected]>... Deferred: 450-4.2.1 The user you are trying to contact
is receiving mail at a rate that
<<< 503-5.5.1 RCPT first. A mail transaction protocol command was issued out of
<<< 503-5.5.1 sequence. For more information, go to
<<< 503-5.5.1 https://support.google.com/a/answer/3221692 and review RFC 5321
<<< 503 5.5.1 specifications. 46e09a7af769-7e55bbdbd9csi5088545a34.77 - gsmtp
... while talking to alt3.aspmx.l.google.com.:
Full email at https://www.gushi.org/ppemail.txt (will not persist forever).
Reach out to me if you need more debugging info.
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
