What are the best practices for email deliverability when using SparkPost and Amazon SES, including reverse DNS, blacklist monitoring, and handling dedicated IPs?
Michael Ko
Co-founder & CEO, Suped
Published 26 Jul 2025
Updated 24 May 2026
10 min read
Summarize with
The best practice is to treat deliverability as a full sending system, not as a list of IPs to check. For SparkPost and Amazon SES, I monitor the domains, the authenticated sending paths, the actual IPs that appear in message headers, bounce and complaint rates, DMARC results, and only the blocklist or blacklist signals that have real delivery impact. If you control an IP, it should have valid reverse DNS. If SparkPost or Amazon SES controls the IP, reverse DNS and most network-level reputation handling sit with the provider, unless you are on a dedicated IP plan that allows configuration or support requests.
- Monitor broadly: Do not check only your datacenter IPs. Check the sending domains, Return-Path domains, DKIM domains, DMARC reports, bounce data, and the provider IPs that actually transmit mail.
- Set rDNS where you can: Every IP you control that appears in Received headers should have a clear PTR name, and the mail server HELO or EHLO should match that naming pattern.
- Escalate provider IP issues: For SparkPost and Amazon SES shared pools, you cannot directly repair their rDNS or IP reputation. You use their dashboards, support process, and your own authentication data.
- Warm dedicated IPs slowly: For 1 to 2 million emails per day, dedicated IPs need predictable volume, clean segmentation, and mailbox-provider-specific monitoring.
Before changing DNS or asking an ESP to adjust anything, send a real message through each mail stream and inspect the headers, authentication results, and routing path with an email tester. That tells you which IPs matter, which domains authenticate, and which part of the chain you actually control.
The control boundary matters
The main mistake I see in mixed SparkPost, Amazon SES, and datacenter setups is treating every IP in the same way. There are at least three control zones. Your own datacenter IPs are yours to configure and defend. Dedicated ESP IPs are assigned to your account, but the ESP still operates the network. Shared ESP IPs are provider-managed, and your control is mostly sender behavior, authentication, list quality, and escalation when metrics break.
|
|
|
|---|---|---|
Own MTA | PTR, HELO, IP pools, routing | IP reputation, DNS, bounces |
SES shared | Domains, auth, content, lists | Domain health, complaints |
SES dedicated | Pools, warmup, segmentation | IP health, warmup, bounces |
SparkPost | Sending domains, streams | Provider metrics, headers |
Use this table to decide what you can change directly.
At this volume, I would also run a periodic domain health check across every customer sending domain and subdomain. Provider IP reputation matters, but a broken customer DKIM record, a missing DMARC policy, or an SPF record that exceeds lookup limits can damage inbox placement before any IP blocklist alert appears.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Reverse DNS for multiple domains
Yes, add reverse DNS on any sending IP you control. The PTR record does not need to match every customer's visible From domain. It should resolve to a stable, non-generic hostname owned by the sending infrastructure, and that hostname should resolve forward to the same IP. I usually prefer names like mta1.mail.yourcompany.com or out1.mail.yourcompany.com over provider-default names that look like raw IP labels.
Reverse DNS and HELO patterntext
IP: 203.0.113.25 PTR: mta1.mail.yourcompany.com A: mta1.mail.yourcompany.com -> 203.0.113.25 HELO: mta1.mail.yourcompany.com
For one IP that sends on behalf of many customer domains, do not try to rotate PTR records per customer. Reverse DNS is attached to the IP, not the message. The customer-specific trust should come through DKIM, SPF, DMARC, the envelope domain, and the visible From domain. The infrastructure identity can be your platform domain, provided it is consistent and professional.
Do not ignore intermediate hops
If your datacenter IPs appear in Received headers before mail enters SparkPost or Amazon SES, those IPs still matter. Missing or generic rDNS on an upstream relay can make filters suspicious, especially when the rest of the authentication path is new or high volume.
For a deeper companion explanation, the core principle is covered in the reverse DNS best-practice page. The short version is simple: make the infrastructure identity stable, forward-confirmed, and consistent with the HELO or EHLO name.
Shared and dedicated IP strategy
Amazon SES dedicated IP console showing pools, warm-up progress, and reputation indicators.
Shared IPs are easier at the start because the provider operates the pool. The tradeoff is that you have limited visibility into exact IP movement and limited control when a receiver reacts badly to pool behavior. Dedicated IPs give you isolation, but that isolation cuts both ways. Good traffic helps you. Bad customer traffic no longer gets diluted by a shared pool.
Shared IPs
- Control: The provider manages IP selection, PTR naming, pool reputation, and most network operations.
- Fit: Useful for irregular volume, smaller streams, and senders that cannot keep each IP warm.
- Risk: You share reputation effects and depend on provider response when a pool has trouble.
- Action: Focus on authentication, complaint rate, bounce quality, and segmentation.
Dedicated IPs
- Control: You can isolate traffic by customer, message type, region, or risk level.
- Fit: Useful for large, stable senders with predictable daily volume.
- Risk: Each IP needs warmup and steady traffic. One bad stream can damage its own pool fast.
- Action: Use separate pools and slow ramp plans, then pause increases when complaints rise.
Amazon SES currently has shared sending, standard dedicated IPs, managed dedicated IPs, and bring-your-own-IP options. AWS explains the tradeoffs in its SES dedicated IPs documentation. For high-volume senders, the most important point is that standard dedicated IPs require manual warmup and stable volume, while managed dedicated IPs automate more of the allocation and warmup behavior.
With SparkPost, the practical step is the same: confirm whether you are on shared or dedicated IPs, ask what reverse DNS naming is available for dedicated IPs, and request a list of account-level sending IPs where the plan allows it. If the IP is not yours and not dedicated to your account, your direct control stops at the provider boundary.
Blocklist and blacklist monitoring
Do not spend your day chasing every blocklist (blacklist) entry. Many public lists have little or no measurable effect on inbox placement. I still monitor major IP and domain listings because they can reveal a real sending problem, but I treat a listing as evidence to investigate, not as the whole diagnosis.
Blocklist monitoring page showing domain and IP checks across blocklists with importance and status
The right workflow is to connect blocklist monitoring with bounce codes, complaint rate, DMARC failures, recipient-domain performance, and sudden volume changes. A blocklist alert without those surrounding metrics is noisy. A blocklist alert at the same time as mailbox-provider deferrals and rising complaints is urgent.
What I would monitor
- Own IPs: Monitor every datacenter IP that appears in outbound headers or hands mail to an ESP.
- Dedicated IPs: Monitor account-assigned SparkPost and Amazon SES IPs when the provider exposes them.
- Domains: Monitor visible From domains, DKIM d= domains, bounce domains, and tracked-link domains.
- Context: Compare listings with bounces, complaints, deferrals, and authentication failures.
Some public blocklists are used more directly than others. Spamhaus is one of the few names I treat as a high-priority signal because major senders and providers respond to it quickly. The Spamhaus and SES article explains how Amazon SES works with Spamhaus to protect its network reputation.
Blocklist checker
Check your domain or IP against 144 blocklists.
Spamhaus
0Spam
Cisco
NoSolicitado
URIBL
abuse.ro
ALPHANET
Anonmails
Ascams
BLOCKEDSERVERS
Calivent Networks
EFnet
JustSpam
Kempt.net
NordSpam
RV-SOFT Technology
Scientific Spam
Spamikaze
SpamRATS
SPFBL
Suomispam
System 5 Hosting
Team Cymru
Validity
www.blocklist.de Fail2Ban-Reporting Service
ZapBL
2stepback.dk
Fayntic Services
ORB UK
technoirc.org
TechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftAuthentication setup for many customers
For multiple customers and domains, the clean setup is to give each customer a clear sending identity. Use customer-owned or customer-delegated subdomains for DKIM, bounce handling, and tracking. Keep your infrastructure rDNS under your own platform domain. Then use DMARC reports to confirm that each customer domain is passing SPF or DKIM through the expected provider.
Customer DNS patterntext
cust.example. TXT "v=spf1 include:amazonses.com -all" s1._domainkey.cust.example. CNAME s1-ses.example. _dmarc.cust.example. TXT "v=DMARC1; p=none; rua=mailto:dmarc@yd.tld"
The exact records vary by provider and customer domain strategy, but the principle stays the same. The visible From domain should have working DKIM, a sane SPF path for the envelope domain, and a DMARC record that reports failures before enforcement. I prefer to stage policy changes gradually, then move high-confidence domains toward quarantine or reject after the data is clean.
Suped's product is useful here because DMARC monitoring turns those reports into source-level views. Instead of reading XML, you can see which customer, ESP, IP, and domain combination is failing, then fix the relevant DNS or provider setup.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Warmup and traffic allocation
At 1 to 2 million emails per day across 6 to 10 IPs, the question is not whether dedicated IPs can handle the volume. They can. The question is whether each IP gets consistent, wanted traffic every day. A dedicated IP that sends a huge spike on Monday and little mail for the rest of the week has a worse reputation pattern than a shared pool with steady usage.
Operational response thresholds
Use thresholds as decision triggers during warmup and when moving traffic across pools.
Normal
Proceed
Authentication is stable and negative signals are within expected levels.
Watch
Hold
Deferrals rise at one major mailbox provider or one customer stream changes sharply.
Problem
Reduce
Complaints, hard bounces, or blocklist alerts move with delivery failures.
Unknown
Verify
The provider changed IPs or routing and headers no longer match your inventory.
AWS has a practical warming guide that is worth reading before moving large workloads onto new SES identities. The advice that matters most is to start with the most engaged recipients, keep volume predictable, separate logical mail streams, and stop increasing volume when negative metrics appear.
For multi-customer platforms, I avoid mixing very different risk levels in the same dedicated pool. Transactional mail, password resets, customer marketing, cold acquisition, and dormant-list reactivation should not all share the same IP pool. If a customer imports a bad list, the blast radius should be limited.
This is also where domain reputation matters as much as IP reputation. Mailbox providers judge sending behavior, authentication, recipient engagement, and complaints across domains and IPs. Moving a bad stream to a fresh IP rarely solves the underlying problem.
A practical runbook
I would run the setup in this order because it separates facts from assumptions. First identify the real outbound path, then fix the DNS you control, then ask the ESP for the items only they can change.
- Inventory: Send test messages for each stream and record every IP, HELO name, DKIM domain, envelope domain, and visible From domain.
- Classify: Mark each IP as owned, SES shared, SES dedicated, SparkPost shared, or SparkPost dedicated.
- Fix: Set rDNS and forward DNS on owned IPs, then match HELO naming to the same infrastructure domain.
- Verify: Confirm SPF, DKIM, and DMARC pass for every customer domain before raising volume.
- Escalate: Ask SparkPost or Amazon SES about dedicated IP PTR options, pool assignment, and raw event exports.
- Operate: Review daily bounce, complaint, deferral, DMARC, and blocklist data by customer and provider.
Where Suped fits
Suped is the best overall DMARC platform for this workflow because it connects DMARC, SPF, DKIM, blocklist checks, deliverability signals, real-time alerts, and issue steps in one place. Hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, and MSP multi-tenancy help teams manage many customer domains without turning DNS changes into a recurring operational bottleneck.
Views from the trenches
Best practices
Check actual message headers before deciding which IPs, domains, and relays need attention.
Use stable rDNS and HELO names for owned infrastructure that touches outbound mail flow.
Treat major blocklist alerts as investigation triggers, then compare them with delivery data.
Ask the ESP about dedicated IP controls instead of assuming shared pool settings are editable.
Common pitfalls
Only checking datacenter IPs misses provider IPs and domains that receivers actually evaluate.
Trying to make one PTR record match every customer domain creates the wrong mental model.
Chasing every blacklist entry wastes time when bounces and complaints show the real issue.
Mixing risky customer mail with trusted transactional mail makes IP pool diagnosis harder.
Expert tips
Keep infrastructure identity separate from customer identity, then verify both in headers.
Use provider dashboards daily, but preserve raw event data for deeper delivery diagnosis.
Segment dedicated pools by traffic type so one customer problem does not affect all mail.
Pause warmup increases when negative signals move together, even if volume targets are unmet.
Expert from Email Geeks says reverse DNS should use clear hostnames that match the machine identity and HELO name, because generic or missing PTR names make filters wary.
2023-09-07 - Email Geeks
Expert from Email Geeks says shared SparkPost or Amazon SES infrastructure is largely the provider's responsibility, so sender teams should rely on provider metrics and escalate only when needed.
2023-09-07 - Email Geeks
The practical answer
For SparkPost and Amazon SES, monitor every domain and IP that is part of the real sending path, not only the IPs sitting in your datacenter. Add reverse DNS to every IP you control, use stable infrastructure hostnames rather than customer-specific PTR names, and ask the ESP what is possible for dedicated IP rDNS and pool assignment.
Use blocklist and blacklist monitoring as one signal among several. The more useful day-to-day signals are authentication pass rates, bounces, complaints, deferrals, engagement, and sudden changes by mailbox provider. Dedicated IPs make sense when volume is high and predictable, but they need careful warmup, segmentation, and fast isolation when one customer stream starts to hurt the pool.
Suped's product gives this work a central operating surface: DMARC monitoring, hosted SPF, hosted DMARC, hosted MTA-STS, SPF flattening, blocklist monitoring, issue detection, real-time alerts, and multi-tenant reporting for agencies and MSPs. The practical value comes from knowing which sender, customer, provider, and DNS record needs action.
