← Frankys Web GitHub Contact
Frankys Web Mailtools

Check and understand email configurations

Spoofing Protection Check

MX, SPF, DMARC and DKIM evaluated together: is sender spoofing rejected?

With sender spoofing, someone sends email that looks like it came from your domain in the From field, without you having sent it. Whether that succeeds does not depend on a single record, but on how SPF, DKIM and DMARC work together: SPF and DKIM alone can only mark a message, not reject it, DMARC is what actually enforces that. This tool does not just check whether the individual records exist and are syntactically valid (the individual SPF Check, DMARC Analyzer and DKIM Lookup tools already do that), it puts the results in relation to each other and gives a clear verdict.

What this tool checks

Four conditions must all be met for direct spoofing of the sender address to be reliably rejected: first, the DMARC policy must be p=reject, because only that forces a rejection at the recipient; p=none only monitors and p=quarantine merely moves mail to the spam folder. Second, SPF should end in ~all (SoftFail), not -all (HardFail): with an enforced DMARC policy in place, DMARC takes over actual enforcement via alignment, an additional -all can instead unnecessarily lock out forwards and mailing lists, because SPF practically always fails on a forwarded message. Third, DKIM needs a key with at least 2048 bits (RSA) or an Ed25519 key; a shorter RSA key is considered insecure. Fourth, MX, SPF, DMARC and DKIM must have no syntax or configuration errors, a typo in a record can completely undermine the policy's effect. The DKIM selector is optional: without one, the tool tries common standard selectors. Not finding one is not proof that DKIM is missing, but without a confirmed DKIM record the tool cannot call the domain "protected", so the overall verdict stays red with a note to enter the real selector from an email and check again.

Reading the result

Green means: all four conditions are met, direct spoofing of the sender address is reliably rejected at the recipient. Yellow means: the domain is largely protected, but there is room for improvement, for example SPF on -all instead of ~all, a missing MX record, or DMARC on p=quarantine instead of p=reject. Red means: a hard criterion is not met, for example DMARC without an enforcing policy, a too weak SPF policy, a too short DKIM key, or no DKIM selector found (then enter the real selector from an email above and check again); direct spoofing is then wholly or partially possible, or not conclusively ruled out. The resolved tree below additionally shows each individual check with its own findings; for a deep dive into one specific area, use that individual tool.

Background

SPF is defined in RFC 7208, DKIM in RFC 6376, DMARC in RFC 7489. Only DMARC connects SPF and DKIM with an enforceable rule: a recipient checks whether SPF or DKIM are aligned with the visible sender domain, and only then applies the DMARC policy. Without DMARC, an SPF fail or a missing DKIM signature remains just one of many signals in a spam filter for the recipient, not a reliable rejection. The recommendation of ~all over -all once DMARC is enforced is not an RFC requirement but a practically established trade-off: DMARC already protects reliably, an additional -all adds little value but a real risk for legitimate forwards.

Common problems and how to fix them

  • DMARC is set to p=none. This is the common monitoring stage, but without enforcement. After an observation period using the rua reports, gradually raise it to p=quarantine and then p=reject.
  • SPF ends in -all instead of ~all. Technically stricter, but unnecessarily risky for forwards once DMARC is already enforced. Switch to ~all.
  • SPF ends in ?all or has no trailing all at all. This allows practically any sender, SPF then has almost no effect. Add a trailing ~all or -all.
  • DKIM key under 2048 bits. Considered insecure against modern attacks. Switch to 2048-bit RSA or Ed25519 at the next key rotation.
  • No DKIM record under a standard selector. Many providers use their own, non-guessable selectors, this is not proof that DKIM is missing. Take the real selector from the DKIM-Signature header of one of your own emails, enter it in the "DKIM selector" field above, and check again.

Common questions

Why aren't SPF or DKIM alone enough against spoofing?
SPF and DKIM can each only provide one signal (sender IP authorized, or signature valid). Whether a recipient rejects a non-matching message because of that, sends it to spam, or merely marks it, is decided only by the DMARC policy.
Why does the tool recommend SPF ~all instead of -all, even though -all is stricter?
With DMARC enforcement (p=reject) in place, DMARC already handles enforcement via SPF or DKIM alignment. An additional -all then adds little value, but can lock out legitimate forwards and mailing lists, because SPF practically always fails when a message is forwarded through a foreign server.
Why is the result only yellow even though DMARC is set to p=reject?
At least one of the other criteria is not ideal, for example SPF on -all instead of ~all or a missing MX record. The details below show exactly what is missing.
Why is the result red when no DKIM selector is given, even though DKIM might be set up?
Without a selector, the tool only tries common standard selectors. Not finding one does not prove DKIM is missing, many providers use their own selectors. But without a confirmed DKIM record the tool cannot give a reliable 'protected' verdict. Enter the real selector from the DKIM-Signature header of an email (field s=) above and check again.
What is the difference to Domain Check?
Domain Check shows MX, SPF, DMARC, DKIM, MTA-STS and SMTP side by side as a general health overview. The Spoofing Protection Check focuses on exactly one question, is direct spoofing of the sender address rejected, and specifically relates SPF, DMARC and DKIM to each other for that.
Does a green result also cover display-name spoofing or lookalike domains?
No. It only checks whether the exact sender domain in the technical From header can be forged. A misleading display name or a similar-looking but different domain (e.g. with swapped letters) are outside what SPF, DKIM and DMARC address at all.