Email Authentication Lab
Everyone knows they should get to DMARC p=reject. Almost nobody does, because they are afraid of blocking their own mail. Publish an SPF record, a DKIM key and a DMARC policy, deliver real-looking legitimate and spoofed messages, and watch exactly what reaches the inbox. By the end you will know why forwarded mail survives on DKIM and why reject is safe once your DNS is right.
Goal
You run your own mail server and send marketing through an ESP. Publish SPF for both, publish your DKIM key, and move DMARC to reject so the three spoofs are stopped while all legitimate mail — including the message a customer auto-forwarded — still gets delivered.
Your published DNS
SPF — authorise your sending sources
v=spf1 include:own-mx._spf.you.com -allDMARC policy
_dmarc.you.com TXT v=DMARC1; p=none; rua=mailto:dmarc@you.comScore vs goal
Tune your DNS, then deliver the messages.
The key insight
DMARC passes if either SPF or DKIM aligns. That is why a forwarded message — which breaks SPF at the new hop — still gets delivered when DKIM is published: the signature survives forwarding. Skip DKIM and you reject your own forwarded mail.
Live now
4 rolling out DMARCsenders warming up…
What this lab is
- A free SPF/DKIM/DMARC lab: publish your own email-authentication DNS and deliver labelled messages through a simulated receiver.
- You control the SPF record (which sending sources are authorised), whether your DKIM key is published, and your DMARC policy (none / quarantine / reject).
- Each message is graded on SPF alignment, DKIM alignment and the resulting DMARC verdict — then dispositioned to inbox, spam or reject.
- It shows the lesson that trips teams up: DMARC passes if either SPF or DKIM aligns, so a forwarded message survives on DKIM even though SPF breaks.
- Goal-based scenarios: stop exact-domain, return-path and subdomain spoofs while keeping all legitimate mail — including auto-forwarded mail — deliverable.
Frequently asked questions
What is the Email Authentication Lab?
A free, in-browser simulation of SPF, DKIM and DMARC. You publish the DNS a domain owner controls — an SPF record listing authorised sending sources, a DKIM signing key, and a DMARC policy — then deliver a set of labelled legitimate and spoofed messages through a modelled receiver and see exactly why each one lands in the inbox, in spam, or is rejected.
How does DMARC decide?
DMARC passes when at least one of SPF or DKIM both passes and aligns with the From domain. SPF alignment needs the Return-Path domain to match From; DKIM alignment needs the signature d= to match From. If DMARC fails, the receiver applies your published policy: p=none still delivers (monitor only), p=quarantine sends to spam, p=reject blocks it. The lab computes all of this per message.
Why does a forwarded message break SPF but still pass?
When a mailbox auto-forwards, the message is re-sent from the forwarder’s servers, so the sending IP no longer matches your SPF record and SPF fails. DKIM, however, signs the message content, and that signature travels with the mail — so if your DKIM key is published, DKIM still aligns and DMARC passes. This is the single most common reason teams are scared to move to p=reject, and the lab lets you see it is safe once DKIM is in place.
Is this a real mail server?
No. It is a teaching model of the SPF/DKIM/DMARC decision. It abstracts away DNS lookups, cryptographic verification and ARC so the alignment logic and policy trade-offs are clear. Domains, sources and messages are invented.