Email Auth Checker (SPF / DKIM / DMARC)

Check the three DNS records that decide whether your email is trusted: SPF, DKIM and DMARC. If any of them is missing or misconfigured, legitimate mail can be marked as spam or rejected outright — and attackers can spoof your domain. Enter a domain to see what it publishes today.

Why legitimate email lands in spam

Mail providers cannot see your intent — they only see signals. The strongest signals are the three authentication records below. When a message arrives, the receiver asks: did it come from a server the domain authorises (SPF)? Is it cryptographically signed and unchanged (DKIM)? Does the domain publish a policy for messages that fail those checks (DMARC)? If the answers are missing, inconsistent or fail, the message loses trust and is more likely to be filtered.

The most common self-inflicted problems are: no SPF record at all; SPF that lists a sender you forgot to include (so mail fails); a record with too many DNS lookups; DKIM keys that are rotated without updating DNS; and DMARC left at p=none forever, which monitors but never protects. Each of these is visible in the results above.

SPF — Sender Policy Framework

SPF is a TXT record starting with v=spf1 that lists which servers may send mail for your domain. It is checked against the sending server's IP and is the most important (and most fragile) record. Issues that break SPF:

• More than one SPF record. RFC 7208 allows exactly one. Duplicates cause a PermError and SPF is not evaluated at all.
• Too many DNS lookups. Mechanisms like include, a, mx, ptr and exists each cost a lookup, and the limit is 10. Beyond that, receivers return PermError.
• A missing or unsafe all. End with -all (hard fail) if only your listed servers send mail; ~all is a softer fallback. +all is dangerous — it authorises the whole internet.

DKIM — DomainKeys Identified Mail

DKIM adds a cryptographic signature to each message. The public key that verifies it is published in DNS at <selector>._domainkey.yourdomain. Receivers look up the selector named in the message's DKIM-Signature header. If the key is missing, rotated out of date, or the record is malformed, signatures fail to verify. A record with an empty p= tag means the key has been deliberately revoked. Because selectors are free-form, there is no way to guess them all — provide yours if the tool does not find it automatically.

DMARC — Domain-based Message Authentication

DMARC is a TXT record at _dmarc.yourdomain that tells receivers what to do when SPF or DKIM fails, and where to send reports. The key tag is p=:

• p=none — monitor only. Mail that fails is still delivered. Good for a start, weak as an end state.
• p=quarantine — failing mail goes to spam.
• p=reject — failing mail is rejected. This is the goal.

Add rua= to receive aggregate reports and see who is sending as you; that data is what lets you move confidently from none to reject.

Fixing the most common problems

1. Publish one SPF record. Merge duplicates into a single v=spf1 … record and end it with -all or ~all.
2. Include every legitimate sender. Add include: entries for your mail provider, newsletter service and CRM, then re-check.
3. Keep SPF under 10 lookups. If you are over, flatten includes (host their SPF content on your own domain) or split senders across subdomains.
4. Turn on DKIM at your mail provider and publish the public key it gives you. Rotate keys by adding a new selector first, then removing the old one.
5. Add DMARC. Start at p=none with a rua address, read the reports, then tighten to quarantine and finally reject.

Privacy and limits

This tool only reads public DNS TXT records. It performs standard DNS queries for the domain, _dmarc and a set of common DKIM selectors, then analyses the results. No mail is sent and nothing is stored beyond a short-lived cache. Requests are rate-limited per IP address.