DKIM key tester — selector validation and key length estimation

Three reliable ways. First, send yourself a test message from the domain you want to check, then view the raw message source (in Gmail: "Show original"; in Outlook: "View source"). Find the DKIM-Signature header and look for the s= tag — its value is the selector. Second, check the sending service's admin console: Google Workspace shows the selector under Admin → Apps → Google Workspace → Gmail → Authenticate Email; Microsoft 365 uses selector1 and selector2 by default; most ESPs document their selectors in setup guides.

Third, if you have multiple sending services and want to find all of them, run the tester against the common ones for your stack: Google Workspace uses google, Microsoft 365 uses selector1 and selector2, Mailchimp uses k1 or k2, SendGrid uses s1 and s2, Mailgun uses a domain-specific selector, Postmark uses 20XXXX numeric selectors. Each match tells you that service is configured for your domain.

2048-bit. The case for 4096-bit is real on paper — more entropy, longer time horizon against advances in cryptanalysis — but in operational practice two things push against it. First, a 4096-bit key produces a public key record around 736 base64 characters; once you add the surrounding tags and account for the 255-character TXT string limit, you are reliably above the threshold where some DNS providers and some receivers handle the multi-string TXT record inconsistently. Second, the marginal security improvement at 4096-bit over 2048-bit is not load-bearing for any threat model that DKIM addresses — DKIM signs at the boundary of email transit, where the relevant attack window is hours to days, not the decade-scale considerations that motivate 4096-bit elsewhere.

The practical answer: 2048-bit for everything unless you have a specific compliance requirement that mandates 4096. Rotate every 6-12 months, and the rotation cadence does more for security than the extra key bits ever would.

Computing the exact RSA modulus length requires decoding the base64 into ASN.1 DER and parsing the BIT STRING. The tester runs entirely in the browser without bundling an ASN.1 parser, so it estimates the key size from the base64 string length: RSA 1024-bit keys produce ~216 base64 characters (give or take a few for the ASN.1 header), 2048-bit produces ~392, 4096-bit produces ~736. The mapping is accurate within standard RSA key sizes; the estimate will tell you correctly whether you are at 1024, 2048, or 4096, even if it cannot tell you whether the modulus is exactly 2048 bits or 2080 bits. For practical purposes — the question is "1024 or 2048?" not "is it exactly 2048?" — that level of precision is what you need.

Carefully, with dual-signing as the safety net. RFC 8463 defined Ed25519 for DKIM in 2018, and the cryptography is genuinely strong — Ed25519 keys are 256 bits (much smaller than RSA), signatures are 64 bytes, and verification is faster. The problem is receiver-side support: not every MTA, every spam filter, every legacy enterprise gateway in the world has caught up. Some receivers still treat an Ed25519-only signed message as DKIM-fail because their software does not know how to verify it.

The deployment pattern that works: sign with both RSA-SHA256 (under one selector) and Ed25519 (under another). Receivers that understand both will validate the stronger of the two; receivers that only know RSA will validate RSA and ignore Ed25519. You get the benefits of newer cryptography without the failure mode for older receivers. Set this up only after you have RSA working cleanly — Ed25519 alone is not safe to deploy.

DMARC alignment requires that the signing domain (the d= tag in the DKIM-Signature header) match the From header domain — exactly under strict alignment (adkim=s in your DMARC record), or organizationally under relaxed alignment (adkim=r, the default, where mail.example.com aligns with example.com). DKIM can pass cryptographically while still failing DMARC alignment if the message is signed by a different domain entirely — common when a third-party sender (a newsletter platform, a CRM that sends on your behalf) signs with their own domain instead of yours.

The fix is having that sender sign with your domain — most modern transactional ESPs and marketing platforms support a "signed with your domain" mode, often called "branded sending" or "signed-by-customer DKIM". Setup involves publishing the platform's DKIM public key in your DNS under a selector they specify, then enabling their corresponding signing mode in their admin console. After that, the DKIM-Signature header shows d=yourdomain.com and DMARC alignment passes.

Whenever the key would normally come up — at initial setup, before and after every key rotation, when onboarding a new sending service that needs its own selector, and quarterly as a maintenance check to catch silent failures. The most common reason a previously-working DKIM record stops working is a DNS migration: the team moves DNS to a new provider, the new provider's interface handles long TXT records differently from the old one, and the record gets truncated or quoted incorrectly during the import. A quarterly DKIM check across every selector you use catches the regression within weeks rather than after a DMARC report shows mail flowing to spam for two months.