Docs · Vendor de-authorization · Cheatsheet
Vendor de-authorization cheatsheet
One-page reference for the most common email vendors a domain accumulates. SPF include + DKIM selectors + tracking CNAMEs + the single most common gotcha that bites cutovers. For the full step-by-step playbook, click through to the per-vendor page.
Run postvale vendors example.com first to see which of these are actually on your domain right now.
| Vendor | SPF include | DKIM selectors | Tracking CNAMEs | Common gotcha |
|---|---|---|---|---|
| SendGrid | include:sendgrid.net | s1, s2 (or per-tenant) | em*.<your-domain>, url*.<your-domain> | Tracking CNAMEs go to sendgrid.net. Removing SPF + DKIM but leaving the tracking CNAME means new mail still gets click-redirected through SendGrid's domain and triggers vendor-reputation alerts. |
| Mailgun | include:mailgun.org | mx, k1, smtp (region-specific) | email.<your-domain> -> mailgun.org | EU vs US regions use different SPF + DKIM. Removing only us-east leaves eu-west still authorised. |
| Mailchimp (+ Mandrill) | include:servers.mcsv.net | k1, k2, k3 | click.<your-domain> | Mandrill (transactional) has a separate include + DKIM. Removing Mailchimp marketing only does not deauthorise Mandrill. |
| HubSpot | include:hubspotemail.net | hs1-<id>, hs2-<id> | links.<your-domain> | HubSpot DKIM selectors are tenant-scoped (hs1-12345-acmecom). Easy to miss if multiple HubSpot portals existed historically; check every selector starting with hs1-/hs2-. |
| Klaviyo | include:_spf.klaviyo.com | klaviyo<id> | bounce.<your-domain> | Klaviyo points the bounce subdomain at their MX. Leaving the CNAME after removing SPF/DKIM means bounce traffic for your old mail keeps flowing to Klaviyo. |
| Amazon SES | include:amazonses.com (or region variant) | three SES-generated CNAMEs (not TXT) | (none by default) | SES DKIM is published as CNAMEs that point to SES-managed records, not TXTs you control. Removing the CNAMEs is the only way to revoke - the actual key material lives on SES. |
| Postmark | include:spf.mtasv.net | 20<sequence>pm | pm-bounces.<your-domain> | Postmark rotates DKIM selectors. The published selector may differ from one you saw in setup - look for any 20*pm TXT record. |
| Marketo | include:mktomail.com | m1-<munchkin> | go.<your-domain> -> mktoresp.com | The tracking CNAME goes through Marketo even when the SPF is removed. New mail gets click-stripped if the CNAME stays. |
| Zendesk | include:mail.zendesk.com | zendesk1, zendesk2 | support.<your-domain> (CNAME to zendesk) | Switching off the SPF/DKIM kills outbound but the inbound CNAME for the support portal usually stays - that is a separate decision. |
| Salesforce (Marketing Cloud + Sales Cloud) | include:_spf.salesforce.com | tenant-named, often <orgname>1024 | cust-<n>.<region>.exacttarget.com | Marketing Cloud (ExactTarget) and Sales Cloud have separate SPF + DKIM trees. Removing one doesn't deauthorise the other. |
| Constant Contact | include:spf.constantcontact.com | cc-<token>, cc-<token>2 | click.<your-domain> -> pages.ctctcdn.com | Bounce subdomain (bounce.<your-domain> or return.<your-domain>) routes delivery-failure mail back through Constant Contact even after SPF / DKIM are gone. Check for any CNAME pointing at ctctcdn.com or constantcontact.com and remove those too. |
| Brevo (formerly Sendinblue) | include:spf.brevo.com (+ legacy spf.sendinblue.com) | mail._domainkey (TXT, not CNAME) | r.<your-domain> -> tracking.brevo.com | Brevo Transactional Email uses the same auth tree as Brevo Marketing. Removing the DNS kills password-reset / receipt / order-confirmation mail going through Brevo SMTP too. Search the codebase for smtp-relay.brevo.com + BREVO_API_KEY / SENDINBLUE_API_KEY before flipping DNS. |
| ConvertKit (Kit) | include:_spf.kit.com (+ legacy include:_spf.convertkit.com) | ck1, ck2 (or convertkit1 / kit1, vintage-dependent) | mail.<your-domain> -> mail.kit.com | Pre-rebrand accounts still publish convertkit.com records; the 2024 rebrand to Kit didn't rewrite anyone's DNS. Check for BOTH kit.com and convertkit.com targets. Also remember embedded signup forms keep collecting subscribers into the Kit account even after DNS is removed. |
| Iterable | include:mail.iterable.com (or include:_spf.iterable.com) | iter1, iter2 (tenant-scoped) | links.<your-domain> -> links.iterable.com | Iterable often drives transactional triggers as well as marketing campaigns from the same account. Search for ITERABLE_API_KEY and api.iterable.com / /api/email/target calls before flipping DNS; removing the records kills the transactional path too. Some accounts also hand off final delivery to SendGrid - re-check the sendgrid.net include. |
| Customer.io | include:_spf.customer.io | cio1, cio2 (account-scoped) | email.<your-domain> -> trk.customeriomail.com or sendgrid.net | Customer.io marketing + transactional share the same auth tree, and many accounts hand off final delivery to SendGrid. Removing the DNS deauthorises BOTH paths; also re-check for any sendgrid.net include. Webhook receivers stay live until you delete them in the Customer.io console - quietly leftover webhooks are a stable telemetry-disclosure surface. |
Cutover sequence we recommend
- Inventory: run
postvale vendors <domain>to enumerate every vendor currently authorised on your apex. - Confirm intent: talk to whoever owned the mail-sender relationship. Removing SPF + DKIM before the last legitimate batch sends will bounce mail customers were expecting.
- Remove DKIM selectors first. Mail already in flight can still be signed; new outbound starts failing DKIM at the recipient. Less disruptive than killing SPF first.
- Then SPF include. Bounce rate spikes within minutes for new outbound through the vendor.
- Tracking CNAMEs last. Old links in archived emails stop working when you remove the tracking CNAME; some teams choose to leave it for 90 days to keep historical click-throughs working.
- Verify: re-run
postvale vendors <domain>. The removed vendor should drop off; SPF include count should decrease by one.
Selectors + tracking subdomains vary by tenant - the values above are the most common patterns. Authoritative answer for your domain comes from your DNS, which the per-vendor guides walk through step-by-step.