Free Email DNS Check

What this checks

Email authentication is four DNS records working together. SPF lists the servers allowed to send for your domain. DKIM publishes the public key that verifies the signature on each message. DMARC tells receivers what to do when SPF and DKIM fail and where to send reports. MX tells senders where to deliver replies. A domain with three of the four in place still gets spoofed, still lands in spam at some receivers, or still loses replies; the whole set matters.

This check runs all four for the domain you type, in one request, against public DNS resolvers (1.1.1.1 and 8.8.8.8). The SPF check follows every include and counts lookups against the limit of 10. The DMARC check reads the policy and falls back to the organisational domain for a subdomain. The MX check sorts the mail servers and names the provider. The DKIM check uses the selector you give it, or tries the 33 common selectors our Chrome extension probes, after the other three have run, so a long SPF chain is never cut short by selector guesses. Each part is the same code as the single checkers on this site, so a card here and the full result on the tool's own page always agree.

The result is a grade from A to F, a short headline, the first thing to fix, and one card per record with its findings. Each finding links to the explanation on that record's own page, which also runs the single check for the same domain.

How the grade works

The grade is the same one our Chrome extension gives, so a domain scores the same in the popup and on this page. Each record has a weight: SPF 30, DMARC 30, DKIM 25, MX 15. A record that passes earns its full weight, a warning earns half, a fail or a missing record earns nothing. The score is the share of the weight earned, out of 100, and the letter follows from it: A from 90, B from 75, C from 60, D from 40, F below that.

Two cases are treated specially. When DKIM is not verified, meaning no key was found under the selectors tried, it is left out of the score entirely, because not finding a key under guessed names proves nothing; the headline says so and asks for your selector. When one of the checks gets no answer from DNS, the grade is withheld rather than guessed, and the result is kept for only a few seconds so a re-check gets fresh data.

Pass at the top means a grade of A. Warning means B or C: the basics work, but something should be tightened. Fail means D or F: most of the protection is missing. Missing means the domain itself does not exist in public DNS.

A check got no answer

One or more of the four checks did not get an answer from our resolvers, so its card says "could not check" and the grade is withheld. This says nothing about your records. The result is cached for only twenty seconds; re-check in a minute.

DKIM is not counted

No DKIM key was found under the selectors tried, so DKIM is left out of the score and the other three records decide the grade. Providers like Amazon SES and Ackuna use random selectors that a sweep cannot find. Enter your selector in the field above, or on the DKIM checker, to get it counted.

The domain does not exist

Public DNS has no entry for the domain at all, so none of the four records can exist. The check stops after the first lookup. Check the spelling, or wait if the domain was registered minutes ago.

Reading the four cards

SPF. The card shows the record, the lookup count out of 10, and the include tree. The common problems are a missing record, more than one record, more than ten lookups, and a record that ends in +all or has no all at all. The SPF checker explains every finding.

DMARC. The card shows the policy (none, quarantine or reject), whether reports are switched on, and whether the record was inherited from the organisational domain. A missing record and p=none are the usual findings; both leave the domain spoofable. The DMARC checker explains the tags.

DKIM. The card shows each key found with its size and flags, or "not verified" with the list of selectors tried. A short key, a revoked-only selector, a dangling alias and the testing flag are the real findings. The DKIM checker explains them and takes your selector.

MX. The card shows the mail servers by priority and the provider. A domain that only sends can have no MX or a null MX; a domain whose users expect replies needs real records that resolve. The MX checker explains the fallback rules.

How to fix it

1. Start with the card marked "fix first". It is the worst finding of the worst card, and usually the one that matters most for delivery: no SPF, no DMARC, a DKIM key that fails, a dead mail server.
2. Publish SPF if it is missing: one TXT record on the apex, v=spf1 followed by one include: per service you send through, ending in ~all. Keep it under ten lookups.
3. Set up DKIM at every service that sends for you and publish the records they give you, each under its own selector. Then enter the selector here to confirm it verifies.
4. Publish DMARC at _dmarc.yourdomain.com, starting with p=none and a rua= address so you receive reports, and move to quarantine and then reject once the reports show your real mail passing.
5. Fix MX last: real records if the domain receives mail, a null MX if it never should.
6. Re-check after DNS has propagated, usually within an hour. Results here are cached for five minutes.

If you send with Ackuna: add your domain in the console and Ackuna hands you the SPF include, the three DKIM CNAME records and a DMARC record to publish, verifies all of them, and keeps re-checking them, so you find out if a later DNS edit breaks one. Newsletters and transactional mail through the SMTP relay share the one verified domain.