Sending DMARC reports is somewhat hazardous | Hacker News Reader

Sending DMARC reports is somewhat hazardous

utcc.utoronto.ca

76 pointszdw29 comments

DMARC is a relatively recent addition to the email security space, and while it seems a bit superfluous at first, is actually quite useful! Sending and receiving the reports (which, should be noted, is entirely optional) might indeed be helped by a setup separate from the main mail handling workflow, as the 'best effort' nature and the fact that lots of systems sending DMARC reports have no business delivering mail for the sender domain in the first place are quite distinct.

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...

Both Microsoft and Google seem to do it just fine

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.

Same here, and the worst part is the duplicates appear to reuse the same Message-id, which confuses macOS Mail.app to no end :-/

>which, should be noted, is entirely optional

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.

That's interesting! Can you share which provider their MX record pointed to? Silently disappearing emails are typical Microsoft Forefront antics (but definitely also a misfeature of other products), but mostly when the originating domain has a p=reject DMARC policy. You didn't happen to relax that at the same time you added the reporting parameters?

But once your DMARC, DKIM & SPF is configured correctly, there should be no reason for an MTA to reject your mail due to DMARC, right? I have DMARC reporting turned on, but am considering turning it off.

Back when I ran email for a large sender, I turned DMARC reports off once I got things settled in, and might turn it on to debug issues.

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.

> Both Microsoft and Google seem to do it just fine

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.

Yeah, there is a whole layer of Rube Goldberg-esque nonsense between the public Microsoft SMTP servers and the actual destinations that not even the highest levels of their support seem to properly understand.

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...

It's been pretty mainstream since 2012 IIRC.

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 also don't see why the DMARC reporting would retry sending. If the receiver isn't receiving right away, surely it's okay to just drop that report to keep the queue small.

We already had 'low effort' mail queues (for things like password reset emails: these are retried 1/2/4/8 minutes apart and don't generate bounces, other than an API flag and a metrics record), to which we added 'least effort' for DMARC reports. Retry once, then forget about the entire thing other than incrementing a counter for the destination domain.

> retried 1/2/4/8 Minuten apart

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:

https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.4

SHOULD is not MUST. These capitalized terms are have very specific meanings in RFCs, see RFC https://datatracker.ietf.org/doc/html/rfc2119. SHOULD is:

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.

> the retry interval should be at least 30 minutes, while the give-up time needs to be at least 4–5 days

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 do operate DMARC report processing service and I have to agree that outdated reporting addresses living in DNS records (in my case, previous customers of mine still using their reporting addresses) are an issue.

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-...

Do DMARC report tools like opendmarc-reports [0] comply with that section? Which tool have you seen that complies?

[0]: https://github.com/nabbar/opendmarc-reports

To the best of my knowledge opendmarc-reports does not perform a DNS check for external auth, but I might be mistaken.

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.

Receiving DMARC reports is just as hazardous. I frequently receive spam, phishing, malware, etc on my DMARC reporting addresses. I'm somewhat surprised I haven't seen any zip-bombs in DMARC reports yet.

Rejecting DMARC reports from any sender that doesn't have a correct SPF/DKIM/DMARC setup is the bare minimum.

Google's DMARC report's seem just fine. Microsoft's DMARC reports routinely report broken delivery, BUT the breakage is on their end. They forward to a custom domain, then their DMARC report says, look your email is broken. It is SO frustrating.

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.

>I assume that putting a 'rua=' into your DMARC record makes it look more legitimate to (some) receiving systems.

Yes, Gmail for example will drop emails from mass-senders that don't implement both SPF and DKIM.

Still the 'r' parameters (reporting) in the DMARC record are optional, and there is no indication their presence bestows additional legitimacy to a sender.

(For me, it's sort-of the opposite: there are fun spam patterns to be found in DMARC records with reporting addresses!)

> that don't implement both SPF and DKIM

I don't see how that's related at all to specifying report addresses in the DMARC record.

Having worked in IT for decades sending millions of emails into an the major inbox providers I can say that unless your brand is being targeted by a coordinated campaign, spending the time to set up processing of both the transaction and forensic emails isn't worth the effort. If you are a smaller shop, consider not spending a great deal of time on it until you actually need it.

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.

I keep getting e-mails containing a ZIP file with subject lines like:

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

They're not zip files. They're gzipped XML files. Some shitty email programs will try to open them as ZIP files, fail, and then claim they're empty.

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 add to jeroenhd's comment, if you're only sending mail from a single server (e.g., you are using a custom domain with Proton Mail, Zoho, etc.), then you probably don't need DMARC reports at all.

To avoid them, you can remove the `rua` or `ruf` tags from your DMARC DNS record.

Thanks for reminding me and looking into DMARC. I removed rua and only left ruf, such that I will only get reports about failing e-mails (not likely). The aggregate reports are useless for my small domain with effectively one e-mail.

I have strict and separate emails for aggregate and forensic. If it’s too much trouble setting it up on your server with all those spammers and borked entries you have my blessing.

Reply on news.ycombinator.com