Deauthorize marketing vendor
How to remove Customer.iofrom your domain's SPF and DKIM
Customer.io (behavioural messaging and lifecycle automation) publishes authentication via an SPF include + a pair of DKIM CNAMEs + a tracking subdomain + a return-path / bounce host. Because Customer.io powers both marketing campaigns and high-volume transactional triggers (the same account, same DNS), removing the records deauthorises BOTH paths. Important to know before flipping DNS.
When you'd want to do this
- Migrated to a different lifecycle / behavioural-messaging platform (Braze, Iterable, OneSignal) and never removed the Customer.io DNS.
- Cancelled the Customer.io contract but the DNS records stayed, leaving the apex authorising a vendor with no active account.
- Spun up Customer.io for a single campaign or product launch that never expanded into production.
- Consolidating per-vendor compromise surface as part of an SPF + DKIM hygiene pass.
What Customer.io 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:_spf.customer.io The SPF include. Remove just this token from your existing v=spf1 record; leave the rest of the record alone. Customer.io's EU + US regions share the same include. |
| CNAME | cio1._domainkey.example.com (or k1._domainkey when using legacy DKIM) | dkim.<account-id>.customer.io First Customer.io DKIM selector CNAME. Account-specific target. Delete the whole record. |
| CNAME | cio2._domainkey.example.com | dkim2.<account-id>.customer.io Second DKIM selector CNAME for key rotation. Same account-specific pattern; delete the whole record. |
| CNAME | email.example.com (or track.example.com) | sendgrid.net (via Customer.io) or trk.customeriomail.com Tracking / sending subdomain. Customer.io routes through dedicated SendGrid sub-tenant infrastructure for some accounts; others use the direct customeriomail.com tracking host. Remove every CNAME under a subdomain whose target contains either domain. |
| CNAME | bounce.example.com (or return.example.com) | bounces.customeriomail.com (or sendgrid.net) Return-path / bounce-handling host. Customer.io publishes a custom Return-Path so DMARC alignment passes; the CNAME points at their bounce infrastructure. Leaving it after removing SPF / DKIM keeps bounce traffic for any mail still in flight flowing through Customer.io. |
Step-by-step
- Stop sending through Customer.io 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 Customer.io 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. Customer.ioshould 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 Customer.io include.
What you'll lose
Both Customer.io marketing campaigns AND transactional triggers (welcome flows, password resets, event-driven receipts wired via the Track API) start failing DMARC alignment after the DNS records are gone. Gmail and Yahoo enforce DMARC strictly for bulk senders; those messages will quarantine or reject.
Customer.io's journey builder, segmentation, and event history continue working with prior data. The account itself stays open; re-publish the DNS later if you change your mind. Stop the subscription separately in Customer.io billing if you do not plan to return.
Common gotchas
Transactional path uses the same auth tree. Many Customer.io accounts started with marketing campaigns and grew into transactional traffic (Track API events triggering operational mail). Removing the DNS deauthorises BOTH paths. Search your codebase for track.customer.io, api.customer.io, CIO_SITE_ID, and CUSTOMERIO_API_KEY references before flipping DNS.
EU vs US regional accounts publish the same SPF but use different DKIM CNAME targets (one points at the EU data plane, the other at US). Removing the CNAMEs is the authoritative deauth signal regardless of region; the SPF include is shared.
SendGrid sub-tenancy is common. A non-trivial share of Customer.io accounts have final delivery hand-off to SendGrid behind the scenes. Those accounts may also have a sendgrid.net include or a u<account-id>.wl.sendgrid.net CNAME. Cross-check the SendGrid removal guide so you don't leave a SendGrid-shaped hole behind a cleaned-up Customer.io entry.
Webhook receivers stay live. Removing the DNS only deauthorises outbound mail. Customer.io webhooks (delivery, bounce, open events posted back to your endpoints) keep firing until you delete the webhook destinations in the Customer.io console. Quietly leftover webhook receivers are a stable source of telemetry disclosure - take them down on the same pass.
Just want to rotate keys instead?
If you're keeping Customer.io 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: Customer.io 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 →