In Amazon SES, what is the difference between Easy DKIM and BYODKIM, and when would you choose BYODKIM?

## What SES is actually deciding here DKIM attaches a signature header to each outbound message; the receiving mail server looks up a public key in DNS at `<selector>._domainkey.<domain>` and verifies the signature. The signing algorithms, canonicalisation and header selection are the DKIM protocol's own subject and are covered elsewhere. What SES makes you decide is narrower and entirely operational: **who generates and holds the private key, and who is responsible for rotating it.** That single choice is the whole of Easy DKIM vs BYODKIM. ## Easy DKIM When you set up a domain identity with Easy DKIM, SES generates the key pair inside the region and returns three DKIM tokens. You publish three CNAME records of the shape: ``` <token1>._domainkey.example.com CNAME <token1>.dkim.amazonses.com <token2>._domainkey.example.com CNAME <token2>.dkim.amazonses.com <token3>._domainkey.example.com CNAME <token3>.dkim.amazonses.com ``` The key point is the indirection. Your DNS delegates the record to SES-hosted DNS, so SES can rotate the key behind the token without you making a DNS change. Three tokens exist so rotation can happen with overlap. You choose the key length through `NextSigningKeyLength` (`RSA_1024_BIT` or `RSA_2048_BIT`). Verification is asynchronous: the identity's DKIM status moves from `PENDING` to `SUCCESS` once SES sees the records, and it can regress to `FAILED` if the records disappear. Nothing stops SES from sending while the status is not `SUCCESS` — the mail simply goes out unsigned, which is exactly the silent failure that wrecks DMARC alignment later. Easy DKIM tokens are **per identity per region**. Verifying `example.com` in `us-east-1` does not verify it in `eu-west-1`; the second region issues its own three tokens and needs its own three CNAMEs. ## BYODKIM Bring Your Own DKIM inverts the ownership. You generate an RSA key pair yourself, choose a selector, and hand SES the private key: ``` aws sesv2 put-email-identity-dkim-signing-attributes \ --email-identity example.com \ --signing-attributes-origin EXTERNAL \ --signing-attributes DomainSigningSelector=sel1,DomainSigningPrivateKey=<base64-der> ``` You then publish a single TXT record at `sel1._domainkey.example.com` containing the public key. SES signs with the key you gave it and nothing else. Rotation is now a procedure you own: generate a new key, publish a TXT record under a **new** selector, switch SES to that selector, and only retire the old TXT once mail signed with it has aged out of receivers' verification window. Skipping the overlap breaks verification for in-flight messages. ## Choosing between them Easy DKIM is the default answer, and an interviewer expects you to say so. Automatic rotation is a real operational win, and the CNAME delegation means one DNS change ever. BYODKIM earns its extra work in a few concrete situations: - **Key custody is a compliance requirement.** Some organisations mandate that signing key material is generated inside their own process and never issued by a vendor. - **The same domain signs through more than one provider.** If SES sends transactional mail and another platform sends marketing from the same domain, reusing one key and selector keeps the DNS surface small and the signing behaviour identical. - **Multi-region SES with one selector.** BYODKIM lets `us-east-1` and `eu-west-1` sign with the same selector, rather than six CNAMEs across two regions. - **DNS constraints.** Some DNS setups make those specific CNAMEs awkward; a single TXT record is easier. ## Where it bites in production The common incidents are all about the DNS records outliving nobody's attention. Someone migrates DNS providers and does not copy the `_domainkey` records across; SES quietly starts sending unsigned mail; DKIM no longer authenticates, and if SPF is not aligned either, DMARC-enforcing receivers start rejecting. Because SES keeps returning message IDs, nothing in your application logs looks wrong. Watch the identity's DKIM status as a monitored signal, not a one-time setup step. With BYODKIM the recurring failure is rotation that never happens because it is manual and undocumented, and private keys that end up in a git repository because someone needed them at deploy time. If you take custody of a key, take custody of its storage too — Secrets Manager or an equivalent, not a config file. One more subtlety worth stating: DKIM survives forwarding in a way envelope-based authentication does not, because the signature travels with the message. That is why DKIM, not SPF, is usually the authentication mechanism that keeps mail authenticated after a mailing list or a corporate forwarder touches it — and it is why getting DKIM right in SES matters more than it first appears.