The Email Authentication Checker reviews the DNS records commonly used for SPF, DKIM, and DMARC. It is designed to help you verify published policy before you troubleshoot a real message.

What to enter?

Use the sending domain you control. For DKIM, you also need the exact selector used by the sending platform. A selector copied from another service will return a misleading “missing” result even if your real mail is signing correctly.

How to interpret SPF?

SPF authorizes sending infrastructure for a domain. Check the mechanisms/includes against every legitimate sender you use. A syntactically valid SPF record can still be operationally wrong if a service is missing, an include no longer exists, or too many DNS lookups are required.

How to interpret DKIM?

A DKIM public key in DNS proves only that the key is published. Send a message through the platform and inspect the receiving system’s Authentication-Results to confirm that the message was actually signed and verified with the expected selector/domain.

How to interpret DMARC?

DMARC evaluates aligned SPF/DKIM for the visible From domain and can publish reporting/enforcement policy. Start with monitoring where appropriate, review legitimate senders, and move to stronger policy only after you understand the reports. Do not jump to p=reject merely because a checker shows all records present.

Common failure patterns

  • Two SPF records instead of one combined policy.
  • DKIM selector mismatch between DNS and the sending service.
  • DMARC From-domain alignment failure despite an SPF pass on a different envelope domain.
  • Old marketing/support platforms still sending mail after being removed from the SPF policy.

Limitations

This tool checks published DNS configuration; it cannot prove deliverability, reputation, inbox placement, or the authentication result of a message you have not actually sent.