Why do we need DMARC?

DMARC is the acronym for “Domain-based Message Authentication, Reporting & Conformance”.

As outlined in previous posts, SPF and DKIM were two frameworks that attempted to correct the issue of email security. In summary, SPF tells a receiver that the mail came from an authorised server that is allowed to send that mail, while DKIM is a framework that makes sure that the mail is the same one that was sent.

The main problem with both frameworks, however, was that when the receiving server checked the SPF and/or DKIM settings and saw that they were failing, it didn’t always know what to do with the mail in question.

Should it put it in the spambucket, or not accept it at all? After all, SPF can often be set up incorrectly, even though the mail itself was legitimate.

What started to happen is that a lot of companies were publishing SPF records that were incorrect or incomplete. The receivers were getting so much mail off these incorrect servers that they weren’t sure what to do. So, they decided that the mail was legitimate, and to ignore the incorrect records and send it on anyway.

As a solution for this, a policy called DMARC was designed to sit on top of both SPF and DKIM. Because it’s a policy that a domain owner publishes, it puts the control of what the receiver must do with a particular mail firmly in the domain owner’s hands.

Remember that in the past, receivers didn’t know what to do with a mail if it failed the SPF or DKIM checks. Now with DMARC, the domain owner essentially says to the receiving server: “If you get this mail from my domain and SPF or DKIM fails, do not accept it.”

This then made the task easier for receiving servers. Finally, they didn’t have to make up their mind about what to do with a particular mail; the domain owner would tell them what to do.

The second key function that DMARC did was to send a report to the domain owner upon receiving a mail that says, for example: “We got a mail from you, and it came from this particular IP, and it was passing SPF and failing DKIM.”

With this example, the receiving server is not only being instructed by domain owners on what to do, but they are also telling domain owners about mail that they are getting from them. This is very important, because often domain owners aren’t even aware of all their own receiving servers!

Some multinationals have hundreds of servers, and don’t know about all of them. Even in the case of small businesses, there may be several servers sending mail: via a CRM system, a ticketing system, a billing system and more.

In another scenario, there may be a small business employee who starts doing email marketing using Mailchimp as a sending server, without anyone else knowing about the platform. The problem here is that if SPF is implemented and Mailchimp isn’t authorised as a sender, all the Mailchimp mails will start failing.

That’s why these DMARC reports are so important, as they tell domain owners which severs are sending mail, and which ones should be audited and authorised where applicable.

These reports then create full visibility for the domain owner, as they can see everybody sending mail from their domain. This, in turn, makes it much easier for them to authorise the correct servers, as before they may not have known about them.

Implementing DMARC creates a simple way of putting control back into the email sender’s hands – no matter where that mail is sent.