Source review dated 8 November 2026. Provider settings and acceptance exercises below are documentary guidance, not executed account, DNS or message tests.
Identify the platform behind the campaign
An Iterable project is not necessarily one email-sending system. Its setup documentation distinguishes the default Amazon SES shared-IP service from connected SparkPost, Mailgun and SendGrid accounts, plus a separately arranged custom-platform option. A message channel can distribute sends across multiple ESP accounts. Authentication therefore belongs to the domain-and-platform combination actually selected by the campaign, not simply to the Iterable project name. Email setup.
Start with a route inventory. For each important campaign or triggered workflow, record its message type, channel, ESP binding, sending domain, sender address and owner. Include every configured percentage split. A successful test of one platform cannot establish the behavior of another platform that receives part of the traffic. Avoid altering production weights just to obtain a sample unless the change has been approved.
This guide provides the routing decisions and two documented setup branches. It does not supply Mailgun, SendGrid or custom-platform DNS values. Use the current integration instructions and account-generated records for those routes. Treat any migration between providers as a new acceptance exercise, even when the visible From address stays the same.
Use the setup branch that matches the route
For Iterable's default Amazon SES shared pool, the integration guide allows one sending domain and does not support bringing a customer-owned SES account. Configure the applicable domain under Settings > Project Settings using Custom Sending Domain for Shared IPs. The tenant's Settings > DNS Setup page then supplies its domain-specific records. Do not create this default SES domain under Settings > Domains. Iterable SES integration.
For a connected ESP, configure and authenticate the domain with that provider first, then add the platform account in Iterable. Under Settings > Domains, associate the sending domain with the correct ESP and complete Verify Domain. If the same domain uses several ESPs, Iterable documents adding it separately for each account. Settings > DNS Setup is not the DNS recipe for those external platforms. Domain-to-platform configuration.
The SparkPost branch specifically separates sending, bounce and tracking domains. Iterable's guide calls for DKIM on the sending domain, bounce-domain CNAMEs and other integration records, followed by verification. It describes one subaccount per bounce domain and separate Iterable account entries for multiple subaccount/IP-pool combinations. Use the IP pool ID, not its display name. The current multi-subaccount/pool procedure says none of those Iterable platform accounts should be set as the default. Work with the implementation owner to obtain the correct values and pool identifiers. Do not turn that example into a generic Iterable SPF record. SparkPost integration.
Before publication, compare the proposed records with authoritative DNS. Preserve the single SPF policy at each applicable owner and apply RFC 7208 §4.6.4’s limit of ten evaluated DNS-causing terms, including nested evaluations. This is not a ten-packet or ten-visible-include limit. Keep existing DKIM selectors during a controlled transition. A tracking CNAME changes a link destination; it cannot replace a missing DKIM public key or authorize an SMTP envelope. SPF and DKIM.
Test every active domain and platform combination
Original route acceptance worksheet, not completed evidence: create one row per active sending-domain/ESP combination. Record the campaign or trigger, channel, platform account, test time, visible From, Return-Path, trusted SPF result and evaluated domain, every DKIM d= and s= pair, and trusted DMARC result. Use harmless content sent to controlled external recipients through the intended workflow. Keep the original message source securely.
Compare the authenticated domain with the visible From under the applicable alignment mode. An SPF pass for the ESP's own bounce domain is not automatically aligned. A provider signature can validate while a customer-domain signature is missing or broken. DMARC needs at least one aligned passing authentication path; neither a branded tracking link nor a verified sender label is a substitute. DMARC specification.
Also test reply delivery, a representative tracked link and the relevant unsubscribe behavior. These checks do not establish DMARC, but a technically authenticated campaign can still be operationally unusable. Recheck triggered sends separately when their channel or sender differs from a marketing campaign.
Recover at the failing route
If failures affect one platform, stop expanding that route and compare its account binding and generated DNS records with the captured message. Do not replace unrelated domains' records or lower organization-wide DMARC enforcement. Restore the previously approved route only through the normal campaign change process, accounting for sending capacity and subscription behavior.
The retrieved first-party documentation was checked on 8 November 2026. No Iterable tenant, connected ESP, live DNS or received message was tested. Tenant bindings, platform-specific records, message evidence and an SME's confirmation of the chosen integrations remain release gates.