✉️ Email Security Checker

Is Your Email Domain Spoofable?

Check the SPF, DMARC, DKIM and MTA-STS records any domain publishes, and whether they tell receivers to reject mail forged in its name. Enter a domain or an email address.

🛡
Ready to test
Enter a domain above and click “Check Domain”
-
SPF + DMARC /4
Checking domain: -
📬
SPF Record
Sender Policy Framework - specifies which mail servers can send email for this domain
Pending ▼
Enter a domain and run the check to see the SPF record.
🛡
DMARC Policy
Domain-based Message Authentication - what happens to spoofed emails (none/quarantine/reject)
Pending ▼
Enter a domain and run the check to see the DMARC policy.
🔑
DKIM Record
DomainKeys Identified Mail - a signing key in DNS. Checked at twelve common selectors, and not part of the score
Pending ▼
Enter a domain and run the check to see the DKIM record.
📭
MX Records
Mail Exchange records - which servers receive email for this domain, or a null MX saying it takes none
Pending ▼
Enter a domain and run the check to see the MX records.
📮
MTA-STS
Mail Transfer Agent Strict Transport Security - whether a policy that can require TLS for incoming mail is published (its mode is not read)
Pending ▼
Enter a domain and run the check to see MTA-STS status.

Why Email Security Records Matter

Without SPF, DMARC, and DKIM, anyone can send email claiming to be from your domain. This enables phishing attacks and brand impersonation.

The score covers what DNS can show for certain: an SPF record (1 point) that ends in -all (1 more), and a DMARC record (1 point) set to p=reject for all mail (1 more: a pct below 100 rejects only that share, and the rest is quarantined). A bare all means +all - any server may send - and earns nothing. DKIM is reported but not scored, because a key can sit under any selector name and DNS cannot list them. Twelve are asked: default, dkim and mail, and the ones large mail services set up - google (Google Workspace), selector1 and selector2 (Microsoft 365), k1 (Mailchimp), s1 and s2 (SendGrid), fm1 (Fastmail), protonmail (Proton Mail) and sig1 (iCloud). A domain signing under another name reads as not found at these, which does not mean it has no DKIM, and an empty p= is a revoked key, not a key. MTA-STS is reported as published or not: whether its policy enforces TLS is in a file on the domain’s own web server that a page on another site cannot read. A lookup that does not complete is shown as not measured, and then no score is given.

Ideal configuration:

  • SPF: v=spf1 ... -all
  • DMARC: p=reject; pct=100
  • DKIM: selector + public key at _domainkey
  • MTA-STS: v=STSv1; id=... with mode: enforce in the policy file

Try these domains: