Email DNS checker
Look up a domain's SPF, DKIM and DMARC records and find out, in plain language, whether they are doing their job.
Enter a domain to check its email records.
What the three records do
SPF is a list of the servers allowed to send mail using your domain. It lives in a TXT record at the domain itself, starts with v=spf1, and ends with an all mechanism saying what to do about everyone not on the list. -all means reject them, ~all means treat them as suspicious, and ?all means no opinion — which is nearly the same as having no record. +all means anyone at all may send as you, and is almost always a mistake. One more rule catches people out: a domain may have exactly one SPF record. Two is a permanent error, and receivers stop evaluating rather than picking one.
DKIM is a signature. Your mail server signs outgoing messages with a private key and publishes the matching public key in DNS, so a receiver can confirm the message really came from you and was not altered on the way. The key lives at selector._domainkey.yourdomain, where the selector is a label your provider chooses — which is why this tool has to guess or be told. There is no way to list the selectors a domain uses; DNS will answer a question but will not tell you which questions to ask.
DMARC ties the other two together. It lives at _dmarc.yourdomain, and it tells receivers what to do when a message fails both checks: p=none means do nothing and just report, p=quarantine means send it to spam, and p=reject means refuse it outright. A rua= address gets you the aggregate reports, which is how you find out who is sending as you before you tighten the policy.
The usual order of doing this is: publish SPF and DKIM, publish DMARC at p=none with a rua= address, read the reports for a few weeks until nothing legitimate is failing, and only then move to quarantine and reject. Skipping to reject on day one is how a company discovers that its invoicing system was sending mail nobody knew about.
Where the lookups go
This site has no server to run the queries on — it is static files on a CDN. So the lookups happen in your browser, over DNS-over-HTTPS, against Cloudflare's public resolver at https://cloudflare-dns.com/dns-query. The domain you type goes to Cloudflare, exactly as it would if you had run dig TXT example.co.za from your own machine, and it does not go to iamlukia.com at all. Google's resolver at https://dns.google/resolve speaks the same JSON API and works as a drop-in replacement if you would rather use that one.
Two caveats worth knowing. Results come from a public resolver's cache, so a record you changed in the last few minutes may not show up yet. And internationalised domains are converted to their punycode form before the query, so a domain with accented characters will appear in the results as its xn-- equivalent — that is the real name as far as DNS is concerned.
This one exists because migrating a domain's mail to ProtonMail meant an evening in a text editor comparing TXT records by eye. Turning it into a page took about as long as doing it by hand twice more would have.