DNS Mail DKIM

DKIM lets a mail server sign outgoing messages with a private key; receivers fetch the matching public key from DNS at <selector>._domainkey.<domain> and verify the signature. A missing, revoked, malformed or weak key means the signature cannot be verified, so legitimate mail loses its DKIM credit (and often lands in spam) while forged mail is no harder to send. The selector is only known from a signed message, so this auditor guesses the selectors used by the major providers.

​

How it works

1. Domain — takes the host of the audited URL and strips one leading www.. A URL without a host ends the audit with 501. The audited page is never fetched.
2. Probe — queries the TXT record of <selector>._domainkey.<domain> for each of the 26 common selectors: default, dkim, google, google1, google2, k1, key1, key2, mandrill, mg, mta1, mta2, pm, protonmail, protonmail2, resend, s1, s2, scph, selector1, selector2, sendgrid, smtp, zoho, zoho1, zoho2. When every lookup fails at the resolver the audit ends with 500; when only some fail, the rest are audited and the failures are listed in the check data.
3. Parse — each record found is parsed once: the tags in record order (the character strings of a split TXT record are joined first), the key type (k, default rsa), the base64 p tag and, for a known key type, the key itself (RSA modulus size from the SubjectPublicKeyInfo, or the raw 32-byte Ed25519 point).
4. Rules — per selector: a v tag that is not DKIM1 (400), v=DKIM1 not first (401), an unknown k (402), no p tag (403), an empty p tag (404), a p tag that is not base64 (405), an RSA key under 1024 bits (406), an Ed25519 key that is not 32 bytes (407) or not a curve point (408), an RSA-typed key that is not a SubjectPublicKeyInfo (409); a missing v tag (300), an RSA key of exactly 1024 bits (301) and a key of another algorithm (302) warn. When no selector answers at all the audit warns (303), because a selector outside the list cannot be seen.
5. Aggregate — FAIL wins over WARNING. Every selector that passed all rules gets its own 200 check, even when another selector failed; the audit is SUCCESS only when nothing fired.
6. Specification pin — every run emits 37A-DnsMailDkimAuditor-100 (INFORMATION), naming RFC 6376 (September 2011) with RFC 8301 and RFC 8463 as notes. It does not change the overall status.

​

What it audits

Every row maps to one checkRule* method and one CheckCode, in the order the auditor runs them. Per-selector rules emit one check per offending selector; {selector}, {fqdn} and {record} are the selector name, <selector>._domainkey.<domain> and the TXT record text. CheckCode suffixes use status ranges: 100 information, 200 success, 300–399 warning, 400–499 fail, 500–599 error.

​

Output documentation

​

Risks and considerations

​

Selector guessing

• DKIM selectors are private to the signer; only a signed message reveals them. The auditor probes 26 common ones, so a domain that signs with a custom selector shows 303 although its DKIM works. That is why 303 is a warning and not a failure.
• Only the first TXT value of a selector is audited; RFC 6376 leaves several records at one name undefined.
• A resolver failure on some selectors does not stop the audit: those selectors are listed in lookupErrors in the check data. Only a failure on every selector ends the audit with 500.

​

Key strength

• RFC 8301 forbids receivers from accepting RSA keys under 1024 bits (406) and recommends 2048 bits; a 1024-bit key still verifies but is worth rotating (301).
• RFC 8463 Ed25519 keys are published raw (32 bytes). A SubjectPublicKeyInfo-wrapped Ed25519 key under k=rsa is accepted as valid; under k=ed25519 it is 44 bytes and fails 407.

​

Changes from the previous version of this auditor

• No selector found was FAIL; it is now WARNING (303), because selector guessing cannot prove that DKIM is absent.
• An RSA key under 1024 bits was WARNING; it is now FAIL (406), as RFC 8301 forbids receivers from using it.
• A key that does not parse as SubjectPublicKeyInfo was ERROR; it is now FAIL (409): bad published data is a site problem, not an auditor failure.
• A missing or empty p tag used to add a second “not valid base64” or “unable to parse” finding; it now emits only 403 or 404.
• The per-tag SUCCESS checks (“valid key type”, “v=DKIM1 first”, “RSA key bigger than 1024 bits”) are collapsed into one 200 per valid selector.
• URL problems were FAIL; they are now ERROR (501), and a resolver failure on every selector is ERROR (500) instead of “no keys found”.

​

What this auditor does not check

• It does not verify a signed message, so a valid key with a broken signer still passes.
• It does not read the optional t, h, s and n tags.
• SPF and DMARC are covered by their own auditors; DKIM alone does not tell receivers what to do with unsigned mail.