The DKIM Tester That Reads the Signing Key.

A DKIM record is a TXT entry published in your DNS that holds a public key. Your sending platform signs every outgoing message with the matching private key, and a receiving server fetches the public key to confirm the signature is valid and the message was not altered in transit. The record lives at a selector._domainkey.yourdomain hostname.

Type a domain into the DKIM tester above and Verifox reads the record back, the key type, the key length, and whether it is well formed. For the definition on its own, the DKIM glossary entry walks through how the signing handshake works.

The fastest way is to paste the domain into the DKIM tester above, add the selector if you know it, and read the record back. No account, no install. You can also run a DKIM test from a terminal with dig TXT selector._domainkey.example.com, but that returns the raw TXT string you then have to parse yourself.

The Verifox DKIM record checker instead reads the key in plain English, flags whether the signature is valid, and flows straight into mailbox verification when you need to go past authentication.

A DKIM selector is the label that points to a specific signing key in your DNS. Because the record lives at selector._domainkey.yourdomain, the selector is what lets a single domain publish several DKIM keys at once, one per sending service, and rotate them without breaking the others.

Each platform uses its own selector. Google Workspace signs with google, Microsoft 365 with selector1 and selector2, and marketing tools each have their own. The DKIM lookup above accepts an optional selector so you can test the exact key you care about.

The selector is embedded in the s= tag of the DKIM-Signature header on any message you have sent. Open a sent email, view its original or raw source, and look for the s= value, that is your selector for that sending service.

You can also get it from the sending platform itself: Google Workspace, Microsoft 365, and most email tools show the selector when you turn on DKIM signing. Once you have it, drop it into the DKIM tester above to confirm the key is actually published in your DNS.

A DKIM test fails for a handful of common reasons: the selector is not published in DNS, the key was rotated by your provider but the DNS record was never updated, the record is malformed, or you are testing the wrong selector for that sender. Any of these means receivers cannot verify the signature.

Because each sending service uses its own selector, a domain can pass DKIM for one sender and fail for another, so always test the selector that matches the platform you send through. The SPF, DKIM, and DMARC check runs all three records in one pass if you want the complete picture.

The fix lives in two places. First, turn on DKIM signing in the sending platform (Google Workspace, Microsoft 365, your marketing tool); it will give you a selector and a public key. Second, publish that key as a TXT record at selector._domainkey.yourdomain in your DNS, exactly as the platform provides it.

Re-run the DKIM test after the DNS change to confirm it now validates. DNS can take time to propagate, so a freshly published key can read as failing for a little while. If the key was rotated, make sure the new selector is live before you retire the old one.

The number is the length of the RSA public key in the record. A 2048-bit key is stronger and is the current recommendation; a 1024-bit key still works but is the weaker minimum. Most major providers now default to 2048-bit.

The DKIM tester above reads the key length back so you can confirm which you are publishing. If you are still on a 1024-bit key, rotating to 2048-bit is a low-effort hardening step: generate the new key in your platform and republish the selector.

No. This page is the DKIM-specific tool, it looks up one record, the signing key at a selector, and validates it. SPF and DMARC are separate records that do different jobs: SPF lists who is allowed to send, and DMARC sets the policy when a message fails.

If you want all three in a single pass, use the SPF, DKIM, and DMARC check instead, it is the all-in-one authentication checker. Use this DKIM tester when you specifically need to dig into the signing key and its selector.

No, and the difference matters. A DKIM test checks the domain’s signing key, can its mail be cryptographically proven genuine. It says nothing about whether a specific mailbox on that domain actually exists.

A domain can publish a perfect DKIM record while jane@ that domain is long gone. That is why DKIM is the authentication layer of deliverability and the free email checker is the mailbox layer. An MX lookup rounds out the picture by showing where the mail routes.

Yes. The single DKIM test above is free with no account. For a list of domains, the REST API returns the DKIM record and its validity for each one, so you can run a bulk DKIM lookup programmatically. Bulk checks run on pay-as-you-go credits that never expire.

Verifox also ships native MCP server support, so AI agents (Claude, Cursor, custom LLM apps) can test DKIM and verify addresses without glue code, and live uptime is tracked at status.verifox.ai.