How To Set Up DMARC (and What p=none, quarantine, and reject Mean)

DMARC is one of the three core email authentication standards — alongside SPF and DKIM — that tells receiving mail servers what to do when an email claims to come from your domain but fails authentication checks. Setting it up correctly protects your domain from spoofing and improves deliverability. But the policy you choose matters a great deal, and picking the wrong one too early can cause legitimate mail to disappear silently.

This guide walks through how DMARC works, how to publish a DMARC record, and exactly when to use each policy level.

What DMARC Actually Does

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It builds on SPF and DKIM by adding two things:

• Alignment: DMARC checks that the domain in the visible From address actually matches the domain that passed SPF or DKIM. Without this check, a sender could pass SPF on a background domain while spoofing a completely different From address.
• Policy enforcement: It tells receivers what to do with mail that fails — monitor it, send it to spam, or reject it outright.

It also enables aggregate reporting, which is genuinely useful. Receiving servers send you daily XML reports showing which IP addresses are sending mail as your domain and whether that mail is passing authentication. This visibility is hard to get any other way.

The DMARC DNS Record

A DMARC record is a TXT record published at _dmarc.yourdomain.com. A minimal example looks like this:

_dmarc.yourdomain.com TXT v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

The key tags to understand:

• v=DMARC1 — required, identifies the record as DMARC.
• p= — the policy: none, quarantine, or reject.
• rua= — where aggregate reports are sent. Include this from day one.
• ruf= — where forensic (per-failure) reports go. Optional, and many providers no longer send them due to privacy concerns.
• pct= — the percentage of failing mail the policy applies to. Defaults to 100. Useful for gradual rollout.
• sp= — separate policy for subdomains, if you want different treatment.

Before you publish DMARC, make sure SPF and DKIM are already set up and passing for your primary sending streams. DMARC without working authentication underneath it will generate failures immediately.

p=none: Monitor Without Enforcing

With p=none, receivers take no action on mail that fails DMARC. It still lands in the inbox (or spam, based on other signals) exactly as it would without DMARC. The only thing that changes is you start receiving reports.

This is the right starting point for almost everyone. Before you enforce anything, you need to understand your full sending landscape. That means every ESP, CRM, marketing platform, transactional email provider, and any third party sending on behalf of your domain. They all need to be covered by your SPF record or signing with DKIM before you tighten policy.

Spend at least two to four weeks at p=none, reviewing aggregate reports carefully. Look for legitimate sending sources you might not have accounted for — internal tools, HR software, customer support platforms. Missing even one before moving to enforcement will cause that mail to be quarantined or rejected.

p=quarantine: Send Failures to Spam

With p=quarantine, mail that fails DMARC is directed to the recipient's spam or junk folder rather than the inbox. It is not outright rejected — it still arrives, just flagged.

Move to quarantine once your reports show that all legitimate mail is passing authentication consistently. If you have a complex sending setup or multiple providers, use the pct= tag to roll out gradually. For example, pct=10 applies the quarantine policy to only 10% of failing mail, letting you catch unexpected problems before full enforcement.

Common reasons mail fails at this stage include third-party senders not yet added to your SPF record, services signing with DKIM under their own domain rather than yours, or forwarding scenarios where SPF breaks in transit.

p=reject: Full Enforcement

With p=reject, receiving servers are instructed to refuse delivery entirely for mail that fails DMARC. This is the gold standard for domain protection. It means a fraudster cannot send phishing email that appears to come from your domain and have it delivered anywhere that respects DMARC — which includes all major providers like Gmail, Outlook, and Yahoo.

Only move to reject when you are confident that every legitimate sending source is authenticated. The consequences of moving too fast are real: legitimate transactional mail, password resets, or invoice emails can be silently dropped at the receiving server with no bounce back to you.

If your domain is exclusively used for receiving mail and you never send from it, you can jump straight to reject safely. Parked domains and non-sending domains are actually a common spoofing target, so locking them down at reject (with v=DMARC1; p=reject;) is good practice even without going through a phased rollout.

A Realistic Rollout Sequence

• Confirm SPF and DKIM are set up and passing for all your sending services.
• Publish DMARC at p=none with an rua address you actually monitor.
• Review aggregate reports for two to four weeks. Identify and fix any failing legitimate sources.
• Move to p=quarantine, optionally starting at pct=10 and increasing gradually.
• Once reports are clean, move to p=reject.

If you are unsure where your domain currently stands, the free deliverability checker from Rainmail will show you your SPF, DKIM, and DMARC configuration and flag anything that needs attention before you tighten your policy.

One Common Mistake to Avoid

The most frequent error is publishing p=reject before auditing all sending sources. The second most frequent is publishing DMARC without an rua address, which means you collect no reports and have no visibility into what is actually happening. Always include reporting from the start — it is the only way to make informed decisions about when it is safe to advance your policy.

Done correctly, DMARC is not complicated. It just requires patience in the monitoring phase. The senders who run into trouble are almost always those who skip p=none and go straight to enforcement on day one.