DKIM record has an empty p= tag (key revoked)
What this check looks for
The DKIM record for this selector exists but contains no key. An empty key means revoked, so every message signed with this selector is rejected outright.
Why it matters
If your mail server is still signing with this selector, all of that mail now fails DKIM — and if DMARC is enforcing, much of it will not be delivered at all.
When the check passes, your report says: “The DKIM record carries a live signing key”.
What it costs your score
When this check fails it removes 25 points from your Email authentication score, before the status, confidence and repeat multipliers are applied. Email authentication carries a weight of 15 in the overall score.
It shares the email-auth.dkim family ceiling of 30 points: however many findings that family produces, together they cannot remove more than that from Email authentication. One underlying problem showing up in several places is still one problem.
- Severity
- critical
- Default confidence
- confirmed
- Status when triggered
- fail
- Deduction
- 25 points
- Family cap
- email-auth.dkim · 30
- Category
- Email authentication
- Module
- Email dkim
- Fix owned by
- dns host
- In the ruleset since
- 2026.09
How to fix it
Republish the correct public key, or stop signing with this selector.
An empty p= is a revocation: every message signed with this selector fails DKIM.
If the revocation was intentional, reconfigure your mail server to sign with the current selector and then delete this record.
If the value was lost, republish the full base64 public key — check your DNS host did not truncate it at 255 characters.
How to confirm it worked
dig +short TXT ‹selector›._domainkey.‹domain› — the p= value must be a non-empty base64 key
A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.
Technical detail
‹selector›._domainkey.‹domain› publishes p= with an empty value. RFC 6376 §3.6.1 defines an empty p= as the key having been revoked, and verifiers must treat any signature using it as failed. This is usually an intentional revocation left in place after a rotation, or a truncated record where the base64 value was lost.
Standards and references
- RFC 6376 §3.6.1 — Key Revocation § 3.6.1
Test this on your domain
Run the check that produces this finding, on its own, against any domain.