Email authentication — SPF, DKIM, DMARC, MX
Under “Email authentication”, Domain Watchdog checks the four records that govern a domain's mail: SPF, DKIM, DMARC and MX. Together they decide whether receivers trust mail from the domain and whether spoofers can impersonate it. Each is graded pass, warn or fail — with one deliberate exception, DKIM, which can only ever warn.
SPF (defined by RFC 7208) says which servers are allowed to send mail for the domain. Domain Watchdog passes it when there's exactly one v=spf1 record and it stays within the 10-DNS-lookup limit receivers enforce. It warns when there's more than one SPF record — which breaks SPF — or when the record needs more than 10 lookups to evaluate. It fails when there's no SPF record at all.
DMARC (RFC 7489) is read from the _dmarc record and ties SPF and DKIM together with a policy telling receivers what to do with mail that fails. It passes when the policy is p=reject or p=quarantine — an enforced policy. It warns when the policy is p=none (published but not enforced — monitoring only) or the record is malformed. It fails when there's no DMARC record.
DKIM signs outgoing mail with a key published in DNS. There's no way to list a domain's DKIM selectors from the outside, so this check is a presence heuristic: it probes common selectors — google, default, selector1, selector2, k1, dkim, mail, s1, s2 — at <selector>._domainkey. If it finds a key, it passes. If it finds none, it warns; it never fails, because the absence of a key at the selectors we know to try doesn't prove DKIM isn't in use.
MX lists the servers that receive mail for the domain. It passes when there's at least one MX record and at least one of the top-three-priority hosts actually resolves to an address. It warns when MX records exist but none of them resolve — mail has nowhere to land. It fails when there are no MX records at all.
DKIM can only ever warn, never fail. Because senders can use arbitrary or rotating selectors — AWS SES is a common example — a key our probe can't find might still exist. When SES is detected, the copy even softens to “likely present but unverifiable”. A DKIM warning means “we couldn't confirm it from outside”, not “it's broken”.
A DMARC policy of p=none is a warning, not a pass. p=none publishes a record but tells receivers to take no action on mail that fails — so it gives you reports without actually stopping spoofing. To pass, move the policy to p=quarantine or p=reject once you've confirmed your legitimate mail authenticates.
Frequently asked questions
Which email records does Domain Watchdog check?
Four, under “Email authentication”: SPF (which servers may send), DKIM (message signing), DMARC (the enforcement policy), and MX (which servers receive mail). Each is graded pass, warn or fail — except DKIM, which can only warn.
Why is DKIM only ever a warning?
Because DKIM selectors can't be listed from outside the domain. The check probes common selectors (google, default, selector1/2, k1, dkim, mail, s1, s2), but senders can use arbitrary or rotating selectors — AWS SES is a common case — so a key we can't find might still exist. It warns rather than failing, and softens to “likely present but unverifiable” when SES is detected.
Why did my domain warn on DMARC when it has a record?
Most likely the policy is p=none — published but not enforced, so receivers take no action on failing mail. That earns a warning, not a pass. Move the policy to p=quarantine or p=reject to pass. A malformed DMARC record also warns.
What counts as a passing SPF record?
Exactly one v=spf1 record that stays within the 10-DNS-lookup limit. More than one SPF record (which breaks SPF) or a record needing more than 10 lookups warns; no SPF record at all fails.