Setup Guides · DMARC

DMARC Setup and Enforcement: From p=none to p=reject, Safely

Publishing a DMARC record takes one TXT entry. Getting to p=reject - the policy that actually stops people spoofing your domain - without quarantining your own mail is the real work. This is the provider-agnostic playbook: what alignment means, every tag in the record, and the enforcement path step by step. For the provider-specific parts, pair it with the Microsoft 365 and Google Workspace DMARC guides.

Last updated 30 August 2026 · applies to any domain, any mail provider

What DMARC actually does

DMARC sits on top of the two checks you may already have - SPF (which servers may send for you) and DKIM (a signature proving a message was not altered) - and adds three things they lack on their own: alignment, a policy, and reporting.

The single idea that trips people up is alignment. SPF and DKIM can each say "pass" for a domain that is not yours - a bulk sender, a forwarder, even a spammer using their own authenticated infrastructure. DMARC ignores whether a check passed and asks a stricter question: did the domain that passed match the domain in your visible From address?

  • SPF alignment - the Return-Path (envelope) domain matches your From domain.
  • DKIM alignment - the signature's d= domain matches your From domain.

A message passes DMARC if it has at least one aligned pass. This is why "DKIM: pass" is not enough on Microsoft 365 or Google Workspace out of the box: the default signature is onmicrosoft.com or gappssmtp.com, which verifies but never aligns with your real domain (see the M365 and Workspace DKIM guides). Fix alignment first; enforce second.

What you need

  • SPF and DKIM already set up and aligned for every service that sends as your domain.
  • Access to your domain's public DNS to publish one _dmarc TXT record.
  • A place to read the aggregate (rua) reports - a free monitor turns the raw XML into plain English.

The DMARC record, tag by tag

A DMARC record is a single TXT record published at _dmarc.yourdomain.com. This is the record you start with:

Name:  _dmarc.yourdomain.com
Type:  TXT
Value: v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r
  • v=DMARC1 - the version. Always first, always this value.
  • p= - the policy: none (monitor), quarantine (spam-folder), or reject (bounce). This is the tag you ramp.
  • rua=mailto: - where aggregate reports are sent. Without this you are flying blind - it is the whole point of the monitoring stage.
  • pct= - the percentage of failing mail the policy applies to (default 100). Historically the way to ramp quarantine gradually, e.g. pct=25. Note the standard changed here: DMARCbis (RFC 9989, May 2026) removed pct= outright and replaced it with the t= testing flag. In practice pct= is still honoured by most receivers today while t= support is still thin, so a percentage ramp remains the pragmatic lever for now - just know it is on its way out.
  • t= - the DMARCbis testing flag that replaces pct=. Be careful with its meaning: t=y does not disable your policy (it is not the old pct=0). RFC 9989 applies the policy one level below the one you declared - so p=reject; t=y behaves as quarantine, and p=quarantine; t=y behaves as none. t=n (default) applies your policy as written. Correct to publish, but receiver support is still thin, so do not rely on it yet.
  • sp= - a separate policy for subdomains. If omitted, subdomains inherit p=. Set sp=reject to lock down subdomains you never send from.
  • np= - a DMARCbis policy specifically for non-existent subdomains (ones with no DNS records). np=reject is the cheapest spoofing defence there is: it costs nothing, needs no monitoring, and instantly shuts down the common trick of inventing a plausible subdomain like billing.yourdomain.com that you never created. Sharper than sp=, which also covers subdomains you do use.
  • adkim= / aspf= - alignment mode, r (relaxed, the default - matches the organisational domain) or s (strict - exact match). Relaxed is right for almost everyone.
  • ruf=mailto: - forensic (per-message failure) reports. Optional, often noisy, and honoured by few receivers; leave it off unless you have a specific need.
One record only

A domain may publish exactly one _dmarc TXT record. If a checker reports two, receivers ignore DMARC entirely - merge them into one.

The enforcement path, step by step

1 Publish p=none with a reporting address

Add the record above with p=none. This changes nothing about your delivery - it only asks the world's receivers to email you a daily report of everything sent as your domain, and what passed SPF and DKIM. It is safe to do during business hours.

2 Collect reports for two to four weeks

Aggregate reports arrive as raw XML from dozens of receivers. Feed them to a monitor that turns them into a plain-English weekly summary of who is sending as you, and whether each source aligns. Postbox DMARC Monitor does this free - add one reporting address and read the digest. Give it a full cycle of your sending so every source shows up: your mail provider, marketing platform, invoicing tool, help desk, CRM.

3 Align every legitimate sender

For each real source in the reports, make sure at least one of SPF or DKIM aligns with your From domain: add the service to your SPF record, or set up branded DKIM for it. This is the step that takes the time - and the step that makes enforcement safe. Do not move on until the reports show every legitimate source passing DMARC.

4 Ramp to p=quarantine

Switch to p=quarantine. To ease in, apply it to a fraction of failing mail first - most receivers still honour pct=25 for this, which is why it remains the practical ramp lever even though DMARCbis has removed it outright in favour of the binary t= flag. Watch the reports for a week or two, raise the percentage, and confirm nothing legitimate is being spam-foldered. Only failing (unaligned, likely spoofed) mail is affected.

5 Move to p=reject

Set p=reject (full coverage is the default, so no percentage tag is needed). Now anyone putting your domain in a From line without your authentication gets bounced at the receiver. This is the enforcement that actually protects your brand from spoofing and phishing - and it is only safe because steps 1 to 4 proved your own mail is aligned. Finish the job on subdomains too: add sp=reject for subdomains you never send from, and np=reject to block spoofed non-existent ones outright.

The failures we keep finding

1. Jumping straight to reject

The most common self-inflicted outage. Almost every domain sends from more services than the owner remembers; enforcing before monitoring bounces that legitimate mail. Always monitor at p=none first.

2. No rua address (or nowhere to read it)

A DMARC record with no rua= is a policy with no visibility - you can never tell whether it is safe to tighten. Publish a reporting address and actually read the reports.

3. Stuck at p=none forever

p=none gives you reports but zero protection - anyone can still spoof you. It is a stage, not a destination. The goal is p=reject; monitoring is how you get there safely, not where you stop.

4. Forgetting subdomains

An enforced apex policy still leaves subdomains open unless you set sp=. Attackers love spoofing mail.yourdomain.com or invoices.yourdomain.com. Set sp=reject for subdomains you do not send from - and add DMARCbis's np=reject, which covers non-existent subdomains an attacker might invent, at zero monitoring cost.

5. A broken SPF record hiding under DMARC

SPF silently permerrors past ten DNS lookups, which counts as a fail for alignment. If reports show SPF failing for mail you know is yours, check the SPF 10-lookup limit before touching the DMARC policy.

Verify it end to end

  • Check the record: the DMARC checker validates syntax, policy and reporting tags; the DMARC generator builds a correct one.
  • Monitor before you enforce: Postbox DMARC Monitor collects the rua reports and shows every source and its alignment - the evidence you tighten the policy on.
  • Confirm on a real message: send one email to Postbox Mailtester - it reports SPF, DKIM, DMARC and whether each aligns to your From domain.

Frequently asked questions

What is the difference between p=none, p=quarantine and p=reject?

p=none is the monitoring stage - receivers take no action and just send you reports. p=quarantine sends failing mail to spam. p=reject bounces it. Move through them in that order, only after reports show every legitimate sender aligned.

Does publishing a DMARC record affect delivery immediately?

Not at p=none - it only requests reports and never changes delivery. Delivery is only affected once you move to quarantine or reject, which is why you monitor first.

What does alignment mean?

DMARC checks whether the domain that passed SPF or DKIM matches your visible From domain. SPF aligns when the Return-Path domain matches; DKIM aligns when the signature d= matches. One aligned pass is enough.

How long should I stay at p=none?

Two to four weeks - a full cycle of your sending - so every legitimate source appears in the reports and you can confirm each is aligned before tightening.

Can I go straight to p=reject?

You can, but you should not. Jumping to reject before monitoring bounces legitimate mail from services you forgot about. Monitor, fix alignment, then ramp.

Provider-specific setup: Microsoft 365 DMARC · Google Workspace DMARC. The DMARC standard is now RFC 9989 (DMARCbis, May 2026), with aggregate and failure reporting split into RFC 9990 and RFC 9991; together they obsolete the original RFC 7489.

Chat with us!