DKIM

DKIM (DomainKeys Identified Mail) takes a different approach to email authentication than SPF. SPF authorises servers — it says which IP addresses are allowed to send as your domain, and that authorisation only means anything at the moment of delivery, checked against the connecting server. DKIM instead signs the message itself: the sending server adds a cryptographic signature covering specific headers and the message body, using a private key, and publishes the matching public key in DNS. Any receiving server can then verify that the signature is valid and that the signed content hasn't been altered in transit — including after the message has been forwarded, which is exactly the case where SPF stops working, since a forwarding server is not on the original sender's authorised list.

The record

A DKIM public key is published as a DNS TXT record at a selector-specific name — not at the domain apex, and not at a fixed, guessable location the way _dmarc and _mta-sts are. The selector is chosen by whoever configured DKIM (your mail platform typically picks it), which is exactly why DKIM presence can't be enumerated from the outside: without knowing the selector in advance, there is no query that reveals whether DKIM exists at all.

selector._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."

• •v — DKIM1, the version tag.
• •k — the key algorithm, almost always rsa.
• •p — the base64-encoded public key. The private half never appears in DNS or anywhere public; it lives only on the sending server.

The signature itself travels in a DKIM-Signature header on the outgoing message, which names the selector and domain used (s= and d=) so the receiver knows exactly which DNS record to fetch and verify against. Two other tags in that header matter in practice: h= lists which headers were actually included in the signature (From, Subject, Date, and usually several more — any header not listed can be altered or added by a relay without invalidating the signature, which is why a short h= list is weaker than it looks), and c= sets the canonicalization mode, which decides how much whitespace and formatting drift the signature tolerates before it's considered a different message. Most platforms default to relaxed canonicalization on both header and body, which survives the minor reformatting many mail servers do in transit; the stricter simple mode breaks more easily and is less commonly used for exactly that reason.

You can see a real signature yourself: view the full source of any received email (most mail clients call this "show original" or "view source") and look for the DKIM-Signature header near the top — the d= and s= tags tell you exactly which DNS record to look up to verify it by hand.

Why Surface can only report this as informational

Because the selector is arbitrary and not discoverable from DNS alone, a domain scanner has two options: guess a list of commonly-used selectors (google, selector1, selector2, k1, mandrill, and a handful of others tied to specific platforms) and check whether any of them resolve, or give up on checking DKIM presence entirely. Surface does the former, but a miss on every guessed selector is not evidence that DKIM is absent — it may simply use a selector that isn't on the guess list, which is common and not a misconfiguration. This is why the result is always reported as informational rather than a pass or fail: an accurate "DKIM found" is a genuinely useful positive signal, but there is no accurate way to assert "DKIM absent" from the outside.

Common failure modes

• •No DKIM configured at all — mail relies on SPF alone, which breaks the moment a message is forwarded through any intermediate server.
• •Key too short — 512-bit keys were common in early DKIM deployments and are now considered weak enough to be practically forgeable; 1024-bit is the realistic minimum today and 2048-bit is standard practice.
• •d= doesn't match the From: domain — DKIM can pass its own signature check while still failing DMARC alignment, if the signing domain isn't the same as (or, in relaxed mode, a subdomain of) the domain in the visible From: header. This is the DKIM half of the alignment problem described in the DMARC guide.
• •Stale or rotated-out keys left in DNS — harmless on their own, but worth cleaning up; an unused key published in a forgotten selector is one more thing that could theoretically be abused if the corresponding private key were ever compromised.
• •No key rotation policy — DKIM keys don't expire on their own, and a key that's been in continuous use for years without rotation is simply a larger, more valuable target for longer.

DKIM, SPF and DMARC aren't three independent settings to configure — they're one system. SPF and DKIM each produce a pass/fail result that means very little on its own; DMARC is what turns those results into an actual policy, and alignment is what makes sure the pass you got was actually protecting the domain you meant it to.