Guide

How to Set Up DMARC: The Complete Guide

DMARC tells receiving servers what to do when email fails authentication — monitor, quarantine, or reject. This guide covers everything from adding your first record to reaching p=reject safely.

Updated March 19, 2026

DMARC is where email authentication stops being “we have TXT records” and becomes “here is what receivers must do when mail fails.” If you only read one sentence: do not skip SPF and DKIM. DMARC is the policy layer on top — not a substitute for either. The DMARC glossary entry spells out the vocabulary; this guide is the operational walkthrough. Use domainpreflight.dev for day-to-day checks and the DMARC Report Analyzer when XML lands in your inbox.

What DMARC actually does

Receivers already check SPF and DKIM. DMARC adds three things: a published policy (p=none, quarantine, or reject), alignment rules (SPF and/or DKIM must align with the From domain), and optional reporting (aggregate XML to a mailbox you control). Policy is what most people mean when they say “we turned on DMARC.” Reporting is how you prove legitimate senders are aligned before you tighten policy.

Think of DMARC as a contract. You publish what you want receivers to do. They compare results against your From: domain. Misaligned mail can be treated as suspicious or rejected — depending on policy and receiver implementation. That is why “DMARC pass” is not one checkbox; it is SPF/DKIM pass plus alignment under your record.

Receivers may apply policy differently for subdomains (sp=) or use local heuristics beyond DMARC. Your job is to make legitimate mail pass and align; anything else should show up clearly in aggregate reports so you can decide whether to quarantine or reject.

The three components you need first

You need SPF (who may send for your domain), DKIM (cryptographic signatures), and DMARC (policy + reporting). Order matters operationally: fix SPF and DKIM until real mail passes, then layer DMARC. Our SPF guide and DKIM guide cover the mechanics. If either is broken, DMARC will surface failures in reports — which is useful — but you should not advance policy until senders align.

Common mistake: publishing DMARC while marketing mail still sends from a subdomain without DKIM or with SPF that does not include the ESP’s include. You will see volume in reports with spf=fail or dkim=fail. Fix the sender configuration first; the DMARC fix hub links provider-specific steps.

Another mistake: assuming Google Workspace or Microsoft 365 “handles everything.” Third-party CRMs, support desks, invoice tools, and AWS SES all add sending paths. Each path needs SPF includes and/or DKIM keys aligned to the From domain you use in campaigns. Inventory before policy — spreadsheets are boring and lifesaving.

Adding your first DMARC record

Create a TXT record at _dmarc.yourdomain.com (some UIs show “host” as _dmarc only). Start with monitoring — p=none — and always include a mailbox for aggregate reports.

rua= is where daily aggregate reports go. Use a dedicated address (or alias) and confirm the mailbox receives mail. fo=1 requests failure reports when either SPF or DKIM fails — helpful during rollout. adkim and aspf set relaxed vs strict alignment; relaxed is typical for first deployments. Document the record in your runbook; you will change p= later.

Exact syntax reference also lives on our DMARC DNS record page. If your DNS host splits name/value oddly, paste the full string into one TXT value field.

Validate propagation: query _dmarc from multiple resolvers after publish. TTLs can delay visibility; do not panic-change the record twice in an hour unless you confirmed a typo.

Reading your aggregate reports

Reports are gzip’d XML from large providers. You can grep them — or use a parser. The fastest path for humans is DomainPreflight’s DMARC Report Analyzer: paste XML, see pass/fail by source IP and aligned domains. That beats staring at raw files when you are answering “who is sending as us?”

When you review reports, tag each source: legitimate (keep), third-party (add include or DKIM), unknown (investigate), malicious (plan for reject once legit mail is clean). Link this work to the p=none still a problem discussion — monitoring without eventual enforcement leaves spoofing on the table.

Pay attention to volume spikes from unexpected ASNs. A small amount of spoofing is normal for large brands; sustained spoof volume deserves incident response. Cross-check with abuse desk contacts at major receivers when needed.

Fixing alignment failures

Alignment means the SPF domain or DKIM signing domain matches the organizational domain in the From: header (per your relaxed/strict settings). Failures show up as aligned=no in tooling even when SPF or DKIM “passes” for a different domain.

Fix paths: add missing SPF includes, enable DKIM at the ESP, align From: addresses with authenticated domains, or use a subdomain strategy. Our DMARC fix collection points to provider guides (Google, Microsoft, SendGrid, etc.). Work one sender at a time; re-check reports after DNS TTLs.

Strict alignment (adkim=s / aspf=s) breaks more legitimate setups — only enable when you understand subdomains and envelope domains. Most orgs stay relaxed until mature.

Moving from p=none to p=quarantine

Upgrade when reports show consistent alignment for all known senders and you have a rollback plan. Quarantine sends failing mail to spam at many receivers — softer than reject. Use pct= to sample (e.g. pct=25 then increase) if your risk tolerance requires it. Communicate with internal teams before you flip; helpdesk volume spikes when one forgotten newsletter source breaks.

Document the change window. Keep screenshots of DMARC record before/after. If something screams, revert p= to none temporarily — data beats pride.

Moving from p=quarantine to p=reject

Reject is the end state for spoofing defense: failing mail should not be delivered. Confirm no critical systems send unaligned mail. Watch transactional paths (receipts, password resets) especially. Keep rua= active — you still want visibility. Large providers have pushed stricter expectations; see Google DMARC enforcement (2024) for why “eventually” is now “soon.”

Some mail still bypasses strict DMARC (direct server-to-server edge cases). Reject raises the bar; it does not replace fraud training or attachment policies.

The complete rollout timeline

Week 1: Publish p=none, validate mailbox receives reports. Week 2–3: Eliminate alignment failures for known apps. Week 4: Evaluate quarantine if clean. Week 5–6: Ramp pct for quarantine or move to full quarantine. Week 7–8: Plan reject after no surprises. Longer if you have many ESPs or acquisitions. This is a guideline — not a law — but rushing policy without data breaks mail.

Enterprise tip: maintain a spreadsheet of sending services, owner, SPF includes, DKIM selectors, and last report date. Tie changes to CAB tickets. When someone says “email stopped,” you open DMARC reports first.

Forensic reports (ruf=) are optional and often ignored by receivers for privacy reasons. Do not block a rollout on ruf; lean on aggregate data and message headers. If legal needs message-level samples, use controlled testing in your own tenant instead of expecting global ruf delivery.

Step by step