DKIM for support email, explained without the jargon

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every message you send, using a private key only you hold; the receiving server fetches your matching public key from DNS and verifies it. If the signature checks out, the receiver knows the message genuinely came from your domain and that no header or body it covers was altered in transit. For support email — high volume, reply-heavy, exactly what spam filters scrutinize — that signature is the single clearest signal that your mail is legitimate.

What DKIM actually does

DKIM adds a digital signature to your outgoing email using a private key only you hold. The receiver looks up the matching public key in your DNS and checks the signature. If it verifies, two things are proven: the mail came from the signing domain, and nobody altered the parts of the message the signature covers. See the short DKIM definition for the canonical version.

Two clarifications that trip people up. DKIM does not encrypt anything — the message still travels in plaintext unless TLS is negotiated between servers. And DKIM is one of three independent checks; it sits alongside SPF (which authorizes sending servers) and DMARC (which ties identity to the visible From address). We cover how the three relate in SPF, DKIM, and DMARC: the difference.

Anatomy of a DKIM signature

The signature rides in a DKIM-Signature header your sending system adds at send time. Its tags tell the receiver exactly how to verify:

• d= — the signing domain. This is the identity DKIM authenticates.
• s= — the selector, which points the receiver to the right public key in DNS.
• h= — the list of headers covered by the signature (typically From, Subject, Date, To, and others). Headers not listed here are not protected.
• bh= — a hash of the message body, so any change to the body invalidates the signature.
• b= — the actual signature, computed over the listed headers and the body hash.
• a= — the algorithm, normally rsa-sha256.

The critical detail for support teams: the signature covers the headers in h= and the body, not the whole envelope. The return-path (envelope sender) is handled by SPF, not DKIM, which is why you need both.

Selectors, keys, and the DNS record

A selector is just a label that lets you publish more than one key under the same domain. The receiver combines the selector with a fixed suffix to find the key: for selector s=cherry1 and domain d=example.com, it queries cherry1._domainkey.example.com for a TXT record. That record holds your public key.

Selectors are what make key rotation and multi-source sending sane. Give each system that sends as your domain its own selector — one for your support platform, one for marketing, one for transactional mail — and you can rotate or revoke any one of them without touching the others. Use 2048-bit RSA keys; 1024-bit still validates but is weak, and 512-bit is broken. A 2048-bit public key often exceeds the 255-character limit of a single DNS TXT string, so it gets split into multiple quoted strings inside one record — your DNS host and SES normally handle that automatically.

Why it matters for support

Support email is high-volume and reply-heavy, exactly the profile spam filters scrutinize. A valid DKIM signature is the clearest per-message signal you can send that a message is legitimate, and it is a prerequisite for DMARC to do anything useful — DMARC requires either SPF or DKIM to pass and align with the visible From domain. Unsigned support replies fail that test by default, and once a stretch of your mail trips filters, the reputation hit follows the whole domain, not just the offending message. The downstream symptoms are covered in why your support replies land in spam and the broader deliverability guide.

BYODKIM: sign as yourself

Many tools sign with their own domain, so recipients see “via” the vendor — for example “via amazonses.com.” That happens because the signing domain in d= belongs to the vendor, not you, and it both leaks your tooling and weakens DMARC alignment on your own domain. BYODKIM (bring your own DKIM) means you generate the key, publish it under your domain, and every message is signed with d= set to your domain — no third-party name in the customer’s inbox.

Cherryrise uses BYODKIM by default: you send signed as your own domain through your own AWS SES, so the signing identity, the reputation, and the bounce stream all stay yours. That isolation matters for a multi-tenant platform — your sending reputation is never pooled with another workspace’s.

Setting it up without breaking mail

The mechanics are short, but the order matters:

1. Generate a 2048-bit key pair and pick a selector name.
2. Publish the public key as a TXT record at selector._domainkey.yourdomain.
3. Wait for DNS to propagate — verify with a lookup before you flip signing on.
4. Enable signing so outgoing mail carries the DKIM-Signature header.
5. Send a test message to an account that exposes the raw headers and confirm dkim=pass.

To rotate later, publish a new selector, let it propagate, switch signing to the new key, and keep the old selector live until no in-flight mail still references it. Because each key lives under its own selector, the old and new validate independently during the overlap, so nothing is left unverifiable.

Reading a failed DKIM check

When verification fails, the receiver records it in the Authentication-Results header. A few recurring causes:

That last row is the one most support setups hit: the mail is technically signed, but signed as the vendor, so DMARC alignment fails. Switching to BYODKIM makes d= your domain and the alignment passes.

Frequently asked questions

Does DKIM encrypt my email?

No. DKIM signs a message, it does not encrypt it. The body and headers travel in the clear unless TLS is negotiated between mail servers. DKIM’s job is integrity and authentication — proving the message came from the signing domain and was not altered after signing — not confidentiality. If you need the contents protected in transit, that is TLS (and MTA-STS); if you need them protected at rest or end to end, that is S/MIME or PGP, which are separate from DKIM.

How many DKIM keys should I have?

At least one per sending source, and ideally separate selectors for each system that sends mail as your domain — one for your support platform, one for your marketing tool, one for transactional mail. Separate selectors let you rotate or revoke a single source’s key without disturbing the others. Because the selector is part of the DNS lookup, multiple keys coexist under the same domain without conflict.

What key length should a DKIM key use?

Use 2048-bit RSA. 1024-bit keys still validate but are considered weak, and some receivers treat them less favorably. 512-bit keys are effectively broken and should never be used. The only practical caution with 2048-bit keys is that the public key may exceed the 255-character limit of a single DNS TXT string, so it must be split into multiple quoted strings within one TXT record — most DNS providers and SES handle this for you.

Will rotating my DKIM key break deliverability?

Not if you do it with overlap. Publish the new selector’s public key in DNS and let it propagate before you switch signing to the new key, and keep the old selector’s record live until no mail in flight still references it. Because each key lives under its own selector, the new and old keys validate independently during the overlap window, so no message is left unverifiable.