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. A second tag, pct, used to set what percentage of failing mail the policy covered; the current specification removed it. That 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."

RFC 7489, the 2015 specification it replaced, worded the same three values as requests. Under it, none meant the Domain Owner "requests no specific action be taken regarding delivery of messages", quarantine meant it wished to have failing email "treated by Mail Receivers as suspicious", and reject meant it wished "for Mail Receivers to reject email that fails the DMARC mechanism check". The newer wording describes what the Domain Owner thinks of failing mail, where the older one described what it asked receivers to do.

Value	RFC 7489 (2015)	RFC 9989 (2026)
none	"requests no specific action be taken regarding delivery of messages"	"offers no expression of preference"
quarantine	wants failing mail "treated by Mail Receivers as suspicious"	"considers such mail to be suspicious"
reject	wants receivers "to reject email that fails the DMARC mechanism check"	considers failures "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. When one check passes and aligns, DMARC passes and the policy is never consulted; only when both fail does the p tag decide between no action, suspicious and refused.

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.

What is pct in DMARC?

pct is the percentage tag of RFC 7489, the 2015 DMARC specification. It took a whole number from 0 to 100, defaulting to 100, and asked receivers to apply the p= policy to only that percentage of messages failing DMARC. RFC 9989, the Proposed Standard that replaced RFC 7489 in May 2026, removed the tag, and its IANA table now lists pct as historic.

RFC 7489 defined it as the "Percentage of messages from the Domain Owner's mail stream to which the DMARC policy is to be applied", and gave its purpose: "to allow Domain Owners to enact a slow rollout enforcement of the DMARC mechanism." Its section on message sampling says the receiver "MUST NOT enact the requested policy" on more than the stated percent. Mail left outside the sample was handled one step down. Under quarantine, a receiver "SHOULD apply local message classification as normal" to it; under reject, it "SHOULD treat the email as though the "quarantine" policy applies". Reports were never sampled: every relevant message still had to appear in them.

So the common values read like this under RFC 7489. p=quarantine; pct=50 asked for no more than half of failing mail to be quarantined. pct=25 and pct=10 stepped the same policy in at a quarter and a tenth. p=reject; pct=25 rejected up to a quarter and quarantined the rest. pct=0 asked for the policy itself on none of it, which under reject still meant treating all of it as quarantine, and pct=100 is the default, the same as leaving the tag out.

RFC 9989's Appendix A.6, on the removal of the tag, explains why. "Operational experience showed that the "pct" tag was usually not accurately applied, unless the value specified was either 0 or 100 (the default)". The value 0 had also taken on a life of its own: some intermediaries and mailbox providers read it as a signal to deviate from standard handling, "usually by rewriting the RFC5322.From header field". The new text therefore "introduces the "t" tag as shorthand for "testing", with the valid values of "y" and "n", which are meant to be analogous in their application by mailbox providers and intermediaries to the "pct" tag values "0" and "100", respectively." With t=y, a quarantine policy is applied as none and a reject policy as quarantine; t=n is the default.

On the IETF datatracker, the address of the working group draft, draft-ietf-dmarc-dmarcbis, now shows RFC 9989: "RFC - Proposed Standard (May 2026)", obsoleting RFC 7489 and RFC 9091. A record that still carries pct does not break, because the specification says "Unknown tags MUST be ignored." It simply stops meaning anything to a receiver that follows the new text. The full tag list is in the DMARC record guide.

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.

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. The classic rollout stepped a quarantine policy upward by percentage. RFC 9989 lists pct among the tags removed, 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, and because receivers ignore tags they do not recognise, 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.

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. RFC 9989 draws the line between the two report types itself: aggregate reports give "some limited insight into email sending patterns", while it is failure reports that carry message contents, which most Mail Receivers refuse to send "out of privacy concerns". That 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.

Specification text is quoted from RFC 7489 and RFC 9989, and the requirement from Google's sender guidelines. Verify current requirements with the source before making DNS changes.