Quick answer
A DMARC policy of reject (p=reject) tells a receiving mailbox provider to refuse any message that fails the DMARC check, so a spoofed message using your domain never reaches the inbox or the spam folder (RFC 7489 §6.3). It is the strongest of the three DMARC policy modes. The p= tag is required in every DMARC record and carries one of three values, each a request to the receiver:
p=none: you request no specific action. Mail that fails DMARC is delivered as it would be without DMARC, and you only receive reports. This is monitor-only.p=quarantine: you ask the receiver to treat failing mail as suspicious. In practice that means the spam or junk folder, so the message is still delivered but out of the inbox.p=reject: you ask the receiver to refuse failing mail outright, at the SMTP layer, so it is never delivered anywhere.
A record that publishes the strictest policy looks like this:
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
The p=reject there is the disposition; the rua= address is where the receiver sends the aggregate reports you use to watch the effect. This page is one of the email authentication reference spokes; to see what policy a domain currently publishes, run the DMARC checker.
What each mode asks the receiver to do
When a message fails DMARC, the receiver looks up your policy and applies the disposition you published (RFC 7489 §6.6.2):
p= value | What you request | Where failing mail ends up |
|---|---|---|
none | No action; report only | Delivered as normal (inbox), reported to rua= |
quarantine | Treat as suspicious | Spam or junk folder |
reject | Refuse the message | Rejected in the SMTP transaction, not delivered |
The difference between quarantine and reject is what survives. Quarantine keeps a copy the recipient can still find in a junk folder; reject removes that option entirely, because the receiving server declines the message before it is ever stored. Both are enforcing policies relative to none, which changes nothing about delivery and exists only so you can collect data first.
A DMARC verdict only bites when a message fails, and failure means the message is not aligned on either the SPF or the DKIM identifier. Legitimate mail that aligns passes DMARC regardless of your policy, so a well-configured domain can sit at p=reject without losing its own mail.
A DMARC policy is a request, not a guarantee
Publishing p=reject does not force any receiver to reject your failing mail. The policy is a request, and the receiver decides. RFC 7489 §6.7 is explicit: "Final disposition of a message is always a matter of local policy." A receiver may accept a message that fails even when you asked for reject, or refuse a message that passes, based on its own reputation signals and filtering.
In practice the large mailbox providers honor p=reject and p=quarantine closely, which is why enforcement works. But a receiver applies its own logic on top of your policy: it may quarantine rather than reject during a ramp, or override your policy for mail arriving through a known mailing-list path. Treat your DMARC policy as the instruction most receivers follow, not a switch that is guaranteed to block every spoof everywhere. If a domain publishes no DMARC record at all, there is no policy to request and receivers fall back to their defaults, which is the gap covered in no DMARC record found.
sp=: a separate policy for subdomains
The optional sp= tag sets the policy for subdomains of the domain that published the record, separately from the p= policy that governs the domain itself (RFC 7489 §6.3). It takes the same three values as p=.
- If
sp=is present, subdomains use it and ignorep=. - If
sp=is absent, subdomains inherit thep=policy.
This matters because attackers often spoof a subdomain that was never used for mail, such as mail.example.com or invoices.example.com. A DMARC record on the organizational domain covers those subdomains through sp= (or through p= when sp= is omitted), so you do not need a separate record on each one. Publishing sp=reject on the organizational domain is a common way to enforce on every non-sending subdomain at once while you keep a looser policy on the parent while it is still ramping. Which domain counts as the organizational domain, and how alignment is judged against it, is covered in DMARC alignment.
pct=: sampling, and why it is deprecated
RFC 7489 §6.3 defined the pct= tag as the percentage of failing mail, from 0 to 100, to which the receiver applies the policy, defaulting to 100 when omitted. The idea was a gradual ramp: p=quarantine; pct=25 asked receivers to quarantine a quarter of failing mail and leave the rest at the next-lower policy, so you could enforce on a slice and watch the reports before going all the way.
Be careful here, because the guidance has changed. The DMARC revision known as DMARCbis (which obsoletes RFC 7489) removes the pct= tag entirely. It is superseded by a testing signal (t=) rather than percentage sampling. So while pct= is still described in the current published standard and older receivers understand it, it is on its way out and you should not build a new rollout around it. The durable way to ramp is to change the policy itself, one step at a time, from none to quarantine to reject. The sequence and its timing are covered in moving DMARC from p=none to p=reject.
Reading the effect of your policy
Whatever policy you publish, the way you tell it is working is the aggregate reports the rua= address collects. They show how much mail is passing and failing DMARC, per sending source, before and after you tighten the policy. Walking through one is covered in how to read a DMARC aggregate report.