Why MXroute Doesn’t Globally Reject DMARC Failures

There’s a question that pops up maybe once a year, and I do mean that literally. Someone asks why we don’t globally reject emails that fail DMARC checks. It’s a fair question. After all, DMARC exists to protect domain owners from spoofing, and on the surface, rejecting failures sounds like the responsible thing to do.

But the reality of running a large-scale email service means balancing good intentions with operational truth. So here’s the short version, followed by the long one:

We don’t globally reject DMARC failures because it would cause far more problems than it would solve.

SPF: Yes. DMARC: Not So Fast.

MXroute already rejects mail that fails a hard SPF check. That’s a line I’m willing to draw. SPF is simple. There’s no ambiguity.

DMARC is a different beast. It layers policy enforcement on top of SPF and DKIM, but when it comes to forwarding, it often breaks. That’s not because anything is wrong with the sender. It’s because forwarding changes the path of the email. The SPF fails because the forwarding host is not in the sender’s SPF list. By focusing on the From header, it invalidates SRS which is a great feature that was designed to fix this. DKIM fails if the message is modified in transit. DMARC fails because one or both of those failed. This happens all the time, and it’s expected behavior.

Strict DMARC enforcement turns email forwarding into a problem, and that’s not something I’m interested in doing to our customers.

Let’s Talk Real Numbers

The number of customers who ask us to enforce DMARC strictly? Roughly one per year. And I’m being generous there.

The number of customers who use some kind of email forwarding where DMARC would break? Easily thousands. These people aren’t doing anything wrong. They’re using email in a normal, expected way.

So we’re not going to disrupt all of that for a feature one person a year might care about. Google's strict DMARC enforcement is handled in an excellent way, by offering zero support so users can either just suck it up or leave. This is not something we intend to emulate.

Will We Ever Offer It?

Probably. One day I may add a toggle that lets customers enable strict DMARC enforcement on their own domains. If someone wants to reject DMARC failures for their domain, I won’t stand in the way. But it’s not a priority. I have no intention of putting time into building UI for a feature that would only be used by a tiny fraction of customers, and even then, would generate complaints because half of the users that enable it wouldn't understand the implications.

Bottom Line

MXroute is built for reliability and practicality. That means we make decisions that work for the majority and avoid breaking email for the sake of a checkbox. Rejecting hard SPF fails is a useful boundary. Rejecting DMARC failures across the board is not.

That’s not going to change.