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 play a critical part in email deliverability. DMARC is specifically designed for evaluating email messages and protecting your brand from spoofing.

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 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:

• v=DMARC1 — the required version identifier
• p= — the policy tag (none, quarantine, or reject)
• Hosted following the _dmarc prefix syntax in your DNS

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

Although it's ultimately up to the recipient servers to honour or ignore your stated DMARC policy preferences, 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)

In other words, DMARC gives you a pass as long as one of your authentication methods (SPF or DKIM) is both valid and aligned. This is why getting both SPF and DKIM set up correctly matters — it gives you two chances to pass rather than one.

SPF and DKIM Alignment

The SPF alignment and DKIM alignment criteria differ from simply SPF and DKIM evaluation. 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.

Creating a DMARC Record

You add a DMARC record as a TXT type record inside your DNS records — typically at _dmarc.yourdomain.com. Here's what a real DMARC record looks like, broken down tag by tag:

Let's walk through each of these tag elements:

• _dmarc — the standardised 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 | quarantine | reject — indicates your desired DMARC policy. This essentially instructs the recipient server what to do when DMARC authentication fails:
  • none — do nothing special with the email if DMARC authentication fails.
  • quarantine — route the email to spam.
  • reject — outright reject the email.
• pct — stands for "percentage", and refers to the percentage of 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.
• rua & ruf — 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. Note: forensic reports are not as well-supported; for example, Google doesn't send forensic reports — they only send aggregate reports.

In the example above, the policy is set to quarantine with fo=1, meaning a forensic report is generated if any underlying check fails — giving maximum visibility into authentication issues.

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 to define a subdomain-specific policy.

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 cause inadvertent quarantine or rejection of your own, legitimate emails due to DMARC authentication failing.

Only once there is good confidence of consistent passing of DMARC authentication for all of 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.

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.