What are the best practices for email deliverability when using SparkPost and Amazon SES, including reverse DNS, blacklist monitoring, and handling dedicated IPs?
Updated on 3 Oct 2026: We clarified how to judge inbox placement, verify sending IPs, and configure aligned authentication across SparkPost and Amazon SES.
Treat deliverability as a full sending system. For SparkPost and Amazon SES, monitor the domains, authenticated sending paths, actual connecting IPs, bounce and complaint rates, DMARC results, and blocklist or blacklist signals with real delivery impact. Every internet-facing sending IP under your control should have valid reverse DNS. When the provider controls the IP, reverse DNS and network operations sit with the provider. Dedicated IP customers still own their sending reputation and usually handle reputation blocklist investigations.
- Monitor broadly. Check sending domains, Return-Path domains, DKIM domains, DMARC reports, bounce data, and the provider IPs that actually connect to recipient servers.
- Set rDNS where you can. Each owned IP that connects directly to recipient mail servers needs a PTR hostname that resolves back to the IP. Use a stable HELO or EHLO name that resolves in DNS.
- Escalate provider IP issues. For SparkPost and Amazon SES shared pools, use provider metrics and support processes when an IP-level problem affects delivery.
- Control dedicated IP warmup. For 1 to 2 million emails per day, use predictable volume and clean segmentation. Follow the provider warmup state before shifting full traffic to a new IP.
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 identifies which IPs matter, which domains authenticate, and which part of the chain you control.
Delivery acceptance and inbox placement
A SparkPost or Amazon SES delivered event means the recipient mail server accepted the message. It does not tell you whether the message reached the inbox, another tab, or spam. Keep delivery acceptance and inbox placement separate when diagnosing a decline.
- Use bounce and deferral codes to find messages rejected or delayed before acceptance.
- Use complaints, recipient engagement, and mailbox-provider reputation signals to assess how accepted mail is treated. Compare these by customer, domain, and mail stream.
- Inspect a real message in the affected mailbox and check its authentication results, placement, and any change in sending volume. Avoid treating an accepted message as proof of inbox placement.
Who controls each sending IP
A common mistake in mixed SparkPost, Amazon SES, and datacenter setups is treating every IP in the same way. 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, so your control centers on 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, dedicated pools | Provider events, headers, suppressions |
Use this table to decide what you can change directly.
At this volume, run a periodic domain health check across every customer sending domain and subdomain. Provider IP reputation matters, but broken DKIM or SPF can damage inbox placement before any IP blocklist alert appears. DMARC reporting should confirm which sending paths remain authorized.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Reverse DNS for multiple domains
Add reverse DNS on every internet-facing sending IP you control. The PTR record does not need to match every customer's visible From domain. It should resolve to a stable hostname owned by the sending infrastructure, and that hostname should resolve forward to the same IP. For owned IPs, names such as mta1.mail.yourcompany.com or out1.mail.yourcompany.com make operations clearer. A provider-assigned hostname with numbers is also valid when its DNS resolves correctly.
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 rotate PTR records per customer. Reverse DNS is attached to the IP, not the message. Customer-specific trust should come through DKIM and DMARC, with SPF authenticating the envelope domain. The infrastructure identity can use your platform domain when it remains stable and consistent.
Check the connecting IP
The recipient typically checks reverse DNS for the IP that connects to its mail server. Inspect Received headers to trace earlier relays, but a private or intermediate hop does not need a public PTR merely because it appears in a header. If your own relay delivers directly to recipient servers, verify its PTR, forward DNS, and HELO or EHLO identity.
The core principle is covered in the reverse DNS best-practice page. Keep 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 limited visibility into exact IP movement and limited control when a receiver reacts badly to pool behavior. Dedicated IPs give you reputation isolation, but poor customer traffic is no longer diluted by a shared pool.
Shared IPs
- The provider manages IP selection, PTR naming, pool reputation, and most network operations.
- Shared pools suit irregular volume, smaller streams, and senders that cannot keep each IP warm.
- You share reputation effects and depend on provider response when a pool has trouble.
- Focus on authentication, complaint rate, bounce quality, and segmentation.
Dedicated IPs
- You can isolate traffic by customer, message type, region, or risk level.
- Dedicated pools suit large, stable senders with predictable daily volume.
- Each IP needs steady wanted traffic. One bad stream can damage its pool quickly.
- Use separate pools and honor the warmup schedule, then pause increases when complaints rise.
Amazon SES offers shared sending, standard dedicated IPs, and managed dedicated IPs. AWS explains the tradeoffs in its SES dedicated IPs documentation. Standard IPs are static, and automatic warmup is enabled by default on a 45-day time-based schedule unless you disable it. Managed pools adapt warmup and capacity for each recipient provider based on actual traffic. Their IP count can change as demand changes.
With SparkPost, confirm whether your traffic uses shared or dedicated IPs, which pool each stream selects, and what PTR naming is available. When automated dedicated IP warmup is enabled, traffic above the new IP's warmup limit uses the configured overflow pool. Shared infrastructure is an overflow option only when the account has access to it. Keep routing deliberate until warmup is complete.
Do not over-allocate IPs
Size the pool by traffic that each recipient provider receives, not only by total daily volume. Adding too many IPs can leave each one with little consistent traffic at a major mailbox provider. Add IPs for isolation or capacity only when each one can maintain a stable pattern.
Blocklist and blacklist monitoring
Do not spend the day chasing every blocklist (blacklist) entry. Many public lists have little or no measurable effect on inbox placement. Monitor major IP and domain listings because they can reveal a real sending problem, but treat a listing as evidence to investigate rather than the whole diagnosis.
Blocklist monitoring page showing domain and IP checks across blocklists with importance and status
Connect blocklist monitoring with bounce codes, complaint rate, DMARC failures, recipient-domain performance, and sudden volume changes. A blocklist alert without surrounding delivery metrics is noisy. A listing that coincides with provider deferrals or rising complaints needs immediate investigation.
What to monitor
- Monitor each owned IP that connects directly to recipient mail servers. Track upstream relays separately for routing and DNS troubleshooting.
- Monitor account-assigned SparkPost and Amazon SES dedicated IPs when the provider exposes them.
- Monitor visible From domains, DKIM d= domains, bounce domains, and tracked-link domains.
- Compare listings with bounces, complaints, deferrals, and authentication failures.
Treat a Spamhaus listing as a high-priority signal and verify whether delivery failures occurred at the same time. The Spamhaus and SES article explains how Amazon SES works with Spamhaus to protect its network reputation. For dedicated IPs, correct the sending cause first, then follow the provider's process for any delisting request.
Blocklist checker
Check your domain or IP against 144 blocklists.
Authentication setup for many customers
For multiple customers and domains, give each customer a clear sending identity. Use customer-owned or customer-delegated subdomains for DKIM, bounce handling, and tracking. Keep infrastructure rDNS under your platform domain. Use DMARC reports to confirm that each customer domain passes aligned SPF or aligned DKIM through the expected provider.
Illustrative Amazon SES customer DNS patterntext
Visible From: cust.example DKIM d=: cust.example (use SES-assigned CNAME records) MAIL FROM: bounce.cust.example bounce.cust.example. MX 10 feedback-smtp.<region>.amazonses.com bounce.cust.example. TXT "v=spf1 include:amazonses.com ~all" _dmarc.cust.example. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
Use the exact DNS values and AWS Region supplied for each SES identity. The custom MAIL FROM subdomain needs both the MX and SPF records. SES can fall back to an amazonses.com MAIL FROM domain if the custom MX fails, depending on the identity setting; SPF then passes for SES but does not match the customer From domain for DMARC. Aligned DKIM can still make DMARC pass. SparkPost uses its own assigned DNS values, so do not copy the SES example for that path.
The visible From domain should have working DKIM and a DMARC record. DMARC passes when either SPF or DKIM passes and aligns with the From domain. Start DMARC reporting at p=none, then move high-confidence domains toward quarantine or reject after legitimate sources authenticate consistently.
Suped's product supports this workflow because DMARC monitoring turns aggregate reports into source-level views. Teams can identify which customer, provider, IP, and domain combination is failing, then correct the relevant DNS or sending configuration.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Bounce and complaint handling
Authentication and clean rDNS do not compensate for repeatedly mailing invalid addresses or people who complained. Build one feedback pipeline across SparkPost and Amazon SES so every customer stream applies the same suppression rules, even when providers expose events differently.
- Capture events. Publish Amazon SES delivery events through configuration sets and ingest SparkPost event data through webhooks or exports. Apply the SES configuration set to each relevant send.
- Suppress permanent failures. Stop sending to hard bounces and complaint recipients immediately. Keep unsubscribe consent in your own system as the durable record.
- Classify temporary failures. Do not treat a soft bounce or deferral like an invalid address. Track repeated failures, retry within provider policy, and suppress when the result becomes permanent.
- Isolate the cause. Group complaints and bounces by customer, mail stream, recipient provider, and IP pool so one tenant cannot hide inside an account-wide average.
- Stop bad traffic. Pause the affected customer or stream when negative signals rise. Do not wait for an account pause, blocklist listing, or broad inbox placement drop.
Provider suppression lists are useful safeguards, but they should not be the only source of truth for a multi-provider platform. Mirror hard bounces, complaints, and unsubscribes into an application-level suppression and consent store. When traffic moves between SparkPost and Amazon SES, the recipient must stay suppressed. For marketing mail, provide a visible unsubscribe link and one-click unsubscribe where recipient-provider rules require it.
Warmup and traffic allocation
At 1 to 2 million emails per day, dedicated IP capacity is rarely the limiting factor. Each IP needs consistent wanted traffic at each recipient provider. A dedicated IP that spikes on Monday and sends little mail for the rest of the week has a weaker reputation pattern than a shared pool with steady usage. New domains also need a gradual, consistent ramp even when they use warmed shared IPs.
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 for moving large workloads onto new SES identities. Start with engaged recipients and keep volume predictable. Separate logical mail streams, then stop increasing volume when negative metrics rise.
For multi-customer platforms, keep different risk levels out of the same dedicated pool. Transactional messages and password resets should not share a pool with customer marketing or dormant-list reactivation. If a customer imports a bad list, the impact should be limited.
This is where domain reputation matters as much as IP reputation. Mailbox providers judge sending behavior and authentication across domains and IPs. Recipient complaints add another direct reputation signal. Moving a bad stream to a fresh IP rarely solves the underlying problem.
Deliverability setup checklist
Run the setup in this order to separate facts from assumptions. Identify the real outbound path, fix the DNS you control, and ask the ESP for items only it can change. Put feedback processing in place before increasing volume.
- Inventory. Send test messages for each stream and record the connecting IP, upstream relays, HELO name, DKIM domain, envelope domain, and visible From domain.
- Classify. Mark each connecting IP as owned, SES shared, SES dedicated, SparkPost shared, or SparkPost dedicated.
- Fix. Set rDNS and forward DNS on owned IPs that deliver directly to recipient servers, then use a stable HELO identity.
- Verify. Confirm DMARC passes through aligned SPF or DKIM for every customer domain before raising volume.
- Connect feedback. Ingest delivery events and synchronize hard bounces, complaints, and unsubscribes into a central suppression store.
- Escalate. Ask SparkPost or Amazon SES about dedicated IP PTR options, pool assignment, warmup state, and event exports.
- Operate. Review daily bounce, complaint, deferral, DMARC, and blocklist data by customer and provider.
Where Suped fits
Suped's product can centralize DMARC results, blocklist checks, issue alerts, and multi-tenant reporting for this workflow. Hosted DMARC and SPF management help teams apply approved DNS changes across customer domains. Use provider event data alongside Suped so bounce and complaint decisions still come from the sending platforms.
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 view
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 view
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
