DMARC

DMARC is an email authentication policy that uses SPF and DKIM alignment to protect your domain from spoofing and to tell receivers what to do with messages that fail.

DMARC (Domain-based Message Authentication, Reporting, and Conformance), Definition & Examples

Definition & Examples

What is DMARC?

DMARC is an email authentication protocol that tells receiving mail servers how to handle messages that fail SPF or DKIM. It helps prevent domain spoofing and phishing and improves email deliverability.

How it works

DMARC is configured with a DNS TXT record at _dmarc.{your-domain}. In plain terms: it’s a small text rule you add to your domain settings that tells inbox providers what to do with suspicious mail and where to send feedback reports.

• Pass rule: a message passes DMARC if at least one of SPF or DKIM passes and aligns with the visible From domain. If neither passes in alignment, the message fails DMARC and your policy (none, quarantine, or reject) applies.

• Policy (p): chooses how strictly to treat failures.

  • none: deliver mail normally and send reports so you can see issues.

  • quarantine: send likely-fake mail to spam/junk.

  • reject: block failing mail outright. Use after you’ve fixed alignment.

• Alignment (adkim, aspf): makes the visible From: domain match the domains used by DKIM and/or SPF.

  • Relaxed (r): allows a subdomain match (mail.from example.com can match dkim d=mail.example.com).

  • Strict (s): requires an exact match; reduces spoofing but needs tighter setup.

  • Why it matters: without alignment, attackers can pass SPF/DKIM from another domain while spoofing your From: address.

• Reporting (rua, ruf): asks inbox providers to send you DMARC reports.

  • Aggregate (rua): daily machine-readable summaries (XML) showing who sent mail claiming your domain, pass/fail counts, and top sources. Use a dedicated inbox or a report viewer because these files are frequent and verbose.

  • Forensic (ruf): per-message samples when failures occur. Not all providers send these; use only if you need deep investigation.

• Rollout (pct): applies your policy to only a percentage of mail (for example, pct=20) so you can tighten enforcement gradually and watch the impact.

• Scope (sp): lets you set a different policy for subdomains (for example, news.example.com) if they’re operated by vendors or have different risk.

Example (quarantine with gradual rollout):

v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s

Useful tags at a glance: p, sp, rua, ruf, adkim, aspf, pct, fo, ri.

Why it matters

• It prevents spoofing and phishing by requiring that the domains in SPF and DKIM match the visible From address.

• It can improve inbox placement when it is configured correctly and you monitor the reports.

• It protects your domain reputation with mailbox providers across regions and services.

• It meets evolving sender requirements (see Google’s bulk sender guidelines).

Examples / Use cases

• Start with p=none (monitoring) so legitimate mail keeps flowing while you identify senders that need SPF and DKIM fixes.

• Add a reporting address, for example rua=mailto:[email protected]. This lets you see who is sending as your domain, which messages pass or fail, and where failures are coming from.

• Tighten alignment (adkim=s and aspf=s) once all legitimate senders are configured. Then move to quarantine, and later to reject to actively block spoofed messages.

• Verify your DNS setup with a DMARC checker such as Loops’ Bounce Doctor to catch typos and duplicate-record issues early.

Example DMARC TXT record (monitoring):

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1; adkim=s; aspf=s

DMARC policy options:

• none: delivers mail and sends reports. Best for discovery and fixing alignment.

• quarantine: moves failing mail to spam/junk. Use when most legitimate traffic aligns and stragglers are rare.

• reject: blocks failing mail. Use when you’re confident all legitimate mail aligns.

DMARC vs SPF vs DKIM

Common pitfalls

• Enabling p=reject too early: blocklists legitimate mail before you’ve fixed alignment; start with p=none and review reports first.

• Missing alignment: the visible From domain must match your SPF/DKIM domains; otherwise DMARC will fail even when SPF/DKIM individually pass.

• Not monitoring reports: without rua and an inbox to receive them, you can’t see who is sending mail as your domain or where failures occur.

• Multiple/conflicting records: only one TXT record at _dmarc.example.com should exist; duplicates cause providers to ignore DMARC.

• Wrong host or type: DMARC must be a TXT at _dmarc.example.com (not at the root, and not a CNAME).

• Ignoring subdomains: if vendors send from subdomains, set sp to a suitable policy so their traffic isn’t accidentally blocked.

• Overly relaxed alignment: stay on relaxed while you configure third-party senders, then move to strict to further reduce spoofing.

Related terms

• SPF

• DKIM

• Email deliverability

• Inbox placement

Key takeaways

• DMARC builds on SPF and DKIM to add policy, alignment, and reporting.

• Begin with monitoring (p=none), then move to stricter policies as issues are resolved.

• Proper DMARC improves deliverability and meets modern sender requirements.