Email Spoofability Checker
Answers one specific question: if someone forged an email with a "From" address on this domain and sent it through their own infrastructure — not yours — what would actually happen to it? Rejected outright, dumped in spam, or delivered to the inbox looking completely legitimate? This is the exact scenario behind CEO-fraud and vendor-impersonation phishing, and it's almost always a DNS configuration problem, not a mail server problem.
Why this isn't the same question as "is DKIM set up"
It's tempting to treat SPF, DKIM and DMARC as one bundle you either have or don't, but for the specific question of forged mail, they don't carry equal weight. An attacker forging your domain's "From" address doesn't have your DKIM private key, so their message was never going to pass DKIM — that check fails by default, every time, regardless of your configuration. What actually determines the outcome is SPF (does their sending server appear on your authorised list — it won't, by definition) combined with DMARC (does anything actually enforce that failure, or just log it). DKIM matters enormously for deliverability and for proving your own legitimate mail wasn't tampered with in transit, but it isn't the lever that stops a naive spoofed message — DMARC is.
Reading the verdict
- Wide open — SPF explicitly allows all senders (
+all). Vanishingly rare, and about as bad as email security misconfigurations get. - High risk — no DMARC record, or DMARC set to
p=none. SPF can fail on the forged message all it wants; nothing tells the receiving server to actually act on that failure, so plenty of mail providers deliver it anyway. - Partially protected — DMARC set to
p=quarantine, orp=rejectwithpctbelow 100. Forged mail is likely to land in spam rather than the inbox, or only some percentage of it gets the strict treatment. - Well protected — DMARC set to
p=rejectat full enforcement. Mail servers that honour DMARC (the large majority, including Gmail and Outlook) should reject the forgery before it's ever delivered.
The domain that never sends email is often the one that gets spoofed
The scenario that catches people out isn't the primary company domain — it's the parked domain, the old rebrand, the marketing-only subdomain that was never configured to send mail at all and was therefore never locked down either. If a domain isn't supposed to send email, the fix is a two-line DNS change: v=spf1 -all and a DMARC record of v=DMARC1; p=reject;, which together tell every receiving server "nothing legitimate will ever come from here, reject all of it." It costs nothing, breaks nothing, and closes off a domain that would otherwise sit there as an open invitation for phishing infrastructure.