How does Amazon SES evaluate automatic production access approvals while protecting shared IP reputation?

These are very fair questions. Legitimate senders who maintain low bounce and complaint rates should not see their deliverability undermined by abuse on shared infrastructure. AWS should provide more clarity about its automatic approval safeguards and strengthen them where necessary.

I would also appreciate more information about this. The reputation of the shared Internet Protocol address pools affects every customer using them, so understanding how Production Access decisions are made would be very helpful.

Two of your questions can't be fully answered publicly, and two can — let me be explicit about which is which, and challenge one assumption along the way.

Q1 & Q2 — Automatic approval conditions and pre-approval risk assessment

AWS does not publish the criteria or automation behind production access decisions — that's deliberate, not an oversight. Any published rule set becomes a checklist for abuse.

What is documented (Request production access):

• The request captures mail type, website URL, use case, and an acknowledgement of opt-in sending and bounce/complaint handling.

• AWS targets an initial response within 24 hours.

• Verifying your domain (not just email addresses) before requesting access helps get approved faster.

• The decision sits with the SES Trust & Safety team.

Whether some requests follow an accelerated path vs. manual review is an internal implementation detail. If you have process-level concerns, the right channel is your account team/TAM or AWS Support — not re:Post. Suspected abuse goes to the AWS abuse form.

Q3 — Balancing onboarding speed vs. shared pool reputation

The safeguards are weighted toward continuous post-approval enforcement rather than heavy pre-approval gating (Sending review process FAQs):

• Bounce rate: best practice < 2% → under review at ≥ 5% → may be paused at ≥ 10%

• Complaint rate: best practice < 0.1% → under review at ≥ 0.1% → may be paused at ≥ 0.5%

• Rates use a representative volume per account, not a fixed time window.

• For serious violations, AWS can pause immediately with no review period.

• The stated purpose: protecting sender reputation and preventing other SES users from experiencing service interruptions and deliverability issues.

The design intent is that bad actors who pass onboarding get caught by behavioural signals shortly after they start sending, rather than slowing every legitimate sender with a heavier gate.

Q4 — Recommendations beyond dedicated IPs

Before spending on dedicated IPs, test whether the shared pool is actually the cause. In 2024-2026, inbox placement at major providers is driven more by domain/sender reputation than IP reputation. Three common causes of "good metrics, declining placement":

1. Check domain vs. IP reputation separately

Google Postmaster Tools shows domain reputation and IP reputation as separate dashboards. If your domain is Low/Bad while the shared IP is fine, dedicated IPs won't help. Add Microsoft SNDS for Outlook visibility.

2. Your SES complaint rate likely understates reality

SES only counts complaints received via feedback loops — Gmail measures spam rate on their side independently. Google's threshold is < 0.10% (never ≥ 0.30%). You can sit under SES's 0.1% while Gmail sees something much higher. Compare side by side in Postmaster Tools.

3. Verify DMARC alignment, not just DMARC pass

A common failure: DKIM signs with an SES-owned domain while From: uses yours — both SPF and DKIM "pass" but DMARC alignment fails. Check raw Authentication-Results headers from delivered messages. Also confirm 2024 bulk-sender requirements: one-click unsubscribe (RFC 8058), opt-outs within 2 days, valid forward/reverse DNS, TLS.

4. Separate streams by subdomain

Use different subdomains for transactional vs. marketing (mail.example.com / news.example.com). Set up a custom MAIL FROM domain for SPF alignment. This is the highest benefit-to-cost change and works on shared IPs.

5. Enable Virtual Deliverability Manager

VDM gives per-ISP inbox placement data, turning "declining placement" into actionable per-provider diagnostics.

6. Engagement-based suppression

Remove recipients who don't open/click over a defined window. Low engagement is a negative signal at Gmail/Microsoft independent of complaints — invisible in bounce/complaint metrics.

7. Dedicated IPs — with caveats

Only after the above. AWS documents that dedicated IPs at low or irregular volume can cause deliverability problems. If splitting traffic across multiple accounts, each pool gets a fraction of total volume, worsening the issue. Dedicated IPs (managed) is the lower-risk option if you proceed.

8. If you still believe it's the pool

Open a Support case with: Postmaster Tools showing healthy domain reputation + degraded IP reputation, affected identities and Region, decline timestamps, and raw headers from spam-foldered messages.