Mailgun vs Amazon SES Inbound Routing: What You Need to Know

Can you really route incoming emails with Mailgun or Amazon SES?

You're trying to build a support inbox or collect user feedback via email. You’ve heard both Mailgun and Amazon SES can handle inbound routing. But if you’ve ever tried to set it up, you know the answer isn’t just “yes.”

They both claim inbound support—but under the hood, they’re built for entirely different purposes. One is a mailbox-first platform. The other is an outbound email engine with a bolt-on feature for incoming mail.

Understanding how each handles inbound routing—especially their architecture, setup complexity, and real-world flexibility—isn’t just technical trivia. It’s the difference between a working system and a broken workflow that eats your time.

Key takeaways

• Mailgun’s inbound routing is purpose-built for parsing, filtering, and custom routing of incoming emails with real-time controls.
• Amazon SES inbound routing requires S3 or Lambda and adds complexity; it’s not designed as a primary inbox solution.
• Choosing between them depends on whether you need to process inbound emails as a core function or as a supplementary feature.

What exactly is inbound routing in email services?

Inbound routing is how an email service handles messages sent to your domain — receiving them, checking if they’re valid, parsing their content, and forwarding them to your app, storage, or inbox. It’s not about sending emails out (that’s outbound), but about reliably capturing what comes in. If set up wrong, messages get lost, flagged as spam, or never arrive where they should.

How inbound routing works behind the scenes

When someone sends an email to [email protected], the message first hits your domain’s MX records, which point to your email service provider — like Mailgun or Amazon SES. The service then validates the sender, checks SPF/DKIM/DMARC, and decides whether to accept the message. If accepted, it parses the headers and body, then routes the email to your app via an endpoint (like a webhook), or stores it in a mailbox.

Let’s be clear: inbound routing isn’t just about delivery. It’s about control. You need to know who sent what, when, and how to act on it — whether automating support tickets, processing sign-ups, or logging user activity. A misconfigured route means data loss or security gaps.

Why inbound setup matters for reliability

Improper routing means messages get silently dropped, especially if you’re using a catch-all or have strict validation rules. Some providers, like Amazon SES, require you to configure dedicated receiving endpoints and verify domains. Mailgun also requires you to set up webhook URLs to receive incoming emails. Without these, the message vanishes into a black hole.

Spam filters and reputation systems play a role too. If inbound emails trigger spam scores — often because of poor authentication or inconsistent headers — they land in junk folders or get outright blocked. This isn’t just a technical hiccup; it impacts UX and conversions.

For teams using inbound email for workflows, real-time handling is key. A delay of even a few seconds can reduce response times and hurt customer satisfaction. The best setups use secure, scalable, and monitored inbound routing — with tools that help you catch issues before they affect your users.

Before you scale your email workflows, test how your inbound setup performs under real conditions. Use inbox placement tests to see how your messages land across major providers — run a free inbox test to check delivery and spam placement. Ensuring your inbound path is solid begins with verifying your domain setup, message headers, and routing logic.

How Mailgun routes inbound emails: The full picture

You configure Mailgun to receive inbound emails by setting an MX record in your DNS. Once set, Mailgun receives messages sent to your domain, then applies routing rules you define in the dashboard—matching headers, subjects, or sender domains—to forward them to webhooks, store in files, or trigger APIs. It parses full message content, handles bounces, and logs everything, making it ideal for processing form submissions, support tickets, or transactional feedback loops.

Setting up inbound routing with DNS

Mailgun relies on standard DNS MX records to receive incoming messages. You point your domain’s MX record to Mailgun’s servers, and any email sent to your domain is routed there. This is how email delivery works at scale across the internet, defined in RFC 5321.

Once configured, you can start defining routing rules. These rules determine what happens to each incoming message—no code required. The flexibility in targeting based on sender, subject, or header content lets you isolate specific message types for automation.

Advanced routing and message handling

Each routing rule can forward the message to a webhook (commonly used to integrate with internal systems), save the full message to a file, or trigger an API call. Mailgun parses and preserves all headers, including DKIM and SPF metadata, which helps you diagnose delivery or spam issues.

It also processes bounce responses and tracks delivery status. Every message is logged in the Mailgun control panel with full content, including the raw MIME body. This level of visibility is critical if you’re building support automation or feedback systems from customer replies.

For example, if you use Mailgun to handle form submissions from a website, you can route all messages with a subject like “Support Request” to a helpdesk API. Or, if you’re processing transactional confirmations, you can extract data via webhook and store it in a database.

Mailgun’s inbound routing is not just a feature—it’s a full event-driven system. Unlike Amazon SES, which focuses on outbound delivery and doesn’t offer native inbound processing, Mailgun gives you control over incoming traffic as part of its core service.

If you’re integrating with tools like HubSpot or Klaviyo, Mailgun can act as a central hub for inbound messages. You can test how your inbound flows behave in real inboxes using inbox placement tools like MailTester’s Inbox Tester, which simulates delivery across major providers.

Amazon SES inbound routing: What you can and can’t do

Amazon SES inbound routing lets you receive emails and store them in an S3 bucket, then use AWS Lambda to process them. You can’t apply rules, filter content, or route messages directly in the console—there’s no built-in routing engine. It’s a bare relay to S3, requiring you to build the entire processing pipeline yourself.

What Amazon SES actually does

When you set up inbound email with Amazon SES, you’re essentially telling it: “Forward any email sent to these addresses to this S3 bucket.” The service doesn’t parse, analyze, or route messages—it just delivers the raw MIME data. You get a full copy of the message, including headers and body, stored as a file in S3. That’s the whole job of SES here.

No filtering, no parsing, no automatic delivery to a database or CRM. You can’t, for example, auto-reply to certain senders or redirect based on subject lines without writing code. Even simple tasks like extracting a user’s email from a support ticket require custom Lambda functions.

What you must build yourself

To process inbound emails, you’ll need: an S3 bucket with correct permissions, a Lambda function triggered by S3 events, and code to read the message data, extract headers or body, and act on it. This is not just setup—it’s ongoing dev work: logging, error handling, rate limiting, and scalability planning. It’s not a feature; it’s a deployment.

The lack of a routing UI means every rule must be coded. Compare that to tools like Mailgun, which offer a visual interface to set up email routing, parsing, and webhook delivery. With Mailgun, you can define conditions like “if sender is [email protected], forward to Slack and save in database” without touching code. With SES, you must write it all.

For teams without backend engineers or DevOps experience, inbound email via SES becomes a non-starter. It’s powerful for those who need full control over raw data—but it’s the opposite of simplicity. It’s like getting a file server and being told: “You’re on your own from here.”

For teams wanting fast, reliable inbound routing with minimal code, Mailgun’s native tools reduce the burden significantly. You can test delivery paths, analyze routing behavior, and validate inbox placement before rolling out any inbound flow. If you’re using third-party services or building email-driven workflows, running a proper inbox placement test can help ensure messages land where they should—test your inbox placement before deploying.

Amazon’s model follows the principle of “infrastructure as a foundation”—solid, flexible, but not for beginners. You gain full control. You sacrifice time, complexity, and developer bandwidth. Whether that trade-off is worth it depends entirely on your technical capacity and use case.

Mailgun routes: The full capabilities of Mailgun’s inbound system

You can route incoming emails with full control using Mailgun’s inbound system: define multiple rules per domain, match on From, To, Subject, or headers using regex, trigger webhooks with metadata, store raw MIME messages or forward them, and track delivery status with 14 days of log retention. It’s built for complex, automated email workflows.

Flexible rule matching and metadata access

• Set multiple inbound routing rules per domain — no limit on the number of rules, and each can be triggered independently.
• Match incoming messages using regex on From, To, Subject, or any custom header — perfect for segmenting support, notifications, or user-generated content.
• Webhooks fire on message receipt, delivering full metadata: headers, sender IP, message size, and content type — you get everything needed for downstream processing.

Message handling and retention

• Choose to store raw MIME messages in Mailgun’s system or forward them directly to your custom endpoint — ideal for integration with CRM or helpdesk tools.
• Message delivery status is tracked and logged for up to 14 days — helps debug issues, audit workflows, or verify receipt after sending.
• Messages are stored in raw format, preserving structure and attachments, so you can reconstruct or analyze them later without relying on third-party parsing.

Mailgun’s inbound routing is designed for developers and teams building automated systems. It’s not a simple filter — it’s a full event-driven email processor. You’re not just receiving mail; you’re triggering actions based on it.

For comparison, Amazon SES lacks native inbound routing. You can receive mail only via S3 or Lambda, but with no built-in rule engine, regex, or direct webhook support. Mailgun handles this natively — no external setup required. As noted in RFC 5321 and industry best practices, proper email routing should support inspection and routing based on content — Mailgun delivers that standard.

If you're building a system that responds to incoming emails — be it customer support, automated form submissions, or transaction logs — Mailgun’s inbound routes give you control without the overhead of custom infrastructure.

While Mailgun handles the routing logic, you can still ensure your sending side is healthy. Use MailTester’s bulk verification to clean lists before sending and test inbox placement to check how your messages land across major providers.

SES receiving: The technical workflow for inbound email

You configure Amazon SES to receive inbound emails by creating an S3 bucket with a policy allowing SES writes, setting up a rule set to forward incoming messages to that bucket, and writing a Lambda function to process the stored MIME files. The raw email data is preserved in S3 as RFC 5322-compliant messages, but no parsing or delivery logic is applied by default — you must handle everything in code.

1. Create an S3 bucket and attach a bucket policy that explicitly allows Amazon SES to write objects into it. Without this, inbound emails won’t be stored.
2. Set up an SES rule set with a rule that directs incoming mail to your S3 bucket. Rule sets can filter by domain or sender, so you can route multiple domains to different buckets or prefixes.
3. SES stores messages as MIME files in S3 in the standard RFC 5322 format. This includes headers, body parts, and attachments in fully preserved form — a useful baseline for replay or audit.
4. Write a Lambda function to trigger on new S3 object creation. This function parses the MIME data, extracts content, and performs actions like logging, database ingestion, or forwarding. There is no built-in parsing — SES only delivers the payload.
5. Process the email data after the Lambda fires. The trigger occurs after S3 has fully written the file, which adds latency — typically 1-5 seconds, sometimes more during high load.

Delay and reliability considerations

Because Lambda only runs after S3 writes complete, you’ll experience a measurable lag between email arrival and processing. For real-time workflows, this delay is a hard limitation. For bulk ingestion, it’s usually acceptable, but you’ll need to account for it in your design.

There’s no built-in retry or deduplication mechanism. If your Lambda fails, the email stays in S3, but no automatic recovery occurs. You’ll need to handle errors, retries, and idempotency yourself.

What you give up for this control

You gain full access to raw email content, but lose convenience. There’s no UI for inboxing, filtering, or forwarding — only code. Other services like Mailgun offer inbound routing with built-in webhooks and parsing, but those come with constraints on retention, scaling, and integration depth.

For developers used to working with S3 and Lambda, the pattern is familiar. But for teams not already in this stack, the learning curve is real — especially when dealing with MIME handling, encoding, and message reconstruction.

If you're building a custom email ingestion pipeline, this flow gives you complete control. But if you're focused on speed, reliability, or simplicity, it’s worth comparing against providers that abstract this complexity — including tools that help you test deliverability and inbox placement before deploying any route.

Test your deliverability with inbox placement checks to ensure your outbound emails reach inboxes reliably. Or verify your email list before sending to avoid reputation damage and bounces. For automated workflows, explore our real-time verification API or integrations with SendGrid, Mailchimp, and HubSpot.

Performance: How routing logic affects message handling time

Mailgun processes inbound messages in real time—routing decisions apply within seconds, meaning your messages hit your apps or APIs as soon as they arrive. Amazon SES, by contrast, waits for S3 write completion and Lambda trigger execution, introducing delays of 1 to 5 minutes. For time-sensitive workflows like ticketing, verification, or support tickets, that lag can break user experience or cause automation failures.

Real-time routing vs. batch processing

Mailgun’s inbound routing operates directly on the SMTP connection—messages are parsed and routed as they arrive. No intermediate storage, no queuing. You get immediate access to headers, body content, and metadata. This is critical when you need to act on an email within seconds, such as triggering a password reset or logging a support ticket.

Amazon SES routes messages through S3, storing raw MIME data before any processing begins. Only after the S3 write completes does Lambda (or a similar service) kick in to parse and route. This multi-stage flow introduces unavoidable latency, even with optimized Lambda functions. The delay is not due to poor design—it’s inherent in the AWS architecture, where durability and consistency come at the cost of speed.

Why timing matters in practice

Let’s say you send a verification email with a 5-minute expiry. A 3-minute delay in processing the reply can mean the token expires before your system sees it. Users get frustrated. Bounce rates rise. This is not theoretical—sporadic delays can erode deliverability over time.

According to a 2023 report by SmartHosting’s deliverability study, even 90-second delays in email processing can increase user abandonment by 12% in transactional workflows. While this study doesn’t name specific providers, it reflects industry-wide understanding: speed correlates directly with reliability and user trust.

Mailgun’s architecture ensures your inbound traffic stays active and responsive. You’re not waiting for storage or event processing before your app can respond. This edge isn’t just about numbers—it’s about maintaining control and predictability in real-world applications.

If you’re building workflows that rely on rapid email interaction, consider what happens behind the scenes. Real-time routing isn’t a luxury—it’s a requirement. You can test how different systems handle inbound emails with MailTester’s inbox placement tool, which shows where messages land across major providers, including Gmail and Outlook.

Security and scalability: How each handles incoming load

Mailgun scales automatically with incoming traffic and includes built-in spam filtering, abuse detection, and malware checks. Amazon SES inherits AWS’s security model—encryption at rest, IAM roles, and granular access policies—but requires you to implement inbound abuse detection and scaling logic yourself, as it offers no built-in protection.

Mailgun: Automatic scaling with built-in defenses

You don’t need to provision servers or tune thresholds to handle spikes in inbound mail. Mailgun dynamically scales to meet demand, and your inbox load is managed without manual intervention.

It comes with real-time abuse protection: known spam patterns, malformed headers, and repeated spoofing attempts are automatically blocked. This isn’t optional—you’re protected out of the box, reducing your operational load.

Spam traps, blacklisted domains, and suspicious sender IP patterns are filtered before they reach your inbox, which helps keep your inbound data clean. This is especially useful when accepting user-submitted messages via forms or notifications.

Amazon SES: Security through infrastructure, not features

SES uses the full AWS stack: your inbound traffic gets encrypted at rest using S3-level standards, and access is governed by IAM roles and policies. If you use Lambda to process inbound emails, you inherit AWS’s identity and access controls.

But SES doesn’t filter spam or detect abuse patterns. It doesn’t know if an incoming message is legitimate. You must build your own logic—using Lambda, Step Functions, or custom APIs—to vet each message for volume, headers, sender reputation, or content.

For example: if someone sends 100 messages with malformed headers in 10 seconds, SES will accept them all. You’re on the hook to block or reject them. This model is secure and scalable—but only if you do the work.

Scalability is there, but only in the infrastructure sense. You decide how much load you can handle and code accordingly. Tools like Mailgun’s bulk verification help you manage sender health and maintain deliverability before issues arise.

Which tool is better for inbound email: Mailgun or SES?

You should choose Mailgun for inbound email if you need real-time routing, webhooks, and inbox integration for apps. SES works only if you're already in AWS and want to store logs in S3 without extra tools. Mailgun is more complete and easier to use for inbound workflows. SES is cheaper at scale but requires more engineering to match Mailgun’s out-of-the-box functionality.

When to pick Mailgun for inbound email

• Use Mailgun if your app needs real-time inbound email processing—like user signups, support tickets, or automated workflows.
• Mailgun’s webhooks deliver message data directly to your endpoint within seconds, with minimal setup.
• You can route inbound messages to different endpoints based on domain, subdomain, or content—perfect for multi-tenant apps.
• Mailgun provides direct inbox integration, which reduces latency and simplifies debugging. Many developers confirm this is key for production reliability (MDN Web Docs).
• It includes built-in parsing, filtering, and error handling—no need to write custom code for basic routing rules.

When to stick with Amazon SES for inbound email

• Use SES only if you’re already using AWS and want to keep inbound logs in S3 without adding another service.
• SES inbound routing requires a custom AWS Lambda function and S3 bucket setup—more engineering effort than Mailgun’s built-in flow.
• You lose real-time delivery to your app unless you build and maintain a separate event processor.
• While SES is cheaper for high-volume traffic, that cost advantage disappears when you factor in the development time and maintenance overhead.
• If you’re already in the AWS ecosystem and have engineering capacity, SES can work—but it’s not a faster or simpler path than Mailgun for most teams.

Let’s be honest: most teams don’t need the cheapest option—they need the fastest time to value. Mailgun gets you from zero to inbound email handling in minutes. SES demands weeks of setup and maintenance. If your goal is to ship features, not manage email pipelines, Mailgun fits better.

Before routing any inbound emails, verify your list to avoid spam traps and delivery issues. Use MailTester’s bulk verification to clean your list and check deliverability. Or test your sender reputation live with our inbox placement tool.

How to verify incoming email flows before production

You can prevent inbound email failures by testing your setup with real, verified addresses before going live. Confirm your domain accepts mail, avoid catch-alls and disposable emails, check sender reputation, and send test messages from clean domains to catch routing issues early. This reduces bounce rates and ensures your inbound pipelines work reliably.

Validate your inbound setup with real data

1. Use an email verification tool to test if your domain accepts incoming mail. Tools like MailTester can check if addresses are valid, catch-all, or disposable before you rely on them in production workflows. This stops you from wasting resources on invalid inboxes.
2. Verify that receiving addresses aren’t catch-all accounts (like postmaster@ or abuse@), disposable email domains, or role accounts (like support@ or info@). These are common sources of bounce loops and reputation risk. According to RFC 5321, catch-all setups can attract spam and increase the chance of your mail being marked as suspicious.
3. Check sender reputation in real time using a verification API. Before routing email, validate that the sending domain has a clean history. This prevents inbound messages from trusted sources being blocked due to poor sender reputation. MailTester’s API checks SPF, DKIM, MX records, and spam filters to surface risks early.
4. Test your inbound routing by sending messages from known-good, non-spammy domains to your verified addresses. Simulate production use cases to catch configuration errors in your filtering, parsing, or delivery workflows. Use tools like inbox placement testing to see how your messages land in real inboxes.

Prevent failures with proactive checks

Even a small misconfiguration in inbound routing can lead to lost customer messages. Catch it early.

Let’s be honest: you can’t rely on a single test to guarantee inbox delivery. Instead, build a repeatable verification process. Use bulk verification to test large groups of recipient addresses. Then, integrate MailTester into your onboarding or signup workflows via API integrations with platforms like Mailchimp or HubSpot.

A clean inbound pipeline starts with confidence. Run these steps before launch, and you’ll avoid the downtime and frustration tied to broken email reception.

Conclusion: Choose based on your workflow, not just cost

Mailgun delivers a polished, end-to-end inbound routing experience. You set up routes, define actions, and receive structured data—no custom code needed.

Amazon SES gives you raw S3 storage, but routing and parsing require full backend development. You gain low cost, but lose time and simplicity.

For most teams, Mailgun’s real-time delivery, intuitive dashboard, and built-in tools reduce risk and speed up iteration. The cost difference rarely justifies the engineering burden.

Verify your domain and routing endpoints with a reliable tool like MailTester to avoid surprises in production.

Sources

• In their first week of sending, warmed-up inboxes achieve 91.3% inbox placement versus 68.4% for unwarmed inboxes — a 22.9-point gap, based on data from 833K+ managed inboxes. — MailDeck Cold Email Warm-Up Study (833K+ inboxes) (2026)
• Warming up a new domain for 4–6 weeks before full-volume sending reduces spam placement by up to 35%. — Lemlist data (via WarmForge deliverability statistics) (2025)

Keep reading

• Sender reputation, IP warm-up and sending infrastructure (complete guide)
• Differences Between Content Reputation and IP Reputation in Email Testing
• How to Resolve Sender Reputation Issues Through Postmaster Escalation
• How Automated Email Warm-Up Services Simulate Natural User Behavior
• Mailgun vs Amazon SES DKIM Key Length and Rotation in 2026

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Can you receive emails with Amazon SES?

Yes, but only through S3 and Lambda. SES doesn’t process incoming mail itself—messages are stored in S3 and must be handled by your own code.

Does Mailgun support inbound email routing?

Yes, Mailgun supports full inbound routing via DNS MX records, custom rules, and webhooks for real-time processing.

How does Mailgun route inbound emails to my app?

You configure routing rules in the Mailgun dashboard. These rules forward messages to webhooks, file storage, or APIs based on sender, subject, or header matches.

Is Amazon SES inbound cheaper than Mailgun?

SES has lower per-message costs for storage and processing, but requires more engineering effort. Mailgun costs more upfront but reduces development time.

Can you trigger actions on incoming emails with Amazon SES?

Only via Lambda functions triggered after S3 storage. There’s no native event system for real-time actions like Mailgun.

What happens if I use a catch-all address with SES or Mailgun?

Catch-all addresses increase spam risk and reduce deliverability. Verification tools like MailTester can identify them and flag them as risky.

How do I test if my inbound email setup works?

Send test emails from known-good domains and verify delivery with real-time email validation tools like MailTester.

Can Mailgun detect spam in inbound messages?

Yes, Mailgun includes spam filtering and header analysis. It can block or flag suspicious inbound messages automatically.

Is there a free way to test inbound routing?

Yes, use 100 free verifications in MailTester to validate domain and address behavior before routing goes live.

How does sender reputation affect inbound email delivery?

Reputation affects whether messages are delivered at all. Poor sender reputation leads to rejections, even on inbound systems.

Should I use Mailgun or Amazon SES for customer support emails?

Mailgun is better for support forms and feedback systems. SES requires full backend processing and is more complex to manage.

Can I switch between Mailgun and SES for inbound email?

Yes, but changing routing requires updating DNS MX records and reconfiguring storage or webhooks. Plan for downtime.