What does an empty p= tag mean?

It revokes the key. An empty p tag is valid syntax that explicitly states this selector is no longer signing, and receivers treat signatures against it as failures. If you did not intend to revoke, the value was lost when the record was entered.

My key is longer than 255 characters. How do I publish it?

As multiple quoted strings on the same TXT record, which resolvers join together. Many DNS panels do this for you when you paste a long value. The failure mode is a panel that accepts the long string and stores it in a way that does not reassemble correctly, so always check what resolves.

Should I use a 1024-bit or 2048-bit key?

2048-bit. It is the current expectation and 1024-bit is increasingly treated as weak. The only argument for the shorter key is that it fits in one DNS string, which is a formatting convenience rather than a technical constraint.

Can I have spaces in the record?

Spaces may appear between tags, but never inside the base64 value of the p tag. A space inside the key corrupts it, and this is the single most common way a valid key is broken during copying.

HighAuthentication

DKIM record is malformed

A DKIM record was found at the selector but it does not parse as a valid key. Receivers that cannot read the key cannot verify the signature, so the result is a permanent failure, which is worse than no record at all, because the sending platform believes it is signing successfully and nothing surfaces the problem.

Check your own domainDKIM checker

What causes this

A DKIM record is tag=value pairs and must contain a p= tag holding the base64 public key. The most frequent cause of a malformed record is the key being truncated or having spaces inserted when it was pasted, because DKIM keys are long and many DNS interfaces wrap or split them awkwardly.

What it breaks

Receivers cannot load the public key, so every signature made with this selector fails verification.

What the receiving server does

The record is a set of tag and value pairs, of which p= carrying the base64 public key is the one that matters. A receiver parses the record, extracts the key and uses it to verify the signature hash. If the record is malformed, if p= is empty, or if the base64 does not decode into a usable key, verification fails permanently. Retrying does not help, and because the failure is at the receiving end it produces no bounce and no log entry on your side.

How valid keys get broken

DKIM records are long: a 2048-bit key does not fit in a single 255-character DNS string, and nearly every syntax problem comes from how that length is handled when the record is entered.

causeline breaks inside the keypasted from a console that wrapped the value

causespaces introduced into the base64base64 has no spaces; any inside it corrupt the key

causep= with an empty valuean empty p tag revokes the key (valid syntax, deliberately no signing)

causequoted strings joined wronglylong TXT records split into chunks that do not reassemble

How to fix it

Re-paste the key exactly as your provider issued it.

Copy the record value again from the provider's console.
Paste it as a single unbroken value. If your DNS host requires splitting long strings, use its quoted-string syntax rather than inserting spaces.
Verify the p= value is unbroken base64 with no whitespace inside it.
Re-check the selector.

If you send with

Records entered by hand: If the provider offers a CNAME instead of a TXT record, take it. A CNAME points at a key the provider maintains, which removes the whole class of transcription error and lets them rotate keys without involving you.
DNS panels and 255-character strings: A single TXT string cannot exceed 255 characters, so a 2048-bit key must be published as several quoted strings that resolvers concatenate. Some panels handle this automatically, others require the quoting to be written manually and will store something that does not reassemble. Verify what resolves rather than what you pasted.

Confirming the fix worked

Re-copy the key from the provider and paste it into a plain text editor first to check for line breaks or introduced spaces.
Confirm the record contains a p= tag with a non-empty base64 value.
Where the provider offers a CNAME, replace the hand-entered TXT record with it.
Send a test message and confirm the headers show dkim=pass rather than a permanent error.

Common questions

What does an empty p= tag mean?: It revokes the key. An empty p tag is valid syntax that explicitly states this selector is no longer signing, and receivers treat signatures against it as failures. If you did not intend to revoke, the value was lost when the record was entered.
My key is longer than 255 characters. How do I publish it?: As multiple quoted strings on the same TXT record, which resolvers join together. Many DNS panels do this for you when you paste a long value. The failure mode is a panel that accepts the long string and stores it in a way that does not reassemble correctly, so always check what resolves.
Should I use a 1024-bit or 2048-bit key?: 2048-bit. It is the current expectation and 1024-bit is increasingly treated as weak. The only argument for the shorter key is that it fits in one DNS string, which is a formatting convenience rather than a technical constraint.
Can I have spaces in the record?: Spaces may appear between tags, but never inside the base64 value of the p tag. A space inside the key corrupts it, and this is the single most common way a valid key is broken during copying.