Check your domain's email authentication

Enter a domain and the checker looks up five things in public DNS: the SPF record, DKIM keys, the DMARC record, MX records, and whether your domain's mail server is on any of four blocklists. You get a score out of 100, a pass or fail for each part, and a fix for every authentication record that's missing. It takes about ten seconds and asks for nothing but the domain.

SPF: which servers may send as you

SPF is a TXT record on your domain listing the servers allowed to send mail for it. The checker reads it and flags the mistakes that break it most often: no record at all; more than one record, which is a failure because a domain may only have one; a record ending in +all, which lets anyone send as you; a record that doesn't end in -all or ~all; and so many includes that it risks going past the ten DNS lookups SPF allows.

DKIM: a signature on every message

DKIM adds a cryptographic signature to each message. Receivers verify it against a public key published in your DNS under a name called a selector. Because nobody can list a domain's selectors from outside, the checker tries 19 that common email providers use, such as google, selector1, selector2, k1 and default. If your provider uses a custom selector, the check can report DKIM as missing when it is set up correctly. You can't enter your own selector here, so confirm it from the headers of a message you sent.

DMARC: what happens when checks fail

DMARC is a TXT record at _dmarc.yourdomain.com. It tells receivers what to do with mail that fails authentication, and asks them to send you reports. A message passes DMARC when SPF or DKIM passes for a domain that matches the one in the visible From address. The checker shows your policy: p=none only monitors, p=quarantine asks for failing mail to be treated as suspicious, usually the spam folder, and p=reject asks for it to be refused. It also flags a record with no rua address, because without one no reports reach you. When they do arrive, the DMARC report analyser reads them.

MX records and blocklists

MX records name the servers that receive mail for your domain. Without them you can't receive replies, and DMARC reports sent to an address on the domain go nowhere. For blocklists, the checker takes a mail server from your MX records, looks up its IP address and queries Spamhaus ZEN, SpamCop, Barracuda and PSBL. If the domain has no MX record there is no server to look up, so that row says Not checked rather than passing.

How the score is worked out

Every domain starts at 100. A missing SPF, DKIM or DMARC record costs 25 points each. A missing MX record costs 10, and so does a DMARC policy of p=none. Each SPF problem costs 5, a DMARC record without an rua address costs 5, and each blocklist listing costs 5. 90 or above reads as excellent and under 40 as critical. The score is a summary; the fixes underneath are the part to act on.

Fixing a failing result

For a missing SPF or DMARC record, the result shows the host, type and value to publish. Those values are the ones Email Digit asks its own customers to use: the SPF include authorises our sending service, and the DMARC record sends reports to us. If you send through another provider, use the include it gives you and your own reporting address. If you already have an SPF record, merge into it rather than adding a second. Start DMARC at p=none, which changes nothing about delivery, and move to quarantine and then reject once reports show every service you use passing. DKIM has no generic value, because the key is unique to your domain and comes from whoever sends your mail.

Results are cached for five minutes. If you changed DNS a moment ago, wait a few minutes and run the check again, and allow longer for the change to reach every resolver.