DMARC is a technology that combines SPF and DKIM to offer domain owners better protection against spoofing. The basic premise is that spammers now know of many methods of ignoring the protections offered by other authentication technologies (SPF and DKIM). DMARC ties them all together while adding reporting mechanisms to help in correcting and updating the DMARC. 

To understand how DMARC verifications work, we first need to talk about both SPF and DKIM.


We already have a detailed article explaining SPF that you can check out for more details (see the Related Articles). The short version is that SPF verifications happen during the SMTP transaction. The SPF verification checks to see if the server sending the email is allowed to send on behalf of that domain. Whether it is, and what to do if it isn't, is all determined by the SPF record of the domain used during the SMTP transaction.


DKIM works using two parts: 

  1. When an email is sent by the server, a DKIM signature is generated. This signature is generated by hashing together parts of the email (selected headers and body content) and a private cryptographic key.
  2. When a server receives an email with a DKIM signature, it can check the DNS to find that domain's public key. This key is then used to verify that none of the hashed content (the selected headers and body content) were changed during transit. The DKIM verification fails if any of the content was changed since the message was sent.

The DKIM signature technology allows an organization to certify that a third party can send with its domain name at the Content-From level. For instance, mass-mailers such as Constant Contact and MailChimp enable the user to set up a DKIM key that allows these senders to sign the messages that they send in the user's name.

Putting it all together: DMARC

The verification done by DMARC is quite a simple one: is the sending domain used in the content of the email aligned with (ie.: is equal to) a domain used in another authentication verification.


Let's break this down.

  • The DMARC record exists on a domain you see in the Content-From address of the email. 
  • DMARC checks to see if that same domain was used in the SPF verification and that the SPF verification had no errors. 
  • DMARC checks to see if that same domain was used in the DKIM verification and that the DKIM verification had no errors. 

To put it another way, at least one of the following must be true for DMARC alignment to succeed:

  • the Content From must be equal to the Mail From (and SPF check succeeds) or;
  • the Content From must be equal to the SDID (ie.: d= domain) (and DKIM check succeeds)

What's interesting about DMARC is that it's so much more than just this verification. The DMARC record tells the checking server what action to take with messages that fail the verification (reject, quarantine, or none) and on what percentage of failed emails to apply this action. DMARC also allows the sending of reports -that's the R in DMARC- to specific email addresses. These reports are useful to determine which senders are attempting to spoof the domain or if any servers are not configured correctly.

Our filters perform DMARC checks and execute the actions specified by the sender in case of a failure. If DMARC verifications are causing difficulties, you can add the problem domain to the  authentication whitelist or the IP address to the trusted IPs list.

You can read an introduction to DMARC here. You will also find more technical information in RFC7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC).