DMARC (Domain-based Message Authentication)

DMARC is an email authentication protocol that builds on SPF and DKIM. It lets domain owners publish a policy telling receivers how to handle messages that fail authentication, and provides a reporting mechanism for visibility into email flows.

How DMARC Works

When a receiver gets an email, it checks SPF and DKIM as usual. DMARC adds two requirements on top. First, at least one of SPF or DKIM must pass. Second, the passing mechanism must be aligned with the From: header domain. Alignment means the domain authenticated by SPF (the envelope sender) or DKIM (the d= value in the signature) matches the visible From domain, either exactly (strict) or at the organizational domain level (relaxed).

If both alignment checks fail, the receiver applies the domain's DMARC policy to decide whether to deliver, quarantine, or reject the message.

DMARC Record Syntax

DMARC is published as a TXT record at _dmarc.<domain>:

_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100"

Key tags:

• v=DMARC1 - version (required, must be first).
• p= - policy for the domain: none, quarantine, or reject (required).
• rua= - address to receive aggregate reports. These are daily XML reports showing pass/fail statistics from receivers.
• ruf= - address to receive forensic (failure) reports. These contain details about individual failed messages. Many receivers do not send these due to privacy concerns.
• pct= - percentage of messages to apply the policy to (default 100). Useful for gradual rollout.
• sp= - policy for subdomains. If omitted, subdomains inherit the p= policy.
• adkim= / aspf= - alignment mode for DKIM/SPF: r (relaxed, default) or s (strict).

DMARC Policies

• p=none - monitor only. Messages are delivered normally regardless of authentication results. Use this to collect data before enforcing.
• p=quarantine - failing messages are typically placed in the spam or junk folder.
• p=reject - failing messages are dropped entirely. This is the strongest protection against spoofing.

The recommended approach is to start with p=none and a rua address, review the aggregate reports to identify all legitimate sending sources, ensure they pass SPF or DKIM with alignment, then move to quarantine and finally reject.

Common Mistakes

• Jumping straight to p=reject. Without monitoring first, you will almost certainly block legitimate email from third-party senders you forgot to authorize. Always start with p=none and review reports.
• Not including rua. Without aggregate reports, you have no visibility into who is sending email as your domain or whether your authentication is working correctly. The reports are the entire point of starting with p=none.
• Forgetting subdomains. Without an explicit sp= tag, subdomains inherit the parent domain's policy. If you have p=reject but a subdomain sends email without proper authentication, those messages will be rejected. Conversely, if you have p=none and attackers spoof a subdomain, there is no protection unless you set sp=reject.
• Mailing list breakage. Mailing lists that modify messages (adding footers, rewriting subjects) will break DKIM signatures. This is a known limitation. Lists that use ARC (Authenticated Received Chain) or that rewrite the From address can mitigate this.

Check your DMARC policy with the DNS tool →