- Newest
- Most votes
- Most comments
You're absolutely right ,with such low sending volume, building a reputation on a dedicated IP would be slow and potentially problematic without proper warm-up. In your case, switching to a different service for @comcast.net recipients is probably the most practical short-term workaround.
A few low-effort options you could try:
Gmail SMTP or Outlook SMTP: Ideal for very low-volume transactional sends. Just make sure SPF aligns, and you're not hitting provider rate limits.
Transactional email providers like Postmark or Mailgun: They typically have better deliverability to providers like Comcast due to established reputations and managed IPs.
Split routing logic in your app or email platform: Route Comcast traffic via the fallback provider and let SES handle the rest.
If the volume ever increases down the road, a move to SES Managed Dedicated IPs (MDIP) with VDM might make sense, but for now, keeping things simple and reliable is the way to go.
This is actually a frustrating problem that several AWS SES users have run into. First, are you currently in the SES sandbox or do you have production access? That can make a big difference with deliverability. Also, I'm curious - have you confirmed that your SPF, DKIM and DMARC records are all properly set up for your domain? Authentication is really important for getting emails delivered successfully.
A couple other options you could explore:
-
Setting up dedicated IPs instead of using the shared pool -
Opening a support ticket with AWS to investigate the IP routing -
Potentially using a different email service just for Comcast recipients
Yes, this is a known issue with Comcast blocking or rate-limiting AWS SES public IP pool traffic. Comcast aggressively throttles email traffic from certain IP ranges, including AWS's shared/public SES pools, to reduce spam. This affects low-volume senders too, even with proper DKIM and SPF setup.
To reliably deliver to @comcast.net, you need to migrate off the SES public IP pool and use either:
-
Option A: Use a Dedicated IP in SES Request a dedicated IP via SES Dedicated IPs console. This ensures your email reputation is yours alone, no noisy neighbors. Once approved and provisioned, assign the dedicated IP pool to your configuration set and reference that in your send logic. Comcast is far less likely to block a clean, dedicated IP.
-
Option B: Use SES VDM with Managed Dedicated IPs AWS now offers Managed Dedicated IPs (MDIP) as part of Virtual Deliverability Manager (VDM). It auto-scales and manages dedicated IPs for you with better warm-up behavior. Link to AWS VDM with MDIP setup guide
-
Option C (Temporary): Use a Mail Relay like Postmark, Mailgun, or Gmail SMTP If this is urgent and you send very few emails, you can temporarily relay SES output through another service known to have higher Comcast trust. Or configure Gmail SMTP for receipts (for low volumes only).
Why DKIM/SPF alone doesn’t fix this: Even with valid SPF/DKIM/DMARC, your IP reputation is what Comcast uses first to judge the connection. The SES public pool includes senders with poor behavior, which can result in blocks, even for clean senders like you.
Thank you for the responses. Yes I have SPF/DKIM/DMARC set up correctly, although DMARC is set to "report" instead of "enforce". I'm only sending about dozen emails a day, which as I understand it is orders of magnitude too low to build a reputation with a dedicated IP. It sounds like using a different service for Comcast emails is my only option?
Relevant content
- AWS OFFICIALUpdated a year ago

I'm surprised to hear you suggest Postmark or Mailgun. Are their shared IP pools likely to have better reputation/deliverability than the SES shared IP pool?