In Amazon SES, what is the difference between verifying a domain identity and verifying an email address identity, and which should a production service use?

## Why identities exist at all SES will not let an arbitrary account send mail claiming to be `[email protected]`. Before any send, you must hold a **verified identity** proving control of the From address or its domain. This is the anti-abuse floor of the service, and it applies both inside and outside the sandbox. There are exactly two identity types. ## Email address identity You call `CreateEmailIdentity` with an address (or add it in the console). SES sends a confirmation link to that mailbox; someone clicks it; the identity becomes verified. The scope is *that one address, in that one Region*. This is genuinely useful for a developer's own address during early testing, or for a one-off sender. Its limits show up fast in production: - Every new From address is a fresh manual verification, each needing a real mailbox and a human. - The addresses a product actually wants to send from — `no-reply@`, `alerts@`, `receipts@` — often have **no mailbox at all**, so there is nobody to click the link. - The verification is tied to a person's ability to read that inbox, which quietly breaks when they leave. ## Domain identity You create the identity for the domain (`example.com`) and SES gives you DNS records to publish in the zone. Publishing them proves you control the domain, because only whoever controls the zone can add records to it. In practice SES's modern flow hands you a set of CNAME records that both verify the domain and turn on DKIM signing, and if the domain is hosted in Route 53 the console can write them for you. Once verified: - **Any local part** at that domain can be the From address, with no further verification. `[email protected]` and `[email protected]` just work. - A verified parent domain generally covers sending from its subdomains; you verify a subdomain separately when you want it to carry its own DKIM keys or its own configuration. - Domain-level features hang off this identity, because they are properties of the domain rather than of one mailbox. This is why every real service verifies the domain. It is one setup, done by whoever controls DNS, and it never needs revisiting when the product adds a new sender address. ## The operational traps **Region scope.** An identity is a per-Region resource. The DNS records are published once in the zone, but the identity must be created and verified in each Region you send from. Deploying a sender to a second Region without doing this is a top-two SES incident. **DNS fragility.** SES rechecks the records. If a zone migration, a Terraform refactor, or a registrar change drops them, the identity can move to a failed state and sends from it start failing. Treat the SES records as production infrastructure and monitor the identity's verification status, rather than assuming that verified once means verified forever. **Verification is not deliverability.** A verified identity means SES will *accept* your message. Whether Gmail puts it in the inbox is a separate matter of domain authentication and reputation. Candidates who conflate the two — "we verified the domain so DMARC is fine" — are exposing a real gap. **Ownership.** The DNS records mean the team that controls the zone effectively controls who can send as the company. That is the correct place for the control to sit, and it is worth saying out loud: it is why an email identity for a shared address is a weaker control than the domain identity plus a scoped IAM permission to send. ## Choosing, in one line Email identity for a developer sandbox or a genuine one-address special case; domain identity for anything a customer will receive.