DMARC Policy Simulator

It shows how a receiver evaluates DMARC for a message: whether DKIM or SPF passed and aligned with your From: domain, and what policy you'd be requesting for a failure (p, or sp/np for subdomains). You enter a policy and a sender scenario and see the DMARC result plus the reasoning — before you publish anything. DMARC decides the result and the requested action, not final delivery (the receiver decides that).

Moving from p=none to quarantine or reject is the step people hesitate on: if a legitimate sender isn't covered by your SPF or aligned DKIM, its mail starts going to spam or bouncing the moment you flip the policy. Simulating each of your senders first shows which ones would break, so you can fix them before you enforce instead of hearing it from angry recipients.

DMARC passes when at least one authenticated identifier — a DKIM signature or SPF — both passes and aligns with the From: domain. A message can carry several DKIM signatures; one aligned, passing signature is enough. DKIM alignment compares the signing domain (d=) to the From: domain; SPF alignment compares the envelope-from to the From: domain. Relaxed alignment (the default) matches at the organizational-domain level (so mail.example.com aligns with example.com); strict requires an exact match. If nothing passes-and-aligns, DMARC fails and your policy is what you're requesting.

RFC 9989, published in 2026, is the current DMARC standard and obsoletes RFC 7489. It removes the pct tag (receivers implemented percentage sampling inconsistently) and replaces its testing role with t=y, which asks receivers to apply one policy level lower than published (reject→quarantine, quarantine→none). It also replaces Public-Suffix-List org-domain discovery with a DNS Tree Walk and adds the np and psd tags. This tool defaults to RFC 9989 and offers a legacy RFC 7489 mode for the older pct behavior many receivers still honor.

sp sets a separate policy for subdomains; np sets a policy specifically for non-existent subdomains, a common spoofing vector. t=y (RFC 9989) is test mode: receivers apply one level below your published policy, so you can publish p=reject while you confirm your real senders. The old pct tag that used to serve this rollout role was removed by RFC 9989 — switch to legacy RFC 7489 mode to model it.

No. DMARC decides authentication pass/fail and the policy you request — it does not decide final delivery. Under RFC 9989 the receiver applies policy at its own discretion, and spam filtering, sender reputation, content and local rules still decide inbox placement. A pass means DMARC won't be the reason your mail is quarantined or rejected; it isn't a delivery guarantee.

Forwarding usually breaks SPF (the forwarder isn't in your SPF record) and mailing lists often modify the message so DKIM breaks too — so DMARC fails. Many receivers recognize these cases and deliver anyway; that's receiver discretion, which RFC 9989 explicitly allows, not a rule. The simulator shows it as an override you shouldn't rely on — which is why you validate with your real reports, not assumptions.

The simulation itself runs entirely in your browser — no account, no upload, nothing stored — and the Copy share link button encodes your inputs in the URL, so a colleague opens the exact same scenario without anything touching a server. The one exception is the optional Fetch button, which looks up a domain's public _dmarc record over DNS; pasting a record instead keeps everything offline. To move from one-off what-ifs to your actual senders, free domain monitoring ingests your DMARC reports and tells you when you're ready to enforce.