DKIM glossary
What is the p= tag in a DKIM record?
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 15, 2026
The p= tag holds the base64 public key in a DKIM DNS record — the key receivers use to verify your signatures, as in v=DKIM1; k=rsa; p=<key>. An empty p= means the key has been revoked. It pairs with k= (almost always rsa), and today a 2048-bit key is the recommended length.
p= at a glance | |
|---|---|
| Tag | p (public key) |
| Valid values | Base64-encoded public key. An empty value (p=) marks the key revoked. |
| Default | Required — the p= tag is the one part a DKIM key record cannot omit. |
| Where it goes | In the _domainkey TXT record, after v= and k=. |
How p= works
p= carries the public half of your DKIM key, base64-encoded, in the DNS record at <selector>._domainkey.<domain>. Receivers fetch it to check the signature the private key produced. The private key stays on the sending system; only this public value is ever published.
An empty p= is meaningful, not a mistake in itself: it tells receivers the key has been revoked. It pairs with the k= tag, which names the key type — rsa is effectively universal; ed25519 exists via RFC 8463 but adoption is still thin. For RSA, a 2048-bit key is the current recommendation; 1024-bit is legacy and weaker.
The most common real-world failure is length, not cryptography. A 2048-bit key is long, and many DNS providers split it into several quoted strings inside one TXT record. If a copy-paste drops a chunk or mangles the quoting, the published key no longer matches the private one and every signature fails — a silent breakage that looks like nothing is wrong in DNS.
Correct record vs common mistake
Correct
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...IDAQABA complete, unbroken 2048-bit RSA public key. The receiver can decode p= and verify signatures made with the matching private key.
Common mistake
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AA truncated key — the paste dropped the tail of the base64 value. It's syntactically fine but no longer matches the private key, so every signature fails.
Troubleshooting p=
| Issue | Likely cause | Fix |
|---|---|---|
| All signatures suddenly fail | The published p= no longer matches the private key | Re-publish the exact public key that pairs with the active private key, unbroken |
| Key looks present but DKIM fails | A long key was truncated or mis-quoted when pasted into DNS | Re-paste the full base64 value; if the provider splits it, keep every quoted chunk in order |
| Receivers treat the key as revoked | p= was left empty during an edit or rotation | Publish the current public key value in p=, or intentionally leave it empty only when retiring the key |
See this on your own domain
Enter your domain — the check runs instantly on the next page. Free, no signup.
Why it matters for MSPs
A truncated or revoked p= is invisible on a DNS spot-check — the record exists, so it looks configured. Across many tenants, a botched key rotation or a provider that silently split a long TXT string can take a whole client's mail out of DKIM at once, with no error to point at.
Trusted by MSPs
“Palisade allowed our team to deploy DMARC on our domains in minutes instead of hours and making sure our clients are compliant with cutting edge security recommendations from Microsoft.”
Alvin Kalli — CSIO, MSP Corp
Enforce it — don't just monitor it
Palisade watches each client's DKIM results in the reports, so a truncated or revoked p= shows up as failing signatures immediately — not weeks later — and the domain isn't advanced toward reject until the key verifies cleanly.
Free 15-day trial · No credit card · Your own domain free forever (NFR)