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...
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.
Rejecting DMARC reports from any sender that doesn't have a correct SPF/DKIM/DMARC setup is the bare minimum.
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.
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-...
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
Yes, Gmail for example will drop emails from mass-senders that don't implement both SPF and DKIM.
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.
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.
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.
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.
I don't see how that's related at all to specifying report addresses in the DMARC record.
(For me, it's sort-of the opposite: there are fun spam patterns to be found in DMARC records with reporting addresses!)
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...
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.
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:
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.
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.
December 2, 2025
DMARC has a feature where you can request that other mail systems send you aggregate reports about the DMARC results that they observed for email claiming to be from you. If you're a large institution with a sprawling, complex, multi-party mail environment and you're considering trying to make your DMARC policy stricter, it's very useful to get as many DMARC reports from as many people as possible. Especially, 'you' (in a broad sense) probably want to get as much information from mail systems run by sub-units as possible, and if you're a sub-unit, you want to report DMARC information up to the organization so they have as much visibility into what's going on as possible.
In related news, I've been looking into making our mail system send out DMARC reports, and I had what was in retrospect a predictable learning experience:
Today's discovery: if you want to helpfully send out DMARC reports to people who ask for them and you operate even a moderate sized email system, you're going to need to use a dedicated sending server and you probably don't want to. Because a) you'll be sending a lot of email messages and b) a lot of them will bounce because people's DMARC records are inaccurate and c) a decent number of them will camp out in your mail queue because see b, they're trying to go to non-responsive hosts.
Really, all of this DMARC reporting nonsense was predictable from first (Internet) principles, but I didn't think about it and was just optimistic when I turned our reporting on for local reasons. Of course people are going to screw up their DMARC reporting information (or for spammers, just make it up), they screw everything up and DMARC data will be no exception.
(Or they take systems and email addresses out of service without updating their DMARC records.)
If you operate even a somewhat modest email system that gets a wide variety of email, as we do, it doesn't take very long to receive email from hundreds of From: domains that have DMARC records in DNS that request reports. When you generate your DMARC reports (whether once a day or more often), you'll send out hundreds of email messages to those report addresses. If you send them through your regular outgoing email system, you'll have a sudden influx of a lot of messages and you may trigger any anti-flood ratelimits you have. Once your reporting system has upended those hundreds of reports into your mail system, your mail system has to process through them; some of them will be delivered promptly, some of them will bounce (either directly or inside the remote mail system you hand them off to), and some of them will be theoretically destined for (currently) non-responsive hosts and thus will clog up your mail queue with repeated delivery attempts. If you're sending these reports through a general purpose mail system, your mail queue probably has a long timeout for stalled email, which is not really what you want in this case; your DMARC reports are more like 'best effort one time delivery attempt and then throw the message away' email. If this report doesn't get through and the issue is transient, you'll keep getting email with that From: domain and eventually one of your reports will go through. DMARC reports are definitely not 'gotta deliver them all' email.
So in my view, you're almost certainly going to have to be selective about what domains you send DMARC reports for. If you're considering this and you can, it may help to trawl your logs to see what domains are failing DMARC checks and pick out the ones you care about (such as, say, your organization's overall domain or domains). It's somewhat useful to report even successful DMARC results (where the email passes DMARC checks), but if you're considering acting on DMARC results, it's important to get false negatives fixed. If you want to send DMARC reports to everyone, you'll want to set up a custom mail system, perhaps on the DMARC local machine, which blasts everything out, efficiently handles potentially large queues and fast submission rates, and discards queued messages quickly (and obviously doesn't send you any bounces).
(Sending through a completely separate mail system also avoids the possibility that someone will decide to put your regular system on a blocklist because of your high rate of DMARC report email.)
PS: Some of those hundreds of From: domains with DMARC records that request reports will be spammer domains; I assume that putting a 'rua=' into your DMARC record makes it look more legitimate to (some) receiving systems. Spammers sending from their own domains can DKIM sign their messages, but having working reporting addresses requires extra work and extra exposure. And of course spammers often rotate through domains rapidly.