Deauthorize transactional vendor
How to remove Zendeskfrom your domain's SPF and DKIM
Zendesk publishes via two DKIM CNAMEs that point at Zendesk-hosted keys, and a CNAME on a support subdomain (so customers can reach you at support.your-domain.com but the inbox is Zendesk's). Most setups don't add an SPF include, but mature setups with outbound automation do.
When you'd want to do this
- Migrated to a different help-desk platform (Intercom, Freshdesk, Help Scout).
- Account was set up for a discontinued product line.
- Switching to self-hosted support tooling.
- M&A: merging two help desks into one tenant, leaving the other domain free.
What Zendesk 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 |
|---|---|---|
| CNAME | zendesk1._domainkey.example.com | zendesk1.example.com.zendesk-key1.zendesk.com First Zendesk DKIM CNAME. Target includes your Zendesk subdomain in the FQDN. |
| CNAME | zendesk2._domainkey.example.com | zendesk2.example.com.zendesk-key1.zendesk.com Second Zendesk DKIM CNAME. Same pattern, rotated key. |
| CNAME | support.example.com | <account>.zendesk.com Vanity URL for the help center. Removing this breaks your support portal at support.example.com; only remove if you are decommissioning Zendesk entirely. |
| TXT | apex (example.com) | include:_spf.zendesk.com or include:mail.zendesk.com SPF include for outbound automation (triggers, ticket auto-responders). Not always present; check your SPF first. |
Step-by-step
- Stop sending through Zendesk 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 Zendesk 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. Zendeskshould 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 Zendesk include.
What you'll lose
Ticket auto-responses, agent reply emails, and triggered notifications from Zendesk stop authenticating as your domain. They'll either fail-out in Zendesk or send from [email protected] (the fallback Zendesk-owned sender).
Removing the support.* CNAME breaks the support portal URL. Customers visiting support.example.com get a DNS error. Make sure you've migrated the portal content (or set up a redirect) before removing.
Common gotchas
Outbound triggers. Zendesk has automation that sends ticket comments and notifications. Even if agents stopped using Zendesk, automation can keep firing. Turn off triggers + macros in the admin console before removing DNS to avoid a flurry of bouncing ticket replies.
Sandboxes and secondary domains. Zendesk Enterprise tenants often authenticate multiple domains. The DKIM CNAMEs are domain-specific - removing them from one domain doesn't affect the others. If you have a sandbox running on a sister domain, leave its DNS alone.
Just want to rotate keys instead?
If you're keeping Zendesk 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: Zendesk 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 →