Amazon SES production access denied? What to do next

• A brand-new AWS account. No billing history and no other AWS usage gives the reviewer nothing to go on. This is the most common situation in denial threads, and the one you can't fix on the form.
• A website that doesn't explain the mail. A placeholder page, a login wall, a site on a different domain from the one you'll send from, or no privacy policy or terms. The reviewer uses the URL to understand what you'll send.
• A vague use case. "Sending emails to our users" doesn't say which emails, what triggers them, who receives them or how many.
• No opt-in story. Nothing says how recipients' addresses were collected. Anything that sounds like purchased lists, scraped addresses or cold outreach is denied.
• No bounce and complaint handling. The form makes you acknowledge a process; requests that describe one (event destinations, the suppression list, removing bad addresses) read as lower risk.
• Marketing mail type on a new account. Choosing Marketing, or describing promotional sends, invites more scrutiny than one-to-one transactional mail.
• Unverified or unauthenticated domain. AWS's own docs say verifying your domain before you request access helps the request get approved faster.

1. 1

   Verify the domain and authenticate it

   Verify your sending domain (not just an address) with Easy DKIM, set up a custom MAIL FROM subdomain so SPF aligns, and publish a DMARC record. The SPF, DKIM and DMARC guide covers each record.

2. 2

   Make the website match the mail

   The URL you give should load publicly, be on the domain you'll send from, and show the product, a sign-up form, a privacy policy and terms. If the app is behind a login, link a public page that describes it.

3. 3

   Pick the right mail type

   If most of your mail is sign-in codes, password resets, receipts and alerts, choose Transactional. Don't describe newsletters or promotions you might send someday.

4. 4

   Write the use case in full

   List each email you'll send, what triggers it, who receives it and roughly how many per day and per month. Say how recipients' addresses are collected (they sign up for your product) and that you never buy or rent lists.

5. 5

   Describe bounce and complaint handling

   Say you publish bounce and complaint events from a configuration set to SNS or EventBridge, keep the account-level suppression list on, and stop sending to addresses that bounce or complain. Build it before you claim it.

6. 6

   Include the use case with the request

   The console form no longer has a use-case box, but the API does. aws sesv2 put-account-details accepts --use-case-description (up to 5,000 characters) next to the mail type and website URL.

7. 7

   Answer follow-ups in the same case

   If AWS replies asking for more information, answer every question in that case. Opening a new request while one is open fails, and the clock starts again.

aws sesv2 put-account-details \
  --region us-east-1 \
  --production-access-enabled \
  --mail-type TRANSACTIONAL \
  --website-url https://acme.com \
  --contact-language EN \
  --additional-contact-email-addresses ops@acme.com \
  --use-case-description "Acme is a project management app (https://acme.com).
We send only transactional email to users who created an account:
sign-in codes, password resets, invoices and notifications they enable in settings.
Expected volume: about 500 emails a day, 15,000 a month.
Addresses come from our sign-up form only; we never buy, rent or import lists.
Bounces and complaints are published from a configuration set to SNS; our app
suppresses those addresses immediately, and the account-level suppression list is on.
Sending domain acme.com is verified with Easy DKIM, a custom MAIL FROM and DMARC."

1. 1

   Create an account and send a test

   Sign up free and click Send test email on Home. It goes to your account email from our test sender, with no domain or API key needed, so you can see sending work in the first minute.

2. 2

   Add your domain

   Add the domain you send from in the dashboard, or with POST /domains. If you already verified it in SES, keep those records: Groundmail uses its own DKIM selector and return-path name, so both can be published at once.

3. 3

   Publish your DNS records

   Groundmail gives you an ownership TXT, a DKIM TXT on its own selector, a return-path CNAME rp.yourdomain.com pointing to rp.groundmail.dev, an SPF include and a monitor-only DMARC record. Ownership, DKIM, the return path and SPF must verify before you can send; DMARC is recommended but doesn't block verification. On Cloudflare, GoDaddy and Vercel, one-click apply writes them for you. If your root domain already has an SPF record, add include:spf.groundmail.dev to it rather than publishing a second one.

4. 4

   Add a card on file

   On the Free plan a card unlocks sending to recipients other than you. It isn't charged: Free is 3,000 emails a month, 100 a day, with no time limit. Pro is 50,000 emails a month for $20.

5. 5

   Send from your app

   Create a send-only API key and call POST https://api.groundmail.dev/emails, use an SDK, or point any SMTP client at smtp.groundmail.dev on port 587. Delivery events arrive on signed webhooks, and bounces and complaints are suppressed for you, so there's no event pipeline to build.

// npm install groundmail
import { Groundmail } from "groundmail";

const gm = new Groundmail(process.env.GROUNDMAIL_API_KEY);

await gm.emails.send({
  from: "Acme <no-reply@acme.com>",
  to: "ada@example.com",
  subject: "Your sign-in code",
  text: "Your Acme sign-in code is 482913. It expires in 10 minutes.",
});

curl -X POST https://api.groundmail.dev/emails \
  -H "Authorization: Bearer $GROUNDMAIL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "Acme <no-reply@acme.com>",
    "to": "ada@example.com",
    "subject": "Your sign-in code",
    "text": "Your Acme sign-in code is 482913. It expires in 10 minutes."
  }'

What you can send

• Transactional and product email to your own users: sign-in codes, password resets, receipts, invoices, alerts and notifications people turned on. Transactional mail goes out on its own servers and IPs, kept separate from product mail.
• Not cold outreach, bought or scraped lists, or bulk promotions. Mail from new accounts is checked for spam before it goes out, and accounts with high bounce or complaint rates are paused.
• Volume grows with a clean record. Free is 100 emails a day. Paid accounts start at 3,000 transactional and 1,000 product emails a day, and the limit doubles each day you use at least half of it while bounces stay under 2% and complaints under 0.1%. Moving an existing sender with real volume? Email support@groundmail.dev.