Every AWS account starts with SES in sandbox mode. To send email to real recipients at scale, you need to request **production access** from AWS. This is a manual review process — AWS evaluates your sending practices, infrastructure, and compliance before lifting sandbox restrictions.

The good news: when you're sending through SendOps, most of what AWS looks for is already in place — and you can submit the whole request without leaving SendOps.

## Request it from inside SendOps

You don't need to open the AWS console. SendOps has a built-in **Production Access** request flow — open it from **Infrastructure → Production Access**, or click **Request Production Access** on the AWS status badge in the sidebar.

SendOps **pre-fills most of the request** from what it already knows about your account — your verified domains, your configuration sets (channels), and your last-30-day sending volume — and drafts a suggested use-case description plus an infrastructure summary. You review those, pick a **mail type**, confirm your **website URL**, and submit. SendOps sends the request **directly to AWS** (no support-ticket copy-paste), then **polls AWS for you**: the status on the page moves from pending to under review to granted, and you get a notification the moment your account is approved.

The rest of this page explains what AWS evaluates and how to make your request strong — useful whether you submit through SendOps or, if you prefer, the AWS console.

## Before you request

Make sure you've completed these steps before submitting your production access request:


  <Step title="Verify your domain and configure DNS">
    Your sending domain should have DKIM, SPF, and DMARC records fully configured and passing verification in SendOps. See [DNS Configuration](/domains/dns-configuration) for details.
  </Step>
  <Step title="Have a working website on your sending domain">
    AWS reviewers will visit your domain. Make sure there's a real website at the domain you'll be sending from — it should clearly explain what your business does.
  </Step>
  <Step title="Connect SendOps and confirm events are flowing">
    Your AWS account should be connected to SendOps and receiving delivery events (bounces, complaints, deliveries). You can verify this on the Messages Dashboard.
  </Step>
  <Step title="Complete at least one test send">
    Send a test email through SES to a verified address to confirm your integration is working end-to-end.
  </Step>
  <Step title="Configure your channels">
    Set up separate channels for transactional and marketing email. This demonstrates to AWS that you manage different traffic types independently. See [Understanding Channels](/channels/understanding-channels).
  </Step>
  <Step title="Set up notification thresholds">
    Configure bounce and complaint notifications so your team is alerted before rates become problematic. See [Configuring Notifications](/notifications/configuring-notifications).
  </Step>


## What AWS evaluates

AWS reviewers assess your request against several criteria. Understanding what they're looking for helps you write a stronger application.

### Sending use case clarity

AWS wants to know exactly what kinds of email you'll send, who receives them, and why. Be specific — "transactional emails" is vague; "order confirmations, password resets, and shipping notifications sent to customers who made a purchase" is clear.

### Bounce handling

Reviewers look for evidence that you detect and act on bounces. They want to know that hard-bounced addresses are suppressed and won't receive future sends. AWS takes this seriously because high bounce rates degrade SES's shared infrastructure.

### Complaint processing

When a recipient marks your email as spam, that feedback needs to flow back to you and result in action. AWS wants to see that you process complaints and stop sending to recipients who complain.

### List quality and consent

AWS wants assurance that your recipients opted in to receive your emails. They look for clear consent mechanisms — double opt-in, sign-up forms, purchase relationships — and evidence that you don't send to purchased or scraped lists.

### Unsubscribe mechanism

Every marketing email must include a working unsubscribe link. AWS also looks for support of the `List-Unsubscribe` header, which enables one-click unsubscribe in email clients.

### Sending volume expectations

Provide realistic volume projections. AWS is wary of new accounts requesting millions of sends immediately. They prefer to see gradual ramp-up plans that start small and grow over weeks.

### Deliverability monitoring

AWS wants to know you're watching your metrics. They look for dashboards, alerting, and processes that let you catch problems before they escalate.

## How SendOps addresses each requirement

If you're using SendOps, you already have infrastructure in place for every concern AWS evaluates:

| AWS requirement | How SendOps handles it |
|---|---|
| **Bounce monitoring** | Real-time bounce detection and notifications. Bounces are tracked per-channel with configurable alert thresholds. |
| **Complaint handling** | Complaint events are captured automatically via SES feedback notifications. Alerts fire when complaint rates exceed your thresholds. |
| **Reputation tracking** | Deliverability reports show bounce rates, complaint rates, and engagement metrics across all channels and domains. |
| **Traffic separation** | Channels let you isolate transactional, marketing, and other traffic types with independent monitoring and thresholds. |
| **Audit trail** | The audit log records all configuration changes. Message-level event history tracks every delivery, bounce, and complaint. |
| **DNS and authentication** | Domain onboarding verifies DKIM, SPF, and DMARC configuration. SendOps alerts you if DNS records are missing or misconfigured. |
| **Deliverability monitoring** | The Messages Dashboard and engagement metrics give you real-time visibility into sending health. |


  You can include a link to this page (or to your SendOps dashboard) in your production access request to demonstrate the infrastructure backing your sends.


## Writing your production access request

The request is the same whether you submit it through SendOps (recommended — see above) or manually through the AWS Console under **SES → Account dashboard → Request production access**. Here's how to fill out each field effectively.

### Mail type

Choose the type that best describes your primary sending:

- **Transactional** — triggered by user actions (receipts, password resets, notifications)
- **Marketing** — promotional campaigns, newsletters, product updates

If you send both, select **Transactional** as the primary type and explain the full picture in your use case description.

### Website URL

Enter the URL of the website associated with your sending domain. AWS reviewers will visit this site, so make sure it's live, professional, and clearly explains your business.

### Use case description

This is the most important field. Be thorough and specific. Cover:

- **What** you send (email types)
- **Who** receives it (how they opted in)
- **How** you handle bounces and complaints
- **What infrastructure** you use to monitor deliverability

Don't be vague. The more detail you provide about your sending practices, the faster your request gets approved.

### Responding to follow-ups

AWS sometimes asks follow-up questions. Common ones include:

- "How do you handle hard bounces?" — Explain that SendOps detects bounces in real time and your team is notified via configurable alerts.
- "How do recipients opt in?" — Describe your specific sign-up or consent process.
- "What's your expected sending volume?" — Give a realistic monthly number and mention you plan to ramp up gradually.

## SendOps fills most of this in for you

When you submit through SendOps, most of the request text is **generated for you** — your verified domains, configuration sets, and 30-day sending volume are dropped straight into a drafted use-case description and infrastructure summary. You mainly fill in the specifics of *what* you send and *how recipients opt in*, then submit.

If you'd rather write the request yourself (or you're submitting through the AWS console), here's a template you can adapt:


  Replace the bracketed sections with your specific details. The structure is designed to address every concern AWS reviewers typically look for.


> We are requesting production access for SES to send [transactional / marketing / both transactional and marketing] email from [your domain].
>
> **Use case:** We send [describe your email types — e.g., order confirmations, shipping notifications, account alerts, and a weekly product newsletter] to [describe your recipients — e.g., customers who created an account on our platform and opted in to receive communications].
>
> **Consent and list management:** All recipients have explicitly opted in through [describe your opt-in mechanism — e.g., account registration, checkbox during checkout, double opt-in for newsletter]. We do not send to purchased or third-party lists.
>
> **Bounce and complaint handling:** We use SendOps (https://sendops.dev) as our email operations platform on top of SES. SendOps monitors all delivery events in real time, including bounces and complaints. Our team receives automated alerts when bounce or complaint rates exceed configured thresholds. Hard bounces are tracked and surfaced immediately so we can take action.
>
> **Infrastructure and monitoring:** SendOps provides deliverability reports, engagement metrics, and per-channel monitoring. We use separate channels for transactional and marketing email, each with independent bounce and complaint tracking. All configuration changes are recorded in an audit log.
>
> **DNS and authentication:** Our sending domain is fully configured with DKIM, SPF, and DMARC, verified through SendOps's domain onboarding process.
>
> **Volume:** We expect to send approximately [number] emails per month initially, ramping up gradually over [timeframe] as our user base grows. Our initial daily volume will be approximately [number] emails per day.
>
> **Unsubscribe:** All marketing emails include a visible unsubscribe link. We support the List-Unsubscribe header for one-click unsubscribe in supported email clients.

## After approval

Once AWS grants production access:

- **Sandbox restrictions are lifted** — you can send to any recipient without pre-verifying their address.
- **Your initial quota** is typically 50,000 emails per day with a sending rate of 14 emails per second. These limits increase automatically as AWS observes good sending practices.
- **SendOps detects the change** — your account status updates in SendOps, and any sandbox-related warnings are cleared.


  Don't jump to high volumes immediately after approval. Start with a fraction of your quota and increase over days or weeks. Sudden spikes from a new account can trigger SES reputation alarms, even with production access. A good rule of thumb is to double your daily volume every 2–3 days until you reach your target.


### Initial sending limits

| Metric | Typical initial limit |
|---|---|
| **Daily sending quota** | 50,000 emails per 24-hour period |
| **Maximum send rate** | 14 emails per second |

These limits grow automatically. AWS evaluates your sending patterns continuously and raises your quota as you demonstrate consistent, low-bounce, low-complaint sending.

## If your request is denied

Denials happen, usually because the request lacked detail. AWS rarely explains exactly what was missing, but common reasons include:

- **Vague use case** — "We send emails to customers" isn't enough. Specify email types, recipient relationships, and consent mechanisms.
- **No bounce/complaint handling described** — AWS needs to know you have systems in place. Reference your SendOps setup and monitoring.
- **No website or non-functional domain** — AWS checks your sending domain. Make sure there's a live, professional website.
- **Unrealistic volume** — Requesting millions of sends for a brand-new account raises flags. Start with modest numbers and a ramp-up plan.

### How to resubmit

You can submit a new request immediately. When resubmitting:

1. Add significantly more detail than your first attempt
2. Address the specific area you think was weak
3. Reference your monitoring infrastructure explicitly
4. Include the link to your SendOps dashboard or this documentation page
5. Keep volume projections modest with a clear ramp-up plan

## What's next?

- [SES Sandbox & Production](/sending-email/ses-sandbox) — understand sandbox limitations in detail
- [Configuring Notifications](/notifications/configuring-notifications) — set up bounce and complaint alerts
- [Deliverability Reports](/reports/deliverability-reports) — monitor your sending health
- [Understanding Channels](/channels/understanding-channels) — separate transactional and marketing traffic