DKIM Record Checker

An empty p= is a revocation, not a missing value

RFC 6376 section 3.6.1 defines a key record with an empty p as a revoked key. A verifier that reads it does not conclude the record is incomplete, it concludes the key was withdrawn and treats every signature made with that selector as a failure. So a DNS interface that trimmed the long value, or a copy-paste that lost the tail, publishes a revocation that looks like a typo. This is the one worth checking first, because nothing about it looks broken.

v=DKIM1; k=rsa; p=MIIBIjANBg...   the key
v=DKIM1; k=rsa; p=                 revoked
v=DKIM1; k=rsa                     no key at all

t=y asks verifiers to ignore failures

Testing mode tells a verifier not to treat a DKIM failure as a reason to act. The record exists, the signature is attached, DNS looks right, and none of it is enforcing anything. It belongs in the first day of a rollout, and it is routinely left in for years because every check that only asks whether DKIM is configured says yes.

The key size is in the key, so no lookup is needed to read it

The p tag is base64 of a SubjectPublicKeyInfo, which is the same structure inside a TLS certificate. The RSA modulus is in there, so the key length is readable from the record itself. RFC 8301 requires verifiers to reject anything under 1024 bits and tells signers to use 2048. 1024-bit keys are still widely published, precisely because nothing breaks and nothing complains.

1024 bits   verifies everywhere, and is the one to rotate
2048 bits   what RFC 8301 says to sign with
4096 bits   needs splitting across TXT strings, and not every
            verifier reads it

A long key is several TXT strings, joined with nothing

A single character-string in a TXT record cannot exceed 255 bytes, and a 2048-bit key does not fit. So it is published as several quoted strings, and the resolver concatenates them with nothing in between. Rejoining them with a space or a newline corrupts the key, and the chunk boundary lands wherever 255 bytes falls, which is as often inside a tag name as inside the base64.

"v=DKIM1; k=rsa; p=MIIBIjANBgkq" "hkiG9w0BAQEFAAOCAQ8A..."
                              ^ joined with nothing

k= and the key have to agree

The verifier reads k to decide how to interpret the bytes in p. When they disagree, verification fails for a reason the record explains and nothing in a bounce message will. Ed25519 is worth publishing and not worth publishing alone: RFC 8463 defines it and support is far from universal, so a receiver that does not implement it has a signature it cannot check. Sign with both, under two selectors.

What this cannot see

This is the key half. Whether a message verifies also depends on the signature your mail server attaches, which is not in DNS: the headers it covers, whether the body was modified in transit by a mailing list or a scanner, and whether the d= domain aligns with the From header for DMARC. None of that is visible in the record. It also performs no lookup, so it cannot tell you the record is published, that the selector matches the one your signer uses, or that the private key still pairs with this public one.