DMARC p=none vs Quarantine vs Reject: Which Policy to Use

The three policies

• p=none — monitor only. Receivers deliver failing mail as they normally would, but send you reports. It gives visibility and meets the Gmail, Yahoo and Microsoft minimum for bulk senders, but offers no protection against spoofing.
• p=quarantine — failing mail should be treated as suspicious, which in practice means the spam or junk folder. Spoofed messages are hidden but still delivered somewhere.
• p=reject — failing mail should be refused during the SMTP conversation, so it never reaches the recipient at all. This is full protection and the end goal for most domains.
• Receivers treat the policy as a strong request, not a command. Some may quarantine where you asked for reject, or apply local overrides for mailing lists, but the major providers broadly honour it.

A complete DMARC record, tag by tag

A DMARC record is a TXT record at _dmarc.yourdomain.com. A typical production example: v=DMARC1; p=quarantine; sp=reject; pct=100; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; fo=1

• v=DMARC1 — required, and must be first.
• p= — the policy for the domain itself.
• sp= — the policy for subdomains (anything.yourdomain.com). If omitted, subdomains inherit p=. Setting sp=reject is a cheap way to stop spoofing of subdomains you never send from.
• pct= — the percentage of failing mail the policy applies to, from 0 to 100 (default 100). With p=quarantine; pct=25 only a quarter of failures are quarantined; the rest are handled as the next weaker policy. The updated DMARC specification replaces pct with a simpler t= testing flag, but pct is still widely honoured today.
• rua= — where aggregate reports (daily XML summaries per sending source) are sent. This is the tag you actually need.
• ruf= — where failure (forensic) reports for individual messages go. Many large receivers no longer send these for privacy reasons, so do not rely on them.
• adkim= and aspf= — alignment mode for DKIM and SPF: r for relaxed (default) or s for strict.
• fo= — when failure reports are generated (0 = both fail, 1 = either fails). Only matters if you use ruf.

Alignment: relaxed vs strict

DMARC passes only when SPF or DKIM passes and the domain it authenticated is aligned with the visible From: domain. SPF authenticates the Return-Path (envelope sender) domain; DKIM authenticates the d= domain in the signature.

Relaxed alignment means the organisational domains must match: mail From: billing@yourdomain.com with DKIM d=mail.yourdomain.com aligns. Strict alignment requires an exact match, so that example would fail. Relaxed is the right default for nearly everyone; strict only makes sense if you deliberately isolate subdomains and control every sender precisely.

This is why a newsletter platform that signs with its own d=platform.com passes DKIM but still fails DMARC for you — the domains are not aligned. The fix is to set up that platform’s custom DKIM for your domain.

Sending reports to another domain

If rua= points to an address on a different domain (a reporting service, for example), the receiving domain must publish an authorisation record, or receivers will silently skip your reports. For yourdomain.com reporting to reports.example.net, example.net must publish a TXT record at yourdomain.com._report._dmarc.example.net with the value v=DMARC1. Reporting services set this up for you; it matters when you point reports to your own second domain.

A safe rollout plan

• Week 0: publish v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Make sure SPF and DKIM already pass for your main mailbox provider.
• Weeks 1–4: read the aggregate reports (an XML viewer or a free DMARC report parser helps). List every source sending as your domain: mailbox provider, CRM, helpdesk, invoicing, website forms, marketing tool.
• For each legitimate source, enable custom DKIM on your domain and add it to SPF if needed, until it shows aligned passes in reports.
• When legitimate sources are consistently passing: move to p=quarantine; pct=25, then 50, then 100 over a few weeks, watching reports and asking colleagues about missing mail.
• Finally move to p=reject (start again at a lower pct if you are cautious). Keep rua= in place permanently so you notice when someone adds a new tool without authenticating it.
• Add sp=reject early if you never send from subdomains — it closes a common spoofing gap at no risk.

Checking your record

Typos in DMARC are common: a missing semicolon, p= placed before v=, or a record published at the domain root instead of _dmarc. Look it up with our free DNS checker after every change. HavitoMail provides a ready DMARC value for each domain in its DNS wizard and checks that it is published, which makes p=none on day one trivial; tightening to quarantine and reject is then up to you as your reports confirm every sender is aligned.