Complete DMARC Guide

Domain-based Message Authentication, Reporting and Conformance (DMARC) tells receiving mail servers what to do when SPF or DKIM fail, and whether the authenticated domain aligns with the visible From domain. SPF and DKIM by themselves do not enforce policy: they produce pass/fail results, but receivers decide how to act. Attackers can still spoof your domain because there is no instruction to reject or quarantine messages that fail authentication. DMARC closes that gap.

For founders: DMARC protects your brand from impersonation. Phishing that uses your domain becomes easier for receivers to block. For IT admins: DMARC gives you reporting visibility and policy control. You see which mail passes or fails and can move from monitoring to enforcement at your own pace. This guide covers record structure, policy levels, alignment, reporting, and how to deploy without breaking legitimate mail.

What DMARC is and why it exists

Email spoofing works because the From header is easy to forge. A receiver can see that a message claims to be from your domain, but SPF and DKIM alone do not say "reject this if it fails." Without DMARC, receivers fall back to heuristics—reputation, content filters—which are inconsistent and can miss phishing. DMARC standardizes the instruction: if authentication fails or alignment fails, apply this policy (none, quarantine, or reject).

Brand protection is the main driver. Phishing that spoofs your domain damages trust and can lead to customer loss or compliance issues. DMARC reduces that risk by giving receivers a clear, cryptographically-backed policy. Authentication alignment ensures the domain that passed SPF or DKIM matches the visible From domain. If a message passes SPF for a subdomain but From shows your root domain, DMARC can treat that as an alignment failure and apply your policy.

How DMARC works in practice

When a message arrives, the receiver performs SPF and DKIM checks first. DMARC does not replace them; it interprets their results.

Flow: Sender → Receiving server → SPF check → DKIM check → Alignment check → Policy evaluation. DMARC passes only if at least one of SPF or DKIM passes and the aligned domain matches the From domain. If both fail, or both pass but neither aligns, DMARC fails.

For SPF alignment: the Return-Path domain (SPF auth domain) must align with the From domain. For DKIM alignment: the d= domain in the DKIM signature must align with the From domain. Alignment can be relaxed (allows organizational subdomains) or strict (exact match). DMARC pass means at least one auth method passed and aligned. DMARC fail means no pass+align, and your policy (p=none, p=quarantine, p=reject) determines what the receiver does.

DMARC record structure

DMARC is a DNS TXT record at _dmarc.yourdomain.com. Required tag: v=DMARC1. Policy tag p= is also required.

• v= — version; must be DMARC1
• p= — policy for failed alignment (none, quarantine, reject)
• rua= — comma-separated URIs for aggregate reports
• ruf= — URIs for forensic (failure) reports
• pct= — percentage of failed mail to apply policy to (1–100); default 100
• sp= — policy for subdomains (none, quarantine, reject)
• adkim= — DKIM alignment mode (r=relaxed, s=strict)
• aspf= — SPF alignment mode (r=relaxed, s=strict)
• fo= — forensic report options (0, 1, d, s)

v=DMARC1; p=none; rua=mailto:dmarc@example.com

DMARC policy levels

p=none

Monitoring only. Receivers do not change handling based on DMARC failure. Use this when you are collecting data and fixing auth issues. Reports (if rua is set) show what would fail under quarantine or reject.

p=quarantine

Failed messages are typically delivered to spam or a quarantine folder. Receivers decide the exact handling, but the intent is "treat as suspicious." Use quarantine before reject to catch edge cases without dropping legitimate mail.

p=reject

Receivers should reject or drop failed messages. Strongest protection but highest risk: if legitimate senders are not authenticated or aligned, their mail can be rejected. Move to reject only after quarantine shows no false positives.

For detailed tradeoffs, see DMARC policy: none vs quarantine vs reject.

DMARC alignment

Alignment means the domain that passed SPF or DKIM matches the domain in the From header. Relaxed alignment (default) allows organizational equivalence: mail.example.com aligns with example.com. Strict alignment requires an exact match: mail.example.com does not align with example.com.

adkim=r and aspf=r set relaxed alignment for DKIM and SPF. Use relaxed unless you have a reason to require strict. Many providers sign with a subdomain (e.g. selector._domainkey.mail.example.com) and strict alignment would cause unnecessary failures. See DMARC alignment failed and DMARC aspf and adkim explained for more detail.

DMARC reporting

Aggregate reports (rua) — XML summaries of authentication results. Reporters send them to the address(es) you specify. They include volume, pass/fail counts, source IPs, and alignment outcomes. Use them to see which senders pass or fail and to tune SPF, DKIM, and DMARC before enforcing.

Forensic reports (ruf) — Individual failure reports. Contain message-level detail; not all reporters support them, and they can include PII. Use ruf if you need per-message diagnosis; otherwise rua is enough for most deployments.

Reports are sent by receiving domains, not by you. Gmail, Microsoft, and others send to the mailto: URIs in rua. See DMARC aggregate reports explained and DMARC fo tag explained for tag details. If reports are not arriving, see DMARC reports not working.

DMARC deployment strategy

Start with p=none and rua= set. Monitor for at least 1–2 weeks. Use reports to find failing sources: third-party senders, ticketing systems, marketing platforms. Fix SPF and DKIM for those senders so they pass and align.

Move to p=quarantine once failures drop to an acceptable level. Some use pct= to apply quarantine to a percentage first. Stay in quarantine until reports show no false positives. Then move to p=reject.

Jumping straight to reject without monitoring breaks mail. Legitimate senders you forgot—newsletters, support tools, partners—will fail. The reports you get in p=none are essential. See DMARC pct tag explained for gradual rollout options.

Common DMARC mistakes

• Enabling reject too early. Move to p=reject only after reports confirm no legitimate traffic will be dropped.
• Ignoring aggregate reports. Reports reveal unknown senders and alignment problems. Review them before changing policy.
• Missing DKIM alignment. If you rely on SPF only, a single misconfigured forward or relay can break alignment. Ensure DKIM is set up and that the signing domain aligns.
• Broken SPF records. SPF permerrors or multiple SPF records invalidate your auth. Fix SPF before tightening DMARC.
• Not accounting for third-party senders. Marketing platforms, CRM email, support tools—each must be authorized in SPF and ideally signed with DKIM. Add them before enforcement.
• Subdomain policy mismatch. Use sp= to set subdomain policy. See DMARC sp subdomain policy explained.

DMARC record examples

Monitoring policy

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Enforcement policy

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

Subdomain policies

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@example.com

The root domain uses p=reject; subdomains use sp=quarantine. For more examples, see DMARC record examples.

Troubleshooting DMARC failures

1. Run a live check. Use our domain checker to confirm your DMARC record is published and valid.
2. Ensure exactly one DMARC record. Multiple records cause undefined behavior—see multiple DMARC records found.
3. Verify SPF and DKIM. DMARC fails when both fail or when neither aligns. Fix auth first.
4. Check alignment. The Return-Path domain (SPF) and d= domain (DKIM) must align with From. Use relaxed unless you need strict.
5. Review aggregate reports. They show which sources fail and why. Fix those senders before changing policy.
6. Confirm third-party senders. Add their includes to SPF and ensure they sign with DKIM using an aligned domain.

Best practices

• Always start with p=none and rua. Collect data before enforcement.
• Fix SPF and DKIM before tightening DMARC. Auth must pass and align.
• Use relaxed alignment (adkim=r, aspf=r) unless you have a specific need for strict.
• Maintain an inventory of all services that send mail for your domain. Update it when you add or change providers.
• Move quarantine → reject only after reports show no false positives.
• Use sp= to set subdomain policy explicitly. Subdomains default to the root policy if sp= is omitted.

Related DMARC deep dives

Go deeper on specific topics:

Return to the DMARC Hub for the full troubleshooting index.