How DKIM signing works
DKIM (DomainKeys Identified Mail) lets a receiver verify that a message was sent by someone holding your domain's private key and that it was not altered in transit. The sending server hashes the body, hashes a chosen set of headers, signs the result with the private key, and adds a DKIM-Signature header that includes the signing domain (d=), the selector (s=), the signed header list (h=), the body hash (bh=) and the signature itself (b=). The receiver fetches the public key from selector._domainkey.domain as a TXT record, recomputes the hashes, and checks the signature.
Because the signature travels with the message, DKIM survives forwarding, mailing lists that do not rewrite the body, and any hop that SPF cannot see. That makes it the more robust of the two authentication methods and the one most likely to carry DMARC alignment for cold email. The d= domain must align with the From header domain for DMARC to pass on DKIM, so sign with the domain your inboxes actually send from, not a shared provider domain.
The DNS record itself is small: v=DKIM1 for the version, k=rsa for the key type, and p= followed by the base64-encoded public key. Optional tags include t=y for testing mode, which tells receivers to ignore failures and should be removed once verified, and h= to restrict hash algorithms. An empty p= tag means the key has been revoked.
Key length, selectors and rotation
RFC 8301 requires verifiers to support keys up to 2048 bits and signers to use at least 1024. In practice 2048-bit is the standard today, and several receivers score 1024-bit keys as weak. The only reason to choose 1024 is a DNS host that cannot store a TXT value longer than 255 characters, and even then the correct fix is to split the value into multiple strings, which the generator provides, rather than weaken the key. A 2048-bit public key is about 392 base64 characters; a 1024-bit key is about 216.
A selector is just a label that lets a domain publish several keys at once. Providers use fixed ones, google for Google Workspace, selector1 and selector2 for Microsoft 365, k1 for Mailchimp, s1 and s2 for SendGrid, zoho or zmail for Zoho. For your own keys, date-based selectors such as s202609 make rotation self-documenting.
- Rotate keys every 6 to 12 months, or immediately if a private key may have leaked.
- Publish the new selector first, switch signing to it, then leave the old record in DNS for at least a week so in-flight mail still verifies.
- Revoke a retired selector by publishing an empty p= rather than deleting the record, so receivers get an explicit answer.
- Use a different selector per sending system so you can revoke one without touching the others.
Where the private key goes, and where it must never go
If your inboxes are hosted on Google Workspace or Microsoft 365, you do not need to generate a key at all. Those providers create and hold the private key themselves; you only copy the public record they give you into DNS. The same applies to most SMTP relay services. This generator is for the cases where you control signing: a Postfix or Exim server with OpenDKIM, Amazon SES with bring-your-own DKIM, a Mailgun or similar service that accepts a custom key, or an appliance that signs outbound mail.
The private key here is produced by your browser's WebCrypto API and exported in PKCS#8 PEM format, which is what OpenDKIM, SES and most SMTP software expect. It is never transmitted; reloading the page destroys it. Store it with the same care as a password: on the signing server with restrictive file permissions, in a secrets manager, or in a password vault. It must never be pasted into DNS, committed to a repository, or sent over chat. If a key is exposed, generate a new pair under a new selector, switch signing, and revoke the old selector.
DKIM for cold email secondary domains
Gmail and Yahoo require every sender to pass SPF or DKIM, and bulk senders to pass both plus DMARC alignment. Since most cold email volume runs on Google Workspace or Microsoft 365 inboxes spread across secondary domains, the practical step for each domain is to turn on DKIM in the provider console, publish the record it gives you, and verify it with the checker above. A domain sending without DKIM is far more likely to land in spam on day one, and a domain whose DKIM record has been mistyped, a stray space or a missing quote in the p= value is the classic case, is effectively unsigned.
Verify after every DNS change and after any provider migration. The checker parses the live record, estimates the key size from the base64 length, and flags testing mode, revoked keys and corrupted values. The selector scan tries the ten most common provider selectors so you can find a record without knowing the selector in advance. If none match, open a message you sent to yourself, view the headers, and read the s= tag in the DKIM-Signature line. ColdBox runs this check on every connected inbox and alerts you if a record disappears or fails to verify, so a broken key never quietly costs a campaign.