Your Email Code Is Fine — Your New Sending Account Is Gated
New SES and Postmark accounts can't email arbitrary recipients — sends fail in ways that look like a code or DNS bug. The gates that block you, and how to clear them.
You wire up transactional email — password resets, receipts, a welcome
message. The code is clean. You send a test to your own Gmail and… nothing.
No bounce. No exception you can act on. You spend the next two hours
re-checking SPF and DKIM, re-reading the SDK docs, digging through spam
folders, second-guessing your from address.
The problem usually isn’t your code or your DNS. It’s policy: brand-new sending accounts are gated by default, and the gate doesn’t present as “your email is broken.” It presents as a rejection you can’t explain, or a send that goes nowhere. Two of the most common gates, and how each one actually behaves:
Amazon SES: the sandbox
Every new SES account starts in the sandbox, and it’s per-region. While you’re in it:
- You can send only to verified email addresses and domains (plus the SES mailbox simulator).
- Caps: 200 messages per 24 hours, 1 per second.
Here’s the specific trap that burns people: you verify your sender identity,
celebrate, and send to a recipient that isn’t verified — and SES rejects it
with MessageRejected: Email address is not verified. In the sandbox, the
recipient has to be verified too, not just the sender. So your test to a
personal inbox fails, and the error reads like a configuration mistake rather
than “you’re in a sandbox.”
To get out, you request production access. As of 2024, AWS expects you to have a verified domain with SPF, DKIM, and DMARC already in place before you ask; their Trust & Safety team reviews your use case and your account’s history, and approval typically lands in about a day. A brand-new AWS account with no billing history tends to draw extra scrutiny — so a fresh AWS account plus SES is really two gates stacked: the sandbox, and a cautious human review.
Postmark: pending approval
New Postmark accounts are pending approval, and until they’re approved:
- You can send only to recipients on the domains you’ve added and verified. Sending to a customer at some other domain is blocked — so, again, your test to a personal address quietly goes nowhere.
- To test in the meantime: send to the sink address
test@blackhole.postmarkapp.com(it’s dropped on receipt, but you’ll see the delivery confirmation in Activity), or pass thePOSTMARK_API_TESTserver token to exercise your integration without sending anything real. - Approval is usually under 24 hours on weekdays. Postmark is strict on purpose — they protect the reputation of their transactional streams — and may email you to confirm your mail is genuinely transactional, not marketing.
The pattern, and the lesson
The unifying trap is this: a success response from a send call means “the provider accepted the request,” not “the message was delivered.” During the gated period, accepted ≠ delivered, and there’s often no error in your own logs to grep for — the truth lives in the provider’s console.
What to do differently:
- Assume every new email account is gated. Read the provider’s new-account restrictions before you debug your code or DNS.
- Test to a verified/owned recipient (or the provider’s sink address), not your personal Gmail.
- Treat production access / approval as an explicit setup step — and do the domain auth (SPF/DKIM/DMARC) first, since it’s both the prerequisite and what gets you actually delivered later.
- Don’t trust “Sent.” Trust “Delivered” — wire up a delivery/bounce webhook early so your system knows the difference your code can’t see.
And the meta-call for a brand-new project: when you just need to ship, a provider with a fast, friendly approval (Postmark, Resend) beats one gated behind your AWS account history (SES). You can always move heavy volume to SES later, once there is a history.
Further reading
- AWS — Request production access (moving out of the SES sandbox)
- Postmark — How the account approval process works
- Postmark — All in for transactional delivery: our approval process
I’m Chris Moore — an independent developer and consultant in Henderson, NV, working under Grudged LLC. I help small teams ship and stabilize the systems they run on. If “the email sent but never arrived” is eating your week, get in touch.