Mastering DMARC: Safeguarding Your Domain with Email Authentication

The three DMARC policies

How email receivers handle messages that fail DMARC authentication under each policy.

The p= tag takes one of three values:

• p=none — take no action, just send reports. This is monitoring mode: you learn who sends mail as you before enforcing anything.
• p=quarantine — deliver failing mail to the spam or junk folder, so a wrongly-failed message is still recoverable.
• p=reject — refuse failing mail outright, so it never reaches the recipient. This is full protection, and the target state for any domain that has finished monitoring.

Most domains progress none → quarantine → reject as confidence grows. For help choosing between the last two, see reject vs quarantine.

The tags that matter

A DMARC record is a set of tag-value pairs. The ones you'll actually use:

• v — the version, always DMARC1, and always first.
• p — the policy for the organizational domain (none, quarantine, reject).
• sp — an optional separate policy for sub-domains.
• rua — the address for aggregate reports: daily XML summaries of every source sending as your domain, with pass/fail counts.
• ruf — the address for failure (forensic) reports: near-real-time samples of individual failing messages. Support is uneven across receivers, so aggregate reports do most of the practical work.
• adkim / aspf — alignment mode for DKIM and SPF, r (relaxed) or s (strict).

A monitoring record is simply v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. You can build a valid one without touching syntax using the DMARC record generator.

Note the report tags carefully: rua is aggregate, ruf is failure/forensic. Older guides — and a lot of copy-pasted records — swap them. Aggregate reports (rua) are the ones you'll read day to day; see what an aggregate RUA report is and what a forensic RUF report is.

What RFC 9989 changed

For its first decade DMARC was defined by the Informational RFC 7489. In May 2026 the IETF published the DMARCbis revision as three Standards-Track documents — RFC 9989 (core protocol), RFC 9990 (aggregate reporting), and RFC 9991 (failure reporting) — which obsolete RFC 7489 and promote DMARC to a Proposed Standard.

Two changes matter in practice:

• The pct tag was removed. It was ambiguously defined and receivers interpreted it inconsistently. For a staged rollout you now publish t=y alongside an enforcing policy: receivers report on the stricter policy but don't yet act on it. If you still have pct=10 published, nothing breaks — receivers simply ignore the unknown tag — but new records should use t=y.
• Organizational-domain discovery now uses a DNS Tree Walk instead of the Public Suffix List. Receivers climb the DNS tree from the sending sub-domain looking for a published record, which makes sub-domain policy far more predictable.

DMARCbis introduced no breaking changes to the syntax you already publish. The full detail is in what DMARCbis (RFC 9989) changes.

Rolling out DMARC safely

The four steps to publish a DMARC record and start monitoring results.

The whole point of starting at none is to avoid blocking your own mail. A safe sequence:

1. Audit SPF and DKIM. Confirm every legitimate sender — internal servers, transactional providers, marketing platforms — passes at least one and aligns with your From: domain.
2. Publish p=none with an rua address you control. This starts the report flow without affecting delivery.
3. Read the aggregate reports for a full sending cycle. They surface forgotten senders — a billing platform, a helpdesk, a marketing tool — that still need SPF or DKIM fixed. The DMARC report guide explains how to read them.
4. Tighten in stages. Fix each failing sender, then move to quarantine, then reject. Use t=y if you want receivers to report on the stricter policy before it takes effect.

For a step-by-step version of this, see how to create a DMARC record and why enforcement matters.

Why it's worth the effort

• It stops exact-domain spoofing. At enforcement, attackers can no longer put your real domain in the From: field — the most convincing form of phishing.
• It gives you visibility. Aggregate reports show every service sending as your domain, often the first time an organization sees its full sending footprint.
• It protects deliverability. A domain that authenticates consistently earns better inbox placement, and DMARC at enforcement is a prerequisite for a BIMI logo in supporting inboxes.

Related reading

• What are DMARC, DKIM, and SPF?
• How to create a DMARC record
• DMARC reject vs quarantine: what's the difference?

Unsure whether your SPF, DKIM, and DMARC actually hold up together? Palisade's Email Security Score checks all three in one pass and shows you exactly what to fix first.