Exploring the DMARC Record: What You Need to Know

DMARC records are an important part of the email authentication trio (SPF, DKIM, and DMARC), and plays a part in email deliverability. DMARC is specifically designed for evaluating email messages.

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. Your DMARC record tells the receiving email servers what you want them to do with your emails that fail DMARC authentication, whether to do nothing, quarantine, or reject.

A primary use of DMARC is to help deal with spoofers. DMARC reports are also excellent in helping identify malicious actors and get feedback on your SPF & DKIM pass-fails.

The way that DMARC authentication works is it evaluates your message passing or failing SPF and DKIM authentication. In this way, proper implementation of DMARC requires you first implement your SPF records and DKIM records correctly, or else they will fail.

DMARC Record Requirements
DMARC requires you already have SPF and DKIM records both set up. DMARC records are not the same as SPF records nor as DKIM records; thus DMARC is not a replacement for either of these records. Instead, the DMARC framework relies on the evaluation of both of these records.

A valid DMARC record must contain certain mandatory tag values such as p=, v=DMARC1, and hosted following the "_dmarc" prefix syntax.

DMARC is completely free of charge, though you can utilize certain third-party software to better tracking and read the report outputs.

Although it's really up to the recipient servers to honor or ignore your stated DMARC policy preferences, though most major inbox providers such as Gmail use DMARC authentication and will send across Aggregate Reports.

How DMARC Authentication Works
To pass DMARC authentication, a message must pass at least one of these two checks:

• SPF authentication and SPF alignment
  
• DKIM authentication and DKIM alignment
  
  

A message fails the DMARC check if the message fails both:

• SPF (or SPF alignment)
  
• DKIM (or DKIM alignment)
  
  

So the evaluation process looks like this:

SPF and DKIM Alignment

The SPF alignment and DKIM alignment criteria differs from simply SPF and DKIM evaluation. As seen in the above diagram, DMARC looks at alignment as an additional factor for pass/fail.

DMARC defaults to a relaxed alignment setting, but you can override these by defining aspf= and adkim= values.

Alignment can best be explained by this table:

Source: Google

Creating a DMARC Record
You add a DMARC record as a TXT type record inside your DNS records. Here's an example of what a typical DMARC record looks like:

Let's break down the DMARC tag elements:

• _dmarc - the _dmarc part is the standardized syntax indicating a DMARC record.
  
  
• v=DMARC1 - the required denotation that this TXT record is a DMARC record. This notation should be familiar from the earlier discussion of SPF and DKIM using the same syntax.
  
  
• p=none - indicates your desired DMARC policy. This essentially is what you instruct the recipient server to do in the case where DMARC authentication fails. The three value options are none, quarantine, and reject.
  
  
  • None is just as it sounds, you instruct the recipient server to do nothing special with the email in case DMARC authentication fails.
    
    
  • Quarantine instructs to quarantine the email, such as to route it to spam.
    
    
  • Reject instructs to outright reject the email.
    
    

• pct - this stands for 'percentage', and refers to the percentage of the received email volume you want to subject to the stated DMARC policy. Adjusting this percentage is part of the process of moving towards stricter policies like quarantine and reject, as you likely don't want to go pct=100 and p=reject right away, but rather at that stage go with something like pct=10 and p=reject, for example, so you are hedging your risk in case your own emails get caught up and fail DMARC authentication.
  
  
• rua & ruf - this stands for aggregate reports and forensic (or failure) reports respectively. You set an email address (or list of email addresses) to which you want DMARC reports delivered to. The forensic reports are not as well-supported, for example Google doesn't send forensic reports; they only send aggregate reports.
  
  

There are several more tags than this, so for a more comprehensive list, you can refer to this Google article.

Getting DMARC Record Values
Your DMARC record is entirely constructed by yourself following the standard syntax. Subdomains will inherit the root domain's DMARC policy if it exists. Otherwise, you can also explicitly place DMARC records on subdomains or use the sp tag.

Common DMARC Mistakes
Quarantining or Rejecting Legitimate Emails
One of the most common and potentially harmful DMARC mistakes is defining an overly strict policy before you ensure your own email is consistently passing DMARC authentication. This can really hurt your deliverability.

For any sender that is new to DMARC, we always recommend starting with a policy of p=none. The reason is because most senders at this point have not been receiving DMARC reports and may have misconfigured (misaligned) SPF and DKIM configurations. So it's actually fairly likely that setting a p=quarantine or p=reject will shoot the sender in the foot because it can cause inadvertent quarantine or rejection of their own, legitimate emails due to DMARC authentication failing.

Only once there is good confidence of consistent passing of DMARC authentication for all the intended sender's emails does it make sense to ratchet up the strictness of the policy to quarantine or reject.

Not Receiving or Reviewing DMARC Reports
We often see DMARC records with no rua values (hence no reports) and many times nobody reads those reports (happens often).

Part of the purpose of DMARC is to help monitor and deal with malicious actors and spoofers. This is why it's important to receive and regularly monitor the DMARC reports to identify potential IP addresses that may be suspicious!

This way you can make decisions on if and when to change your DMARC policy to best protect your brand and customers from bad email actors.

Summary
DMARC is a great record to implement as it not only gives you deliverability visibility via reports, it also gives you as a sender a degree of control in defining policies to combat potential bad actors.

We recommend a basic DMARC implementation for all email senders and brands, and increasingly advanced implementations depending on the sender needs.