Deauthorize marketing vendor
How to remove Iterablefrom your domain's SPF and DKIM
Iterable (cross-channel marketing automation) publishes authentication via an SPF include + a pair of per-tenant DKIM CNAMEs + a click-tracking subdomain + a bounce-handling subdomain. The records are scoped to your Iterable tenant, so the exact selector strings vary between accounts. Removing every entry tied to Iterable infrastructure is the only way to fully deauthorize.
When you'd want to do this
- Migrated to a different marketing-automation platform (Braze, Klaviyo, Customer.io) and never removed the Iterable DNS.
- Cancelled the Iterable contract but the DNS records stayed, leaving the apex authorising a vendor with no active account.
- Trialled Iterable for a cross-channel campaign that never went into production.
- Consolidating per-vendor compromise surface during an SPF flattening + DNS hygiene pass.
What Iterable adds to your DNS
You need to remove every record below for the de-authorization to be complete. Removing only the SPF include: but leaving DKIM keys published is still a partial authorization - the vendor can sign mail as your domain even without SPF alignment if the recipient has a permissive DMARC policy.
| Type | Host | Look for |
|---|---|---|
| TXT | apex (example.com) | include:mail.iterable.com (or include:_spf.iterable.com) The SPF include. Iterable has shipped both spellings depending on account vintage; check your v=spf1 record for either. Remove just the matching token; leave the rest of the record alone. |
| CNAME | iter1._domainkey.example.com (or iter._domainkey) | iter1._domainkey.<tenant>.iterable.com First Iterable DKIM selector CNAME. Tenant-specific target. Delete the whole record. |
| CNAME | iter2._domainkey.example.com | iter2._domainkey.<tenant>.iterable.com Second DKIM selector CNAME for key rotation. Same tenant-specific pattern; delete the whole record. |
| CNAME | links.example.com (or click.example.com) | links.iterable.com (or click.iterable.com) Click-tracking subdomain. Used to rewrite outbound links so Iterable can record click-throughs. Mail still sends without this, but any historical campaign link points here - remove it last so click attribution survives until you cut over. |
| CNAME | bounce.example.com (or em.example.com) | bounce.iterable.com Bounce-handling subdomain. Iterable uses this to track delivery failures via VERP. Leaving the CNAME after removing SPF / DKIM means bounce traffic for any mail still in flight keeps routing back to Iterable. |
Step-by-step
- Stop sending through Iterable first. Check every app, webhook, and automation that hits the vendor's API or SMTP. Pause those before touching DNS - if you flip the DNS first you'll just spend a week chasing bounces from a vendor that's still wired up on your application side.
- Remove the DKIM record(s) at the hosts listed above. Removing DKIM first means any mail still queued from Iterable fails alignment, which is the safer failure mode - the receiver quarantines or rejects rather than silently delivering signed-as-you mail from a vendor you no longer control.
- Remove the SPF include. Open your SPF TXT record at the apex. Look for the exact
include:entry shown above. Remove the entire token (including theinclude:prefix). Leave the rest of the record untouched. Verify the byte-count of the record is now under 450. - Remove the CNAMEs, if any. CNAMEs for tracking domains and return-paths are dead weight once the vendor is gone; some DNS UIs surface them as "orphan records" later if you forget.
- Wait for propagation. 1-4 hours for most providers. The old SPF entry stays cached at receivers for the TTL you published (often 5 min - 1 hour).
Verify it's gone
Run a vendor-consolidation report on your domain. Iterableshould be gone from the vendor list. If it's still showing under SPF or DKIM, the DNS edit either didn't save or hasn't propagated yet - re-check in 30 minutes.
You can also do a manual spot-check with dig TXT example.com (replace with your domain). The output should no longer show the Iterable include.
What you'll lose
Anything still triggered through Iterable - lifecycle campaigns, transactional triggers wired via the Iterable API, journey workflows - starts failing DMARC alignment after the DNS records are gone. Gmail and Yahoo enforce DMARC strictly for bulk senders; those messages will quarantine or reject.
Iterable's journey builder, segmentation, and historical analytics keep functioning with prior data. The platform just stops being able to send mail as your domain. The account itself stays open; re-publish the DNS later if you change your mind. Stop the subscription separately in Iterable's billing settings if you do not plan to come back.
Common gotchas
Iterable can drive transactional traffic too. Many teams started with Iterable for marketing and added transactional triggers later (password reset, receipt, shipping confirmation). Search your codebase for ITERABLE_API_KEY, api.iterable.com, and any /api/email/target calls before flipping DNS. Removing the records kills the transactional path too.
Selector names follow tenant naming. Older Iterable accounts use iter1 / iter2selectors; newer ones may use the account's short slug instead. Any CNAME whose target contains iterable.com should be removed - the selector left-hand side is cosmetic.
SendGrid sub-tenancy. Some Iterable accounts (historically) routed final delivery through SendGrid as a backend. Those accounts may also have a sendgrid.net include or a u<account-id>.wl.sendgrid.net tracking CNAME. Check our SendGrid removal guide for those entries.
Just want to rotate keys instead?
If you're keeping Iterable but want to rotate credentials (a stronger move than just changing the API key - it forces all old DKIM signatures invalid), do it from the vendor side first: Iterable console →
While you're here: audit the rest
The median domain we've analyzed has 6 vendors authorized in DNS and 3 of them can send mail as you. If you just removed one, see who else is on the list.
Run a vendor-consolidation report →