What is a DMARC Policy?

Key Takeaways

• A DMARC policy is the instruction published in your DNS that tells receiving mail servers how to handle a message that fails DMARC authentication.
• There are three policy options: p=none (monitor only), p=quarantine (send to spam), and p=reject (do not deliver).
• A DMARC policy is an instruction to receiving servers, not a filter you run. It reduces spoofing by making unauthenticated mail actionable at the receiver, and it reports back on what happened, but it inspects nothing in the message itself.
• Most organizations move through the three policy levels in stages, using DMARC aggregate reports at each step to confirm every legitimate sending source is authenticated before tightening the policy.
• Enterprise environments with multiple domains and sending sources need reporting and oversight at every stage, to maintain accountability across IT, security, and compliance teams.
• DMARC was re-published in 2026 as RFC 9989, 9990, and 9991, replacing RFC 7489. The pct= tag is gone, and t=, np=, and psd= are new.

What a DMARC Policy Does

An unauthenticated sending source is exactly what lets an attacker impersonate a trusted domain in the first place. That is the attack path a DMARC policy is designed to close off.

A DMARC policy is the p= tag in your DMARC DNS record. It tells a receiving mail server what to do with a message that claims to come from your domain but fails SPF or DKIM alignment: deliver it, send it to spam, or decline to deliver it.

DMARC checks whether the sending source is authorized and aligned with your domain, using SPF and DKIM as the underlying checks. The policy tag is what turns that authentication result into an action at the receiving server.

A DMARC record is published as a DNS TXT record at _dmarc.yourdomain.com.

Here’s the minimal structure:

 v=DMARC1; p=none; rua=mailto:[email protected]

You can check whether your domain’s record is published correctly with the EasyDMARC DMARC record checker.

How a DMARC Policy Is Evaluated

Each incoming message goes through the same evaluation sequence at the receiving server before your policy takes effect:

1. A message arrives claiming to be from your domain.
2. The receiving server checks SPF and DKIM authentication and alignment.
3. If the message passes and aligns, it is delivered normally.
4. If it fails, the server looks for your DMARC record. It queries _dmarc at the sending domain first, then walks up the DNS tree toward the organizational domain until it finds a record, up to a limit of eight queries. This tree walk replaced the Public Suffix List in RFC 9989, which means your policy is now discovered from your own DNS rather than from an externally maintained list of domain suffixes.
5. The server applies that policy: deliver, quarantine, or reject.
6. The server sends an aggregate report back to the address in your rua= tag, summarizing pass/fail activity for that period.

This reporting loop keeps DMARC functioning as an ongoing monitoring and enforcement layer. Every policy level, including p=reject, continues generating reports.

The Three DMARC Policy Options

1. Monitoring Policy (p=none)

 v=DMARC1; p=none; rua=mailto:[email protected]

With p=none, the receiving server takes no action based on DMARC results. Every message, passing or failing, is delivered normally. The record’s only function at this stage is to generate aggregate reports.

For an enterprise domain, this stage is where you build the picture of every sending source across marketing platforms, transactional email tools, and internal systems, including ones IT may not know are sending on the domain’s behalf. Skipping this stage on a domain with many sending sources is the most common cause of legitimate mail getting caught later at enforcement.

p=none is a starting point for data collection, and it provides no enforcement on its own.

2. Quarantine Policy (p=quarantine)

 v=DMARC1; p=quarantine; rua=mailto:[email protected]

p=quarantine instructs the receiving server to route messages that fail DMARC checks to the recipient’s spam folder instead of the inbox. Messages that pass are unaffected.

This stage functions as a checkpoint. If a legitimate sender was missed during monitoring, its mail lands in spam instead of being rejected outright, which gives you room to identify and fix the source before moving further.

Under RFC 7489, the pct= tag let you apply the policy to a percentage of failing messages. That tag was removed in RFC 9989, so gradual rollout is no longer a matter of turning a dial from 25 to 50 to 100. Enforcement now scales by scope rather than by sample: authenticate one sending source at a time, and use sp= and np= to enforce on the parts of your namespace you are already confident about while the root domain stays at a lower policy. If you want to publish an enforcement policy without it being applied yet, t=y is the supported way to do that.

3. Reject Policy (p=reject)

 v=DMARC1; p=reject; rua=mailto:[email protected]

p=reject asks the receiving server not to deliver messages that fail DMARC authentication, so the message reaches neither the inbox nor the spam folder. It is worth being precise about the word “asks”: RFC 9989 describes quarantine and reject as the domain owner’s stated preference, and a receiving organization is under no obligation to honor it. Most large receivers do, but some apply local exceptions — mailing lists and forwarded mail are the common ones. When a receiver overrides your policy, it tells you so in the aggregate report, which is one more reason reporting stays switched on after you reach enforcement.

This is the strongest policy level, and the one enterprise compliance frameworks typically require for domains handling sensitive communication. It’s also the least forgiving: any legitimate source that wasn’t authenticated before this point will have its mail rejected. Reaching p=reject safely depends entirely on the completeness of the monitoring and quarantine stages before it, not on the policy tag itself.

Other Tags That Shape Policy Behavior

The p= tag gets the most attention, but several other tags change how a policy actually behaves.

sp= — Sets a separate policy for subdomains that exist. Without it, subdomains inherit the root domain’s policy. It is ignored for any subdomain that publishes its own DMARC record, and it is useful in both directions: to lock a subdomain down ahead of the root domain, or to hold one at a lower policy while its sending sources are still being authenticated.

np= — Sets a policy for subdomains that do not exist in DNS at all. This is the tag worth adding first. Attackers do not need a real subdomain to spoof one, and invoices.yourdomain.com looks entirely legitimate in a From header whether or not it resolves. Because no real mail can originate from a subdomain that does not exist, np=reject carries close to no deliverability risk even while the root domain is still at p=none. If np= is absent, non-existent subdomains fall back to sp=, then to p=.

t= — Test mode. t=y tells receivers to treat the published policy as a declaration of intent rather than an instruction, so you can publish p=reject; t=y and keep receiving reports without failing mail being blocked. The default is t=n. It replaced pct= and is deliberately binary: on or off, with no partial application. Treat it as a temporary state with a date attached, not a resting place.

adkim= and aspf= — Control how strictly DMARC checks domain alignment for DKIM and SPF. r (relaxed) allows a subdomain match; s (strict) requires an exact match. Relaxed is the default and is appropriate for most organizations.

fo= — Controls when failure reports are generated. fo=1 requests one when either SPF or DKIM fails; the default, fo=0, requests one only when the message fails everything. In practice, very few receivers send failure reports at all, and those that do may include message content, so this is more of a debugging option than a monitoring one.

psd= — Declares whether a domain is a public suffix domain. It applies to registry and TLD operators rather than to ordinary organizational domains; the default, u (unknown), is correct for almost everyone.

What Changed in the 2026 DMARC RFCs

DMARC was re-published in May 2026 across three documents that together replace RFC 7489: RFC 9989 for the core protocol, RFC 9990 for aggregate reporting, and RFC 9991 for failure reporting. This work was known as DMARCbis while it was in progress, but there is no longer a second version to distinguish it from. It is simply DMARC.

Existing v=DMARC1 records remain valid, and the three policy values have not changed. What changed around them:

• pct= was removed. Operational experience showed it was rarely applied accurately by receivers at any value other than 0 or 100, so the sampling behavior it implied was never as reliable as it looked. t=y replaces it.
• rf= and ri= were removed. Report format only ever had one usable value, and reporting interval was widely ignored.
• np=, t=, and psd= were added.
• The Public Suffix List was replaced by a DNS tree walk for determining the organizational domain.

If your record still contains pct=, remove it. This is more urgent than housekeeping. A record such as p=reject; pct=0 was a common way to publish an enforcement policy without enforcing it. A receiver following RFC 9989 ignores pct entirely and applies the policy as written, so that same record now means full reject at that receiver — while a receiver that has not yet migrated still applies none. During the transition your enforcement level is not gradual, it is inconsistent, and it varies by mailbox provider. Any record relying on pct below 100 should be rewritten now: use t=y if you want the policy held back, or drop the tag if you are ready to enforce.

You can check what your domain currently publishes with the EasyDMARC DMARC record checker.

p=none vs. p=quarantine vs. p=reject

	p=none	p=quarantine	p=reject
Action on failing messages	Delivered normally	Sent to spam folder	Not delivered
Enforcement level	None (monitoring only)	Partial, scoped by sp= and np=	Full
Generates aggregate reports	Yes	Yes	Yes
Risk to legitimate mail if misconfigured	None	Low, mail lands in spam	High, mail is not delivered
Typical use case	Initial data collection	Verifying legitimate sources before full enforcement	Steady-state enforcement for a fully authenticated domain

Which DMARC Policy Should You Implement

The end state most enterprise domains work toward is p=reject, but the path there depends on the completeness of your sending source inventory, not a fixed timeline. Organizations with many domains and sending platforms typically need longer at the monitoring and quarantine stages than a single-domain environment does.

EasyDMARC’s platform surfaces every sending source identified in your aggregate reports and tracks authentication status per source, so your team can see exactly which sources are ready before advancing the policy.

Because policy no longer scales by percentage, the sequencing question is which parts of your namespace you enforce on first, not what share of failing mail you enforce against. Non-existent subdomains are usually the safe starting point.

Moving to p=reject before every legitimate source is authenticated will cause real mail to go undelivered. Continued monitoring after reaching p=reject is still necessary, since new sending sources get added to enterprise environments regularly.

For enterprise domains managing this across many properties, EasyDMARC’s Support Team can help scope and sequence a policy rollout, guided by a step-by-step enforcement approach.

Frequently Asked Questions

Talk to EasyDMARC’s Support Team

EasyDMARC’s Support Team works with your organization through each stage of DMARC policy implementation, from initial monitoring through full enforcement. Contact us today to scope your rollout.