DMARC policy: none, quarantine, or reject?

DMARC policy tells receiving mail systems what to do when a message fails DMARC. Start by understanding your legitimate senders before moving from monitoring to enforcement.

Use the DMARC Checker

What each DMARC policy does

A DMARC record publishes a policy at the domain level. With p=none, a receiving system is asked to monitor failures without applying enforcement. With p=quarantine, failing mail is treated as suspicious. With p=reject, the receiving system is asked to reject failing mail.

The policy is not a guarantee that every receiver will behave identically. It is a public instruction that works alongside SPF and DKIM alignment checks.

Why p=none is not the same as protection

p=none is useful while you learn which systems legitimately send mail for the domain. It can help prevent an enforcement policy from disrupting valid messages too early.

Because it does not request quarantine or rejection, p=none should be treated as a monitoring stage rather than the final protection level. CloudSpex reports p=none as a warning so it is not mistaken for full enforcement.

A safe progression

Inventory every legitimate sender first: your mailbox provider, support desk, marketing platform, transactional email service, and any application that sends on your behalf. Confirm that each source has the intended SPF and DKIM configuration.

Review DMARC reports or your mail-provider evidence, then move in small steps. A common sequence is p=none, then p=quarantine, then p=reject once legitimate traffic is understood. Do not copy a policy from another domain without checking its sending services.

Check whether a DMARC record is present and which policy it publishes.
Confirm SPF and DKIM are configured for legitimate senders.
Review legitimate mail before changing enforcement.
Publish a stricter policy only after the sending inventory is understood.
Recheck the public record after DNS changes propagate.

Common mistakes

Treating a syntactically present record as complete protection is a common mistake. A p=none policy is intentionally weaker than quarantine or reject.

Another mistake is enabling reject while an overlooked service still sends unauthenticated mail. That can interrupt wanted mail, so ownership and change control matter as much as the DNS record itself.

Frequently asked questions

Is p=none a valid DMARC policy?

Yes. It is valid for monitoring, but it does not ask receivers to quarantine or reject failing mail.

Which DMARC policy is strongest?

p=reject is the strongest of the three policy values, but it should be used only after legitimate senders have been checked.

Does CloudSpex change my DMARC record?

No. CloudSpex reads public DNS signals and does not change DNS or email settings.

Use public checks as a starting point

CloudSpex reads limited public-facing signals. It does not change DNS, website, certificate, or email settings. Confirm the responsible provider and test relevant changes before applying a remediation.