DMARC policy: how it works and why it protects your domain

What is a DMARC policy

DMARC (Domain-based Message Authentication, Reporting & Conformance) is a DNS TXT record that tells receiving mail servers what to do with messages that fail SPF and DKIM checks. It was designed to close a specific gap: SPF validates the envelope sender, DKIM validates a cryptographic signature, but neither controls what happens when validation fails, and neither ties results to the From header domain the recipient actually sees. DMARC closes both gaps.

The core concept is alignment. DMARC requires that the domain passing SPF or DKIM matches the domain in the visible From header. Without alignment, an attacker can pass SPF on their own domain while spoofing yours in From. With DMARC, that trick fails: the receiver checks whether the authenticated domain and the From domain are the same, or share a parent domain in relaxed mode.

How DMARC works

When a message arrives, the receiving server runs SPF and DKIM checks, then fetches the DMARC record for the From header domain. If at least one check passes with correct alignment, the message is authenticated. If both fail, the server applies the policy from the p= tag.

Alignment comes in two modes. Relaxed mode (the default) allows a subdomain to match its parent domain, so mail sent from mail.example.com or news.example.com still aligns with example.com in From. Strict mode requires an exact domain match.

Three policy levels

p=none is monitoring mode. Messages are delivered normally, but providers send aggregate reports to the address in rua=. Every deployment should start here: two to four weeks in none mode shows which servers send on your behalf and which pass authentication.

p=quarantine routes unauthenticated messages to the spam folder. Move here only after all legitimate senders are correctly configured. The pct= tag lets you apply the policy to a percentage of messages first: start at 10%, then 50%, then 100%.

p=reject is the end goal. The provider refuses unauthenticated messages at the SMTP level. The message never reaches the inbox or spam folder. Gmail, Yahoo, and Microsoft all recommend this mode. Jumping straight to reject without monitoring first almost always blocks legitimate mail.

Record structure

A DMARC record is published at the _dmarc subdomain as a TXT entry. For example.com the minimum record looks like: v=DMARC1; p=none; rua=mailto:dmarc@example.com.

Beyond v= and p=, the useful tags are: sp= sets a separate policy for subdomains; pct= applies the policy to a percentage of traffic; adkim= and aspf= set alignment to strict (s) or relaxed (r, the default); ruf= requests forensic reports for individual failed messages.

Reports

Aggregate reports (rua) arrive as gzipped XML once per day from each provider that processed mail from your domain: Gmail, Outlook, Yahoo, and others. Each report lists source IPs, message counts, SPF and DKIM pass rates, and the policy action taken. Tools like Postmark DMARC Digests or dmarcian convert these into readable dashboards. Without rua=, you have no visibility into whether your policy is working.

Forensic reports (ruf) include headers from individual failed messages. They help investigate spoofing incidents, but many providers, including Gmail, do not send them.

Common mistakes

Jumping to reject without monitoring. Third-party services, CRMs, helpdesks, and transactional platforms often send with broken alignment. Switching to reject before fixing them will block legitimate mail.

No rua tag. DMARC without a reporting address is blind. You will not know whether failures come from attackers or your own marketing platform.

SPF configured, DKIM not. When a message is forwarded, the envelope sender changes and SPF alignment breaks. If DKIM is missing, DMARC fails on every forwarded message. DKIM survives forwarding because the signature is tied to message content, not to the sending IP.

Forgetting subdomains. Without sp=, subdomains inherit the parent domain policy. If a subdomain runs a different mail stream, that inheritance can block it. Set sp= explicitly or publish separate DMARC records for each subdomain.

Gmail and Yahoo requirements since 2024

Since February 2024, Gmail and Yahoo require a DMARC record (minimum p=none) for bulk senders, defined as those sending more than 5,000 messages per day to Gmail addresses. Domains without any DMARC record risk having their mail deprioritized or rejected. DMARC has effectively moved from best practice to a mandatory prerequisite for commercial sending.

Effect on deliverability

DMARC does not guarantee inbox placement on its own. It is a domain protection mechanism, not a deliverability shortcut. The indirect benefit is real though: a domain at p=reject cannot be spoofed, so its sender reputation stays clean regardless of what attackers try to do with it.

A misconfigured DMARC record hurts deliverability directly. At quarantine, legitimate messages land in spam. At reject, they never arrive. The phased rollout through none, quarantine, and reject is the standard procedure, not optional caution.