Email security check

What the email security check reads

The check reads the three records that decide whether mail claiming to come from a domain is accepted. SPF comes from the TXT records at the domain, DMARC from the TXT record at _dmarc.example.com, and DKIM from a key asked for at seventeen common selectors: default, selector1, selector2, google, k1, mail, smtp, dkim, s1, s2, mandrill, sendgrid, mailgun, zoho, protonmail, amazonses and mailchimp. The MX records are read too. Every query goes to Cloudflare's 1.1.1.1 from the IPVIEW server.

SPF lists the servers allowed to send for the domain; DKIM lets a receiver verify a signature the sending server put on each message; DMARC tells receivers what to do when both fail and where to report. A domain that sends no mail should still publish them, with a reject policy, so nobody else can send as it.

How to read the result

The banner says SPF and DMARC are both set up, or which part is incomplete, or that some queries went unanswered and the state is not fully known. A record is reported missing only when the zone answered; a timeout is unknown, not absent. More than one SPF record gets its own banner: receivers treat it as a PermError and apply no SPF at all, so the fix is to merge, not to add. A DKIM record with an empty p= is a revoked key and is listed as revoked, not as DKIM found; and a null MX (a single MX record with priority 0 and no host) is a domain declaring it takes no mail, and is reported as that. If a subdomain has no _dmarc record of its own, the nearest parent's record is read under its sp= policy (or p= without one) and reported as inherited, the way receivers apply it. A key with t=y is in testing mode, and is marked as such. Two DMARC records at one name are an error too: receivers then apply neither. A DMARC record without a valid p= counts as p=none when it names a reporting address (rua), and is ignored when it does not.

DKIM is reported as found with its selectors, or not found under the common selectors. Selectors can have any name and only the seventeen listed were asked for; the table of selectors tried says which, so a key under another name was never looked for rather than found absent. Read the DMARC record's p= tag: none monitors and protects nothing; quarantine and reject act. The Full report goes further on SPF, counting its DNS lookups against the limit of ten and checking the all qualifier.

When it is useful

Mail from the domain lands in spam or is refused for authentication. Confirm the SPF record includes every service that sends on the domain's behalf, that DKIM is published under the selector your provider uses, and that DMARC exists. Then check the sending address with Email blacklist check and Reverse DNS; together these cover most refusals.

Someone is sending mail as your domain to your customers. Without DMARC at p=reject nothing tells receivers to refuse it; publish SPF and DKIM, move DMARC from none to quarantine to reject as the reports allow, and watch the change here.

Common questions

What are SPF, DKIM and DMARC?

SPF names the servers allowed to send for a domain. DKIM signs each message so the receiver can verify it came from an authorised server unaltered. DMARC tells receivers what to do when a message fails both, and where to report.

Why does the check say DKIM was not found?

No key was published under any of the seventeen common selectors. Your provider may use another selector name, in which case the key exists and was never queried; look up selector._domainkey.yourdomain with the TXT record tool.

Can I have two SPF records?

No. Two v=spf1 records at one name are a permanent error for receivers and the domain ends up with no SPF at all. Merge them into one record listing every sender.

Which DMARC policy should I use?

Start with p=none and a reporting address to see who sends as your domain, then move to quarantine and finally reject once every legitimate sender passes. Only reject actually stops forged mail.