DKIM Monitor

We look at the TXT records already stored on the zone whose name ends in ._domainkey.<domain> — that is, DKIM selectors directly under the root domain. Subdomain selectors (e.g. sel._domainkey.mail.example.com) and a bare _domainkey record without a selector are skipped.

For each selector we parse the tags and validate per RFC 6376 / 8463:

• v=DKIM1 if the version tag is present (omission is allowed by spec).
• p= must be present and non-empty. An empty p= means the key has been revoked.
• k= if present must be rsa or ed25519; defaults to rsa when omitted.
• t=y indicates testing mode.

Because the data comes from our zone-records database rather than a live DNS lookup, freshness depends on the zone's check schedule.

A revoked DKIM key (empty p=) silently breaks signing for any sender still using that selector — affected mail starts failing DMARC alignment without an obvious error. A selector left in testing mode (t=y) tells receivers to ignore failures, defeating the point of publishing the key. And a key using an algorithm receivers don't support produces signatures that can't be verified.

A formal validation of a DKIM key beyond record-level syntax requires actually receiving and verifying a signed message. We don't do that here — but the structural checks catch the most common production failures.

For a missing DKIM record, follow your mail provider's setup — they'll provide the selector name and the public key TXT to publish. Most providers (Google Workspace, Microsoft 365, SendGrid, Postmark, etc.) document this in their admin UI.

For a revoked key (empty p=), either remove the record entirely or replace the public key. Mail signed against a revoked selector will fail DKIM validation.

For a record stuck in testing mode, remove the t=y tag once you're satisfied the signing pipeline works.