RevenueFlow
    Domain health

    DKIM checker

    The short answer

    A DKIM record is a DNS TXT record at <selector>._domainkey.<domain> holding the public half of the key a mail server uses to sign outgoing messages, so a receiver can verify that the headers and body arrived unaltered and were signed by someone holding the private half. This checker fetches that record for a selector you supply, or tries fourteen selectors the major sending platforms publish by default, and reports the key type, the key length read from the key itself, and whether the key has been revoked — an empty p= value, which RFC 6376 defines as revocation and which no amount of correct configuration elsewhere will survive.

    Run the check

    The selector is the s= value in the DKIM-Signature header of any message the domain has sent. It cannot be discovered from DNS.

    No signup, no email, nothing stored. The check is a set of DNS queries made from our server and thrown away when the answer is rendered.

    Result

    Enter a domain to run the check. Results appear here.

    How the check works

    The query is a TXT lookup at the selector name: selector, then the fixed label _domainkey, then the domain. In auto mode that same query runs against fourteen selector names at once and the results are reported individually. Nothing else is possible, and this is the structural difference between DKIM and the other two checks: SPF and DMARC live at names derived from the domain, so a lookup is deterministic, while a DKIM key lives at a name someone chose. DNS answers “does this name exist?” and never “what names exist here?”, so a checker that finds nothing has not established that DKIM is absent.

    Records longer than 255 characters arrive as several strings inside one TXT record, and RFC 6376 section 3.6.2.1 requires them to be concatenated with nothing between. A 2048-bit RSA key does not fit in one string, so this matters: a tool that skips the join reports a perfectly valid key as malformed. The joined value is then parsed as semicolon-separated tags — v= for the version, k= for the key type, p= for the key itself, h= for the acceptable hash algorithms, t= for flags. Only p= is genuinely required; the version tag is recommended rather than mandatory, which is why a record without it is still treated as a key here.

    The key length is not estimated from the length of the base64 string. The p= value is a DER-encoded SubjectPublicKeyInfo structure, so it is decoded and the modulus length read from the key, giving an exact figure rather than a bucket. The string-length estimate is kept only as a fallback for keys that will not parse, and when it is used the result says so — the difference between “1024-bit” and “about 1024-bit” is the difference between a measurement and a guess.

    A worked example

    v=DKIM1; k=rsa; h=sha256; t=s; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…IDAQAB

    Published at s1._domainkey.example.com. v=DKIM1 identifies the record as a key record. k=rsa gives the algorithm; the alternative is ed25519 under RFC 8463, usually published alongside an RSA selector rather than instead of it, because not every verifier supports it. h=sha256 restricts the key to SHA-256 signatures, which rules out the long-deprecated SHA-1. t=s says the signing domain must not be a subdomain of the From domain — a tightening, not a test flag; the flag to watch for is t=y, which means testing mode and tells verifiers to ignore a failure. The truncated p= value here is the public key, and its real length is what determines whether this is a 1024- or 2048-bit key.

    Questions

    What is a DKIM record?
    A DNS TXT record at <selector>._domainkey.<domain> holding the public half of a signing key. The sending server signs selected headers and the message body with the private half and puts the signature in a DKIM-Signature header; the receiver fetches this record and verifies it. It is defined by RFC 6376.
    Why do I need to know the selector?
    Because DNS cannot be enumerated. A selector is an arbitrary label chosen by whoever set up the signing, and there is no query that lists the selectors on a domain — you can only ask whether a specific name exists. The selector in use is written in the s= tag of the DKIM-Signature header on any message the domain has sent, which is the only reliable way to find it. The auto mode here guesses from the defaults the big platforms publish, and a miss proves nothing.
    What does an empty p= tag mean?
    The key has been revoked. RFC 6376 defines an empty public key value as revocation, and the record is left in place deliberately so verifiers get a definite answer instead of a missing one. If a selector with an empty p= is still signing outgoing mail, every message it signs fails DKIM.
    Is a 1024-bit DKIM key a problem?
    It still verifies everywhere. RFC 8301 sets 1024 bits as the minimum acceptable and recommends 2048 or more, so a 1024-bit key is the weakest size still in spec rather than a broken one. It is usually a sign the key was generated years ago and never rotated. Part of why it persists is mundane: a 2048-bit key does not fit in a single 255-character DNS string and has to be published as a split record, which some DNS panels make awkward.
    Can one domain have several DKIM selectors?
    Yes, and it normally should. Each sending service signs with its own key under its own selector, so a domain sending through a mailbox provider, a marketing platform and a transactional service will have three. What is not allowed is two key records at the same selector: RFC 6376 section 3.6.2.2 tells a verifier to treat that name as having no key at all.
    What does t=y do?
    It puts the key in testing mode, which tells verifiers to treat a failed signature from it exactly as they would treat unsigned mail. It exists so a new key can be deployed without risk, but a key left in testing mode is not protecting anything and DMARC cannot rely on it.

    The rest of the set

    Read further

    For the economics rather than the DNS, our free calculators cover cost per meeting, cold email ROI and a spam word checker that runs in your browser.

    Records checked · Now the sending

    Authentication is the floor, not the plan.

    A verified DKIM key proves a message was not altered in transit. It says nothing about whether the message was worth sending — which is the part we are actually hired for, and the part we are paid on.

    Book a strategy callRead the benchmark report