Email Authentication: DMARC Explained

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the third pillar of email authentication, building on SPF and DKIM to give domain owners control over how their email is handled when authentication fails.

What DMARC does

DMARC allows domain owners to publish a policy that tells receiving servers what to do with email that fails SPF or DKIM authentication. It also provides reporting mechanisms so domain owners can see who is sending email on their behalf.

How DMARC works

Domain owner publishes DMARC record. A TXT record is added to DNS specifying the policy and reporting options.
Email is received. The receiving server gets an email from the domain.
SPF and DKIM are checked. The receiving server verifies SPF and DKIM for the message.
DMARC policy is applied. Based on SPF/DKIM results and the DMARC policy, the email is handled accordingly.
Reports are sent. The receiving server sends reports to the domain owner about authentication results.

DMARC record syntax

A typical DMARC record looks like this:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com

Key fields:

v=DMARC1 — DMARC version
p= — Policy (none, quarantine, reject)
rua= — Aggregate report destination
ruf= — Forensic report destination

DMARC policy options

p=none: Monitor mode. No action is taken on authentication failures. Reports are sent. This is the starting point for new DMARC implementations.

p=quarantine: Messages that fail authentication are treated as suspicious (often sent to spam folder).

p=reject: Messages that fail authentication are rejected outright. This is the strongest policy but should only be used after ensuring legitimate email passes authentication.

DMARC alignment

DMARC requires alignment between the authenticated domain and the From domain:

SPF alignment: The domain in the SPF record must match the From domain (or be a subdomain).

DKIM alignment: The domain in the DKIM signature (d= field) must match the From domain (or be a subdomain).

Both SPF and DKIM must pass and align for DMARC to pass.

DMARC reporting

Aggregate reports (RUA): Daily summaries of authentication results, showing volume and pass/fail rates.

Forensic reports (RUF): Individual reports for failed messages, including the message headers. These are more detailed but can be voluminous.

DMARC implementation path

Start with p=none to monitor without affecting deliverability. Review reports to identify legitimate senders and fix authentication issues. Gradually move to p=quarantine and eventually p=reject once you are confident all legitimate email passes authentication.

Temporary email and DMARC

Temporary email services must implement DMARC for their domains to ensure their email (if they send any) is properly authenticated. When you receive email in a temporary inbox, DMARC authentication happens on the incoming message based on the sender's DMARC policy, not the temporary email service's policy.

Questions

Should I start with p=reject?

No. Always start with p=none to monitor without affecting deliverability. Moving directly to p=reject can cause legitimate email to be rejected if you have not properly configured SPF and DKIM for all your senders.

What happens if I don't publish a DMARC record?

Without a DMARC record, receiving servers will handle your email based on their individual SPF and DKIM policies. Some domains may treat your email as less trustworthy. DMARC is increasingly expected for legitimate senders.