Email with SES

In 1 minute

Amazon SES (Simple Email Service) sends email only from an identity we have proven we own. MiniTickets verifies its whole domain with DKIM: SES signs every email, and three DNS records let any receiving mail server check the signature. The worker sends from no-reply@minitickets.theversehub.in. A refused send is a normal failed message: retried, then the dead-letter queue.

Picture it

flowchart TB
  W["worker Lambda"] -->|"SendEmail<br/>From: no-reply@…"| S["SES"]
  S -->|"signed with DKIM"| G["receiver<br/>(Gmail, …)"]
  G -->|"look up the public key"| D["DNS: 3 CNAMEs<br/>at Cloudflare"]

How it works

1. Prove the domain. The SES domain identity uses Easy DKIM (RSA 2048): AWS makes and rotates the keys. We add three CNAME records once, at Cloudflare, with the proxy off.
2. SES checks the records on its own, for up to 72 hours. Until the identity is verified, every send fails.
3. The worker sends a plain-text email with SendEmail. The worker role allows it only for our identities and only when ses:FromAddress is no-reply@minitickets.theversehub.in.
4. The receiver checks the signature against the public key in our DNS. Signed mail is far less likely to land in spam.
5. A refusal throws. The message is reported as failed, retried with backoff, and after 3 receives sits in the DLQ.

In MiniTickets

The account is in the SES sandbox, where every new account starts: 200 emails per 24 hours, 1 per second, and only TO verified addresses. That is why one test address (sesTestRecipient) is verified as well. A booking by any other address fails with “Email address is not verified” and ends in the DLQ, a live example of the failing-email flow. Leaving the sandbox is a request to AWS, reviewed by a person.

The identities are always on: they are free, and the DNS records stay valid only while the identity exists. The worker logs only the recipient’s domain, never the address.

From → to	What happens	What allows it
SES email identities → Public DNS	receiving mail servers check the DKIM signature against our DNS	dns 3 CNAMEs <token>._domainkey.minitickets.theversehub.in → <token>.dkim.amazonses.com (stack output sesDkimRecords)createEmail
Worker Lambda → SES email identitiesonly when computeEnabled = true	SendEmail from no-reply@minitickets.theversehub.in	iam worker role SendBookingEmails: ses:SendEmail on our identity ARNs, condition ses:FromAddress = no-reply@minitickets.theversehub.increateWorkerRole config env MAILER ses and MAIL_FROM no-reply@minitickets.theversehub.increateWorkerLambda

See SES and its DNS records on the map →

See it in AWS

Console

Amazon SES → Identities → minitickets.theversehub.in (DKIM: Successful); Account dashboard for the sandbox status.

CLI

aws sesv2 get-account shows the sandbox status and the sending quota.

Code

infra/src/jobs/email.ts → createEmail and apps/worker/src/ses-mailer.ts → SesMailer.

Break it

Symptom	Cause	Where to look
MessageRejected: Email address is not verified	Sandbox: the recipient is not verified	Worker log, minitickets-dev/errors
Every send fails; the identity stays pending	DKIM CNAMEs missing, or proxied at Cloudflare	SES → Identities → DKIM
AccessDenied on ses:SendEmail	The From address differs from the one in the condition	Worker role policy

Say it in an interview

Say it like this (20-30 seconds)

The worker sends through SES from a domain identity verified with Easy DKIM: three CNAME records publish the public keys, so receivers can check each signature. The worker role may call SendEmail only on our identities and only with our From address. The account is still in the SES sandbox, so only verified recipients work; other sends fail, retry with backoff, and land in the dead-letter queue with an alarm.

Follow-ups

What does DKIM prove, and what does it not?

It proves the email came from a server holding our domain’s key and was not changed on the way. It says nothing about whether the content is wanted. SPF with a custom MAIL FROM and DMARC are not built yet.

Does more Lambda concurrency send more email?

No. SES has its own sending rate (1 per second in the sandbox). That is one reason the worker runs at most 5 batches at once.

What should happen to an address that can never receive mail?

Today it retries 3 times and reaches the DLQ. In production you would use SES’s suppression list and bounce events, so permanent failures are not retried.

Advanced: Details: the DNS records

Each record is <token>._domainkey.minitickets.theversehub.in CNAME <token>.dkim.amazonses.com, from the stack output sesDkimRecords. They are public, not secrets. Our DNS lives at Cloudflare, not Route 53, so they are added by hand.

Checkpoint

Answer these without scrolling up. If one feels hard, reread that section.

1. What is an SES identity?
2. What do the three CNAME records hold?
3. Which two things does the worker role’s SES statement restrict?
4. What are the three sandbox limits?
5. What happens to a booking email sent to an unverified address?

Redraw it from memory: worker → SES (From: no-reply@…) → receiver → DNS DKIM CNAMEs (check signature)

Try this: on the map, select SES and follow its arrow to the public DNS; read what allows it

Mark this page as read