auth.dkim.revoked_null_mx

DKIM Keys Revoked (Null MX Domain)

What we check

We query DKIM public-key records at common selectors. This finding is emitted when the keys we find have an empty p= tag — the RFC 6376 way to revoke a key — and the domain publishes a Null MX (RFC 7505), declaring that it receives no mail.

What this finding means

On an ordinary mail domain a revoked key is a failure: mail signed with it can no longer be verified. On a Null MX domain the picture is different. Publishing revoked keys at every well-known selector is a deliberate hardening step for a domain that sends no mail: it guarantees that nobody can produce a DKIM signature that validates for the domain, closing one more spoofing avenue alongside v=spf1 -all and p=reject.

The scanner cannot see whether the domain sends mail — Null MX only says it does not receive any. So this is reported as information, not a verdict: correct for a parked or non-mail domain, a problem only if the domain does send mail.

Why it matters

Parked domains get spoofed. Attackers favour domains nobody watches. Revoked keys, -all, and p=reject together make such a domain useless to them.
Sending domains still need keys. A domain that sends transactional mail but receives none (Null MX) must keep active keys, or its mail fails DMARC alignment.

How to fix

Nothing, if the domain sends no mail. If it does send mail, publish an active key for each selector your mailer signs with and leave the unused selectors revoked.

How it's graded

Informational — no deduction. See Grading Methodology and the Null MX section of the test-suite spec.

Evidence example

default._domainkey.example.com  TXT  "v=DKIM1; p="
google._domainkey.example.com   TXT  "v=DKIM1; p="
example.com                     MX   0 .