Mastering DMARC: Safeguarding Your Domain with Email Authentication

Q: What replaced the pct tag in DMARCbis?

The t=y tag. It signals that the published policy should be treated as a test — receivers apply no enforcement action (like the old pct=0) while still sending reports that show what would have failed. It's the clean way to stage a move to quarantine or reject without risking live mail.

What DMARC is

DMARC — Domain-based Message Authentication, Reporting, and Conformance — is the email authentication control that ties SPF and DKIM to the address your recipients actually see. On their own, SPF and DKIM can each pass for a domain an attacker controls; neither protects the visible From: header. DMARC closes that gap by requiring that whichever check passed aligns with the From: domain, and by telling receivers what to do when nothing aligns. That is what stops exact-domain spoofing and the domain-based phishing built on it.

DMARC has also moved from optional to expected. Gmail, Yahoo, and Microsoft now require any domain sending roughly 5,000 or more messages a day to personal inboxes to publish a DMARC record, and non-compliant bulk mail is rejected rather than merely filtered.

How DMARC works

You publish one TXT record at _dmarc.yourdomain.com. When a receiver gets a message claiming to be from your domain, it runs three steps:

Authentication. It checks whether the sending IP is authorized by your SPF record and whether the message carries a valid DKIM signature.
Alignment. A pass only counts if the SPF or DKIM domain aligns with the visible From: domain. This is DMARC's core idea — it's what stops an attacker from borrowing your address with mail that is technically well-signed for a domain they own.
Policy. If neither SPF nor DKIM passes and aligns, the receiver applies the action your policy requests.

DMARC needs only one of SPF or DKIM to pass and align, not both. Because a DKIM signature travels with the message, it often survives forwarding when SPF breaks — which is why a correctly signed domain keeps authenticating through mailing lists.

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

Four-step flow for creating a DMARC record, from auditing SPF and DKIM to monitoring reports.

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:

Audit SPF and DKIM. Confirm every legitimate sender — internal servers, transactional providers, marketing platforms — passes at least one and aligns with your From: domain.
Publish p=none with an rua address you control. This starts the report flow without affecting delivery.
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.
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.

Frequently asked questions

Do I need both SPF and DKIM before turning on DMARC?

You need at least one working and aligned, but you should set up both. DMARC evaluates the results of SPF and DKIM — it authenticates nothing itself — so a record with neither behind it fails every legitimate message once you enforce. In practice DKIM is the more resilient of the two because its signature survives forwarding, so most domains lean on DKIM alignment and keep SPF as a second path.

What replaced the `pct` tag in DMARCbis?

The t=y tag. It signals that the published policy should be treated as a test — receivers apply no enforcement action (like the old pct=0) while still sending reports that show what would have failed. It's the clean way to stage a move to quarantine or reject without risking live mail.

Will enforcing DMARC break my newsletters or forwarded mail?

Only if those streams aren't authenticated. Forwarding often breaks SPF, but a valid DKIM signature usually survives it, so DMARC still passes on DKIM. The real risk is a legitimate sender you forgot to authenticate — which is exactly what the p=none monitoring phase exists to surface before you enforce.

How is a sub-domain's policy decided?

By default the organizational-domain record covers sub-domains. To treat them differently, add an sp= tag or publish a dedicated _dmarc record on the sub-domain. Under RFC 9989 receivers find the governing policy with a DNS Tree Walk, so sub-domain behavior is more predictable than under the old Public Suffix List approach.

Does DMARC encrypt my email?

No. DMARC is about authenticity and policy, not confidentiality. It verifies a message truly came from your domain and tells receivers what to do if that can't be proven — but the body still travels in plain text unless the connection is separately protected with TLS.

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.