Why AWS SES Emails Get Rejected by Corporate Gateways

When your AWS SES emails work perfectly for Gmail but mysteriously disappear into the void for corporate addresses, you're experiencing one of the most frustrating email delivery problems in cloud computing. The dashboard shows successful deliveries, but your recipients never see the message.

The False Positive Problem

Here's what makes this issue particularly deceptive: SES reports successful delivery because the initial SMTP handshake completes. The corporate mail gateway accepts the connection and returns a 250 OK response, making SES believe everything worked. Only afterward does the gateway perform deeper validation checks and silently reject the email without notifying SES.

This creates a perfect storm where your metrics lie to you. You see 100% delivery rates in the AWS console, but your actual recipients never receive the emails. The gateway accepts the connection (SMTP 250 OK) then runs additional checks: domain existence, SPF, DKIM. It quietly rejects the email with a 553 error without delivery notifications, these bounces are invisible.

The DNS Configuration Trap

Most developers check the obvious things first: SES in production mode, correct from addresses, proper DKIM configuration, and suppression lists. When everything seems correct but delivery still fails, the culprit is often hidden in DNS records.

The specific issue I encountered involved the MAIL FROM domain configuration in SES. When you set up custom MAIL FROM domains, AWS SES uses that domain in the SMTP envelope's return path. However, RFC 5321 requires that this domain must be resolvable - it needs valid A or AAAA records.

My configuration used mail.mydomain.com as the MAIL FROM domain, but this subdomain had no A record. The parent domain had a strict SPF policy: v=spf1 mx ip4:x.x.x.x include:corporate-spf.example.com include:spf.protection.outlook.com -all The -all mechanism means "reject everything not on this list," and without proper DNS records, SES wasn't properly authorized.

The Diagnostic Journey

To uncover what was really happening, I needed better visibility than what the SES dashboard provides. Creating an SNS topic for SES send and delivery events revealed the truth. The notification showed a bounce with diagnostic code: smtp; 553 #5.1.8 Domain of sender address <[email protected]> does not exist

This error indicates the corporate mail gateway couldn't resolve the MAIL FROM domain. The gateway was performing strict RFC compliance checks, rejecting emails where the return path domain lacked proper DNS infrastructure.

The Solution That Worked

Rather than trying to fix the DNS records for the custom MAIL FROM domain, I removed the custom configuration entirely. SES defaults to using amazonses.com as the MAIL FROM domain when no custom domain is specified. This domain is properly configured with all necessary DNS records and is widely accepted by corporate mail gateways.

After removing the custom MAIL FROM domain, emails started delivering to corporate addresses immediately. The key insight is that some strict gateways check for A/AAAA records, not just MX records. Even if your domain has MX records for mail exchange, lacking A records can cause rejection.

Critical Lessons for Production Systems

Never trust dashboard metrics alone. When debugging email delivery, enable delivery notifications through SNS or similar mechanisms. The initial SMTP success doesn't guarantee actual delivery.

RFC compliance matters more than you think. Corporate mail gateways often implement stricter validation than consumer services like Gmail. What works for personal email accounts may fail in enterprise environments.

DNS completeness is essential. If you use custom MAIL FROM domains with SES, ensure they have proper A records (and preferably AAAA records for IPv6 compatibility). The domain must be fully resolvable, not just configured for mail exchange.

SPF inheritance can cause unexpected failures. Subdomains without their own SPF records inherit parent domain policies, which may be too restrictive for your sending infrastructure.

This experience taught me that email delivery in enterprise environments requires understanding both your sending infrastructure and the receiving infrastructure's validation rules. The gap between what SES reports and what actually happens can be significant - always implement proper monitoring and logging to bridge that gap.