p=none vs quarantine vs reject

22 June 2026 · 5 min read

The p= tag in your DMARC record tells receivers what to do with mail that fails DMARC. p=none asks them to take no action and only report. p=quarantine asks them to treat failing mail as suspicious, which usually means the spam folder. p=reject asks them to refuse failing mail outright. Start at none, fix every legitimate sender until your reports are clean, then move to quarantine and finally reject.

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

The three policies compared

Receivers are not obliged to follow your policy. The current DMARC standard, RFC 9989, describes the policy as the domain owner's preference, and says failing mail is handled under each receiver's own local policies. Large mailbox providers do act on it: Microsoft 365, for example, rejects mail that fails a p=reject policy during SMTP when its recommended Honor DMARC record policy setting is on.

p=none: monitor only

Under p=none, a message that fails DMARC is handled exactly as if you had no DMARC record. Its value is the reporting: with a rua= address, receivers send you daily aggregate reports listing every source that sent mail as your domain and whether it passed SPF and DKIM with alignment. That is how you find the marketing platform, CRM, billing tool or office server that sends as you without proper authentication.

The risk is staying there. A domain at p=none can still be spoofed, because you have asked receivers not to act on failures. Gmail, Yahoo and Outlook.com accept p=none for their bulk sender rules, but meeting that rule is not the same as being protected. Why p=none gives a false sense of security covers this.

p=quarantine: treat failures as suspicious

Under p=quarantine, you tell receivers you consider failing mail suspicious. RFC 9989 leaves the handling to them; in practice it usually means the spam or junk folder. The message is not destroyed, and a recipient can still find it.

This is the first policy that protects you, and for some domains it is a reasonable place to stay. RFC 9989 says domains whose users post to mailing lists SHOULD NOT publish p=reject: a list that edits messages breaks the DKIM signature, and because the list sends from its own servers, SPF cannot rescue the message. If that describes your domain, p=quarantine may be the right end point.

p=reject: refuse failing mail

Under p=reject, receivers refuse mail that fails DMARC, usually during the SMTP conversation, so it reaches neither the inbox nor the spam folder. It is the only policy that stops exact-domain spoofing outright, which is what protects your customers and suppliers from invoice fraud and phishing in your name.

The cost of a mistake is higher: a legitimate sender that is not aligned has its mail bounced. That is why you only move to reject once your reports show every legitimate source passing.

Moving safely from none to reject

1. Publish p=none with a rua address. Build the record with the DMARC generator.
2. Read the reports. List every legitimate sender and whether it passes SPF or DKIM with alignment. The DMARC report analyser turns the XML into a per-source view, and reading your first DMARC report explains the fields.
3. Fix alignment for each legitimate sender. Usually this means completing DKIM setup at the sending platform so it signs with your domain. Check with the DKIM checker and SPF checker.
4. Move to p=quarantine. RFC 9989 suggests at least a month at p=none, then a similar period at p=quarantine, comparing the reports.
5. Move to p=reject once quarantine has run without legitimate mail failing.

pct= has gone; use t=y

Older guides ramp enforcement with pct=25, pct=50 and so on. RFC 9989 removed the pct= tag. In its place is a test flag, t=y, which asks receivers to apply one level less than the policy you publish:

So v=DMARC1; p=reject; t=y; rua=... asks for quarantine while you watch the reports, and removing t=y turns on full rejection. The flag does not change reporting, and it has no effect with p=none.

Subdomains and domains you do not send from

• sp= sets the policy for existing subdomains. If you leave it out, subdomains use p=.
• np=, added by RFC 9989, sets the policy for subdomains that do not exist in DNS. If you leave it out, sp= applies, then p=. Setting np=reject stops attackers inventing subdomains such as billing.example.com to send from.
• Domains that never send mail can go straight to p=reject, with v=spf1 -all as their SPF record, because no legitimate mail should fail.

Common mistakes

• Staying at p=none indefinitely. The record is present, but your domain is still spoofable.
• Jumping straight to p=reject. Without reading the reports first, you will bounce your own mail from senders you did not know about.
• Keeping pct= in the record. It has been removed from the standard. Use t=y for trials.
• Copying adkim=s or aspf=s from an example. Strict alignment fails subdomain senders that relaxed alignment, the default, would pass.

Check your current policy with the DMARC checker. If you would rather have the staged move from p=none to p=reject handled for you, hosted DMARC publishes the record, stages the policy from p=none to p=reject and ingests the reports for you. For the end-to-end method, read how to reach p=reject without breaking email.