Both Microsoft and Google seem to do it just fine using their main infrastructure though, so there's that. And apart from (performing or hopefully kickstarting) troubleshooting of SPF and (especially) DKIM failures, going through the forensic reports (which not everyone sends, even if they do summaries, due to message privacy concerns) will definitely satisfy your 'WTF-quota' for the day, since you get to see some spoofed messages that are usually just blackholed, and some of those are truly bizarre...
That's generally not very clever, as it will impose an unneeded burden on a receiving server which actually has temporary resource problems, and it will collide with greylisting, for example.
RFC 5321 states in section "4.5.4.1. Sending Strategy" that the retry interval should be at least 30 minutes, while the give-up time needs to be at least 4–5 days:
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
MUST is a requirement. You left out the "however" part:
In general, the retry interval SHOULD be at least 30 minutes; however, more sophisticated and variable strategies will be beneficial when the SMTP client can determine the reason for non-delivery.
There's absolutely nothing wrong with a fine tuned backoff. I am not saying the specific backoff discussed by GP is best, merely that 30 minutes is absolutely not a requirement, and in fact, discussed in tandem with the fact that "more sophisticated strategies" are actually beneficial.
The RFC does not agree with you. Partially quoted as you have, does not help.
RFCs have very little to do anymore with the realities of email delivery. And advocating for password reset emails to only be retried after 30 minutes (all while the user is manically mashing the 'resend link' button) and/or to be kept around for 5 days (while the link contained therein expires after an hour) doesn't either.
I routinely get between 5 and 10 duplicates of DMARC reports from Google for gmail. Searching on this, it's a known phenomenon. No one else has this issue. I don't get dupes from outlook.com, hotmail, yahoo, etc, etc.
But it's Google. Fairly typical for their modern quality control and engineering practices. I view them as a little like when Volkswagen stopped being run by engineers, and instead by accountants.
I wouldn't say entirely. I had a client with a large company contact me on LinkedIn saying that they wanted to buy my product but no one would respond to their emails. Their system was nuking my responses until I set up DMARC reporting, and I had no indication it was happening on my end. No "failed to deliver" message and nothing in the logs, just email that vanished into the ether.
There was nothing to do about the reports most of the time. Just get mad that people are accepting spoofed mail that fails DKIM and SPF.
But mostly, the phishing campaigns with our branding just stopped spoofing addresses. Turns out, lots of email clients don't show the sender address and people who get a phishing email about Service Y from info@johnsplumbingservices.example.com may get phished.
Microsoft sends me DMARC reports saying "yes, everything was accepted 100%, all good". The delivery logs on our end look good as well. However, they silently drop a large portion of messages with a Hotmail destination.
Like: if you truly want to ensure delivery to an Office 365 tenant, EWS is pretty much the only option. Anything else will have random gaps, even after the tenant themselves have begged everyone they could find to let that particular sender, domain, IP, and everything through no matter what...
The article is correct though. Microsoft has never done it just fine. Their reports are constantly interrupted and at one point it lasted years. Microsoft also wasn't following spec on handling DMARC rules and would take failed messages with a reject policy that should have been dropped and then put them in the spam folder, creating massive phishing risk. I believe they have finally started to get their act straight but for a long time they were the biggest problem in the space.
Google has usually been one of the leaders in the DMARC space though. Yahoo too.
Yes, Gmail for example will drop emails from mass-senders that don't implement both SPF and DKIM.
(For me, it's sort-of the opposite: there are fun spam patterns to be found in DMARC records with reporting addresses!)
I don't see how that's related at all to specifying report addresses in the DMARC record.
Rejecting DMARC reports from any sender that doesn't have a correct SPF/DKIM/DMARC setup is the bare minimum.
Although the RFC 7.1 section regarding External Domain Validation [1] addresses this topic, I've found that lots of final hosts disregard this step and blast their reports to whatever reporting address is provided.
1: https://www.dmarctrust.com/email-dns/fundamentals/dmarc-dns-...
Major hosts (Google, Zoho, Yahoo, Microsoft) are checking for sure. Japanese hosts are the worst offenders. I will try to do a proper data extraction and report back.
Dmarc Aggregate Report Domain: {mydomain.com} Submitter: {Amazon SES} Date: {2025-11-16}
From postmaster@amazonses.com
Nothing in the body, no idea idea what they are. I've always assumed malware, so left them untouched. But if anyone can enlighten me, I'd be grateful
Amazon sends these when you or someone pretending to be you sends email to Amazon's domain.
They contain the DMARC report you asked for.
To avoid them, you can remove the `rua` or `ruf` tags from your DMARC DNS record.
That being said, when I had some IPv4/IPv6 trouble on the email server, I did get good reports that helped my discover, diagnose, and fix the problem. So I like DMARC reports. Microsoft's support of custom domains appear to be lacking to say the least.
Edit to say if sending to Gmail recipients take the time to set up the free Postmaster tools provided by Google to give you the ability to keep an eye on both IP and domain reputation and use "good" content email streams on your lower reputation IPs to bring them back into acceptable ranges while moving transactional emails around to avoid watering down remarks email streams with high-engagement content.