DMARC Policy: The p Tag, and Why Publishing One Protects Nothing

A DMARC policy is the instruction a domain publishes telling receiving mail servers what to do with messages that claim to come from it and fail authentication. It travels in the p= tag of the domain's DMARC record, a TXT record at _dmarc.<domain>, and it takes one of three values: none, quarantine or reject. The current specification is RFC 9989, dated May 2026, whose header carries the line "Obsoletes: 7489, 9091".

The specification states each value as a statement about the domain owner rather than as an instruction to filter. For none: "none: The Domain Owner offers no expression of preference." For the middle value: "quarantine: The Domain Owner considers such mail to be suspicious." And for the strictest: "reject: The Domain Owner considers all such failures to be a clear indication that the use of the domain name is not valid."

What the policy is applied to

The policy only ever runs on messages that have already failed the DMARC check, and understanding that check is what makes the three values legible.

DMARC does not require both SPF and DKIM to pass. It requires that at least one of them passes and is aligned, meaning the domain that authenticated matches the domain in the visible From header. A message can pass SPF outright, on a domain the sender's platform owns rather than one you own, and still fail DMARC because nothing lined up with what the reader sees. That is the ordinary behaviour of many third-party senders, and it is why every platform asks you to publish its DKIM records on your own domain.

1. Step 1Check SPF and alignment

   Did the connecting server pass SPF, and does the envelope domain align with the From domain?

2. Step 2Check DKIM and alignment

   Did a signature verify, and does the signing domain align with the From domain?

3. Step 3One aligned pass is enough

   If either check passed and aligned, DMARC passes and the policy is never consulted.

4. Step 4Apply the policy

   Only when both fail does the p tag decide: take no action, treat as suspicious, or refuse.

Alignment itself has two modes and the default is the forgiving one. Relaxed alignment accepts a match at the organisational domain, so a subdomain aligns with its parent; strict alignment demands an exact match. Relaxed is the sensible default and is the reason a subdomain sending strategy works at all. Choosing strict without understanding that distinction is a reliable way to start failing your own mail.

Why it matters: a published record is not an enforced one

Publishing p=none is the correct first move and a bad permanent position, and the gap between those two facts is where DMARC rollouts stall.

At none, the record exists, reports arrive, and nothing is refused. That is exactly what it is for: it lets you enumerate every service sending as your domain before you start blocking anything, and the enumeration is a list nobody in an organisation can produce from memory. The failure mode is staying there for two years because nobody scheduled the next step, then describing the domain as DMARC compliant.

The distinction that catches people out is between compliance and protection. Google's sender guidelines require every sender to "Set up SPF or DKIM email authentication for your sending domains", and the requirement is a published record rather than an enforcing one, so p=none satisfies the bar as written. What p=none does not do is stop anybody sending mail that claims to be your domain. Compliance is the floor. Enforcement is the security decision layered on top of it, and only the second one changes what a receiver does with a forged message.

p=noneMonitor

• No action taken on failing mail
• Aggregate reports still arrive
• Forged mail reaches inboxes unchanged
• The correct place to start, and a bad place to stay

p=quarantineEnforce, softly

• Failing mail is routed to spam
• Any legitimate sender you missed becomes visible quickly
• Reversible with limited damage
• The usual second step, held for a fortnight

p=rejectEnforce, fully

• Failing mail is refused outright
• The strongest protection against forgery of your domain
• A sender you forgot now fails silently
• The destination, reached deliberately

Two tags sit beside p= and change what it covers. sp= sets a separate policy for subdomains, and np= sets one for subdomains that do not exist at all, which is the surface an attacker reaches for once the main name is enforcing. A policy on the parent domain does not automatically govern either, and non-existent subdomains were unprotected entirely before np= arrived.

One piece of older advice is now obsolete and worth unlearning. The classic rollout was to enforce by percentage, publishing a quarantine policy applied to a fraction of mail and stepping the fraction upward. RFC 9989 lists it among the tags removed, described there as a "Tag requesting application of the DMARC policy to only a percentage of messages", so a new rollout plan should not be built around it. An existing record carrying it keeps working, because receivers ignore tags they do not recognise rather than rejecting the record, which is precisely why the deprecation is easy to miss.

Where the textbook definition misleads

Four readings of the tag are common and each one costs something.

A policy is not a filter you control. The tag is a request, and receivers weigh it against their own judgment of the sender. A reject policy on a domain with a poor sending history does not buy that domain better treatment, and an enforcing policy has never moved a message from spam to the inbox. What it decides is what happens to mail forged as you, which is a different problem from where your own mail lands.

Failures in the reports are mostly not attacks. Forwarding routinely breaks authentication: a mailing list that appends a footer invalidates a DKIM signature, and a redirection changes the connecting address so SPF fails. A steady trickle of failures from forwarding sources is the normal state of a working domain, and treating it as evidence of forgery wastes weeks.

Enforcing without reading is the expensive order. The policy is one DNS edit and takes thirty seconds; the work it depends on is the month of enumeration before it. Reversing that order is how a payroll notification, an applicant tracking system or a monitoring tool starts failing three weeks later, with the cause invisible because nobody is watching the surface that would show it.

A quarantine policy is not a halfway house you can leave running. It routes forged mail to spam, which means a forged message still reaches the recipient's account and can still be found. Quarantine earns its place as a watched stage on the way to reject, where the watching is the point rather than the policy.

How it is used in outbound

Two things about the policy are specific to running outbound from more than one domain.

Every sending domain needs its own DMARC record. The policy on a primary company domain does not extend to a separate sending domain, and a sending domain with no DMARC record at all is a worse signal than one sitting at p=none. On an inventory that grows, this is the record most often missed, because provisioning a domain and publishing three records are two different jobs and only one of them is visible in a campaign tool.

Enforcement on the primary domain is an argument for separate sending domains rather than against them. A strict policy on the domain your contracts and invoices come from is exactly right. Outbound runs on separate domains so that a reputation problem in one place cannot reach the other, and each of those carries its own records and its own policy.

The rollout order is the same everywhere and the only real variable is how long each stage lasts. Publish p=none with a reporting address that somebody reads. Spend a month enumerating every source sending as the domain from the aggregate reports, which is the stage worth extending rather than shortening. Authenticate or retire each source. Move to quarantine and watch, then to reject, adding np= for non-existent subdomains. The quarantine versus reject decision covers the second half of that in detail, and the scanner warning about a policy not being enabled covers what the finding means when a tool raises it.

Before moving a domain off p=none

• ✓Yes: A reporting address is published and reports are actually arriving
• ✓Yes: Every legitimate sending source has been identified in those reports
• ✓Yes: Each of those sources produces an aligned pass on your domain
• ✓Yes: Somebody owns the reports after enforcement, not only before it
• ✓Yes: The SPF record still evaluates inside its ten-lookup limit
• ✕No: The rollout plan is built around stepping a percentage upward
• ~Depends: Subdomains need a policy different from the parent

The habit that makes enforcement safe is reading the reports before rather than during. After enforcement, an unknown source is a support ticket from a colleague whose payroll notification vanished. Before it, the same source is a line in a report with a message count beside it. The reports contain no message content, only counts and authentication results per sending address, which is worth knowing before anybody raises a privacy objection to publishing the address.

Related terms

The policy is the third layer of email authentication, sitting above SPF, which authenticates the delivery path, and DKIM, which signs the message. The identity the whole thing exists to protect is the domain in the From header, which is why alignment rather than a raw pass is the test. BIMI is the visible reward for reaching an enforcing policy, and it is gated on exactly this tag. Sending domain is the object a policy belongs to, and domain reputation is what authentication makes legible rather than positive.

The short version

A DMARC policy is the p= tag in a DMARC record, and it tells receivers what to do with mail that failed authentication and alignment for your domain. None takes no action and exists so you can enumerate your own senders. Quarantine treats failures as suspicious. Reject refuses them. A published record satisfies the compliance bar; only an enforcing one protects the domain, and the work between the two is reading reports rather than editing DNS. Give every sending domain its own record, and build the rollout on the current specification rather than on the percentage stepping it removed.

RevenueFlow runs cold email and LinkedIn outreach for B2B teams on infrastructure we authenticate and monitor ourselves, one message per campaign. If you would rather not own that layer, see how the campaigns work.

Verified as of mid-2026 against RFC 9989 and Google's sender guidelines. Verify current requirements with the source before making DNS changes.