A consortium of companies including Google, Microsoft, Facebook and Paypal have announced that they were collaborating and coming up with a new protocol known as DMARC—the Domain-based Message Authentication, Reporting and Conformance.

What is DMARC?

This is very much a summary of DMARC in a nutshell (I will probably write an article about this in the future), but from the website:

A DMARC policy allows a sender to indicate that their emails are protected by SPF and/or DKIM, and tells a receiver what to do if neither of those authentication methods passes—such as junk or reject the message. DMARC removes guesswork from the receiver’s handling of these failed messages, limiting or eliminating the user’s exposure to potentially fraudulent & harmful messages. DMARC also provides a way for the email receiver to report back to the sender about messages that pass and/or fail DMARC evaluation.

When I first heard about DMARC, I said to myself “Self, why do we need another email authentication protocol?” The answer is that DMARC is not another protocol but instead leverages existing email authentication protocols and provides feedback to the spoofed domain.

SPF already provides a way to say: “If this message fails an SPF check, discard the message.” It’s called a Hard Fail. However, not all hard fails are illegitimate (there are significant false positives with SPF). DKIM, in itself, doesn’t provide a way to discard a message if it fails an authentication check. This makes it less useful in securing the Internet (i.e., it is a barrier to adoption).

Besides which, what happens if an SPF check asses but a DKIM check doesn’t? And if one of them fails, who should you tell? DMARC provides a mechanism that says: “If one of these checks fails, discard the message.” But furthermore, it also provides a way to tell the responsible party that the message failed a check. For example, if [email protected] fails a DMARC check (either through SPF or DKIM), the email receiver can send the message to an email address that says “Hey, this message failed an SPF check. Was it legitimate or not?” If it is a false positive (perhaps a new server brought online), Paypal can add it to its SPF check. If it’s a phishing message, Paypal can investigate to have the website taken down.

The strength of DMARC is that it is a stronger way to protect a brand from being abused; receivers can discard spoofed messages and senders can figure out just who, exactly, is sending mail as them.

The weak point of DMARC is, unfortunately, the weak point of SPF and DKIM—spammers and phishers don’t need to spoof a domain in order to fool users into taking action. If a spammer sends mail from [email protected] (a fictitious domain), many users just see that first part (paypal.com) without being more aware that there is more to the message.

And if a phisher signs up for a cloud service that issues temporary credentials, they can create the account paypale.onmicrosoft.com and send spam from there to avoid IP reputation blocking (and to the spammer that is abusing our Office 365 service, we know what you’re doing, you jackass) while hijacking the reputation of another brand in the From address.

The strength of DMARC is not so much that it combats phishing but that if a good domain is authenticated, mail user agents (like Gmail, Hotmail, Outlook, etc) can highlight that the sender is a trusted sender and highlight it in blue or put a little icon beside it. Since users use visual clues to make heuristic decisions, the lack of a trusted symbol can train people to be suspicious.

Anyhow, it’s nice to see that the authentication/validation protocols are consolidating.