SPF, DKIM and DMARC checker

What the three records do, in one paragraph each

SPF is a list, published in DNS, of the servers allowed to send mail for your domain. A receiving server looks at the domain in the envelope sender, fetches the list and checks whether the connecting IP address is on it. It is a TXT record that starts with v=spf1 and ends with a verdict for everything not listed: -all for reject, ~all for soft fail.

DKIM puts a cryptographic signature in a header of every message. The signature names a selector, and the receiver fetches the matching public key from a TXT record at selector._domainkey.yourdomain. If the key verifies the signature, the message was signed by someone holding the private key and was not altered on the way. The selector is chosen by whoever signs, which is why a checker cannot always guess it.

DMARC ties the two together. It says which of SPF and DKIM must pass and align with the visible From domain, and what receivers should do with mail that fails: nothing (p=none), spam folder (p=quarantine) or refuse (p=reject). It also asks receivers to send you reports, which is the only way to learn who else is sending as your domain.

The mistakes this page looks for

Most failures are small and are found by reading the records rather than by sending test mail.

• Two SPF records. Adding a second TXT record when you add a new mail service is the classic accident. A domain may publish exactly one; with two, SPF returns a permanent error for every message.
• More than ten DNS lookups. Each include, a, mx, ptr, exists and redirect counts, and so does every one inside an included record. Past ten the check fails. Marketing platforms, CRMs and help desks each bring their own includes, so the budget runs out quietly. The checker follows includes to estimate the count.
• +all or no all at all. A record ending in +all authorises the whole internet. A record with no ending verdict says nothing about strangers.
• DMARC stuck on p=none. It is the right place to start and the wrong place to stay: nothing is blocked while it is there. Read the aggregate reports, fix the senders that fail, then move to quarantine and reject.
• A 1024-bit DKIM key. It still validates but is considered weak. Rotate to 2048 bits, publishing the new selector before switching signing over.
• A DMARC record with no rua address. You are then enforcing a policy blind.

Why DKIM sometimes shows as not found

A DKIM key lives at a name that includes a selector, and DNS cannot list the names under a domain. This page tries the selectors that the common providers use by default (google, selector1 and selector2 for Microsoft 365, s1, s2, k1, default and a few more). If your sender uses another, open any message you received from the domain, look at the DKIM-Signature header and copy the value after s=. Paste it into the selector box and run the check again.

Some providers publish the key as a CNAME to their own record. That is normal and works the same way; the checker reads the final TXT answer.

From a one-off check to something that tells you

Authentication records change for ordinary reasons: a new newsletter tool, a migrated mailbox, a DNS provider switch that drops a record. They also change when someone makes a mistake. A DNS monitor in Tenium can watch the SPF and DMARC TXT records and alert when the value stops matching what you expect, with the old and new text in the message (see DNS monitoring). It starts on the Starter plan. For the lower-level record views, the SPF lookup, DMARC lookup and DKIM lookup pages show the raw answers.

This tool reads public DNS from your browser. It does not send test mail, cannot see your sending reputation, and says nothing about whether a specific message was delivered. For that you need the message headers and your provider's logs.