wiredepth
Run a check

Deauthorize marketing vendor

How to remove ConvertKit (Kit)from your domain's SPF and DKIM

ConvertKit (rebranded to Kit in 2024) publishes authentication via an SPF include, a pair of per-account DKIM CNAMEs, and a sending-subdomain CNAME tree used for click + open tracking. Older accounts still publish under convertkit.com; newer ones under kit.com. Both need to come out for the de-authorization to be complete.

When you'd want to do this

  • Migrated to a different marketing-email platform (Mailchimp, HubSpot, Beehiiv, Substack) and never removed the Kit DNS.
  • Bought a domain that came with ConvertKit / Kit pre-configured by the previous owner.
  • Trialled Kit for a launch and the records stayed after the trial expired or the launch wrapped.
  • Consolidating per-vendor compromise surface as part of a vendor-consolidation audit.

What ConvertKit (Kit) 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.

TypeHostLook for
TXTapex (example.com)
include:_spf.kit.com (or legacy include:_spf.convertkit.com)
The SPF include. Kit accounts created after the 2024 rebrand publish _spf.kit.com; pre-rebrand setups still have _spf.convertkit.com. Check your v=spf1 record for BOTH and remove whichever appears. Leave the rest of the record alone.
CNAMEck1._domainkey.example.com (or kit1._domainkey)
dkim1.mcsv.net.<account-id>.kit.com (per-tenant)
First Kit DKIM selector CNAME. The selector name varies by account vintage (ck1 / convertkit1 / kit1) and the target is per-tenant. Delete the whole record.
CNAMEck2._domainkey.example.com (or kit2._domainkey)
dkim2.mcsv.net.<account-id>.kit.com (per-tenant)
Second DKIM selector CNAME for key rotation. Same naming variability as ck1; delete the whole record.
CNAMEmail.example.com (or send.example.com)
mail.kit.com (or mail.convertkit.com)
The sending-subdomain CNAME. Used as the visible From: subdomain in campaigns and as the bounce-handling host. Remove this last; removing it earlier rejects bounces from any campaign still in flight.
CNAMEclick.example.com (or links.example.com)
links.kit.com (or links.convertkit.com)
Optional click-tracking subdomain. Only present if you enabled Kit click tracking with a custom subdomain. Removing it stops new click data from being attributed to historical campaigns.

Step-by-step

  1. Stop sending through ConvertKit (Kit) 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.
  2. Remove the DKIM record(s) at the hosts listed above. Removing DKIM first means any mail still queued from ConvertKit (Kit) 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.
  3. 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.
  4. 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.
  5. 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. ConvertKit (Kit)should 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 ConvertKit (Kit) include.

What you'll lose

Kit newsletter broadcasts and sequence emails (welcome series, drip campaigns, paywall flows) stop sending as your domain. They will either pause inside Kit or send from a Kit-owned domain, which goes to spam on most major receivers.

Kit's analytics + subscriber data continue working for historical campaigns. The Kit account itself stays open; re-publishing the DNS later resumes sending. Cancel the subscription separately in Kit billing if you do not plan to return.

Common gotchas

Selector names vary by account vintage. Pre-rebrand accounts often use convertkit1._domainkey and convertkit2._domainkey or just ck1/ck2. Newer accounts may use kit1/kit2. The authoritative signal is the CNAME target: any CNAME pointing at a host containing kit.com or convertkit.com is theirs.

Legacy convertkit.com records survive the rebrand. If your account was created before 2024, the rebrand to Kit didn't rewrite your DNS. You may have both legacy convertkit.com records AND newer kit.com records side by side. Remove every entry that resolves to either domain.

Find every form + landing page first. Kit landing pages and embedded signup forms call Kit's API from your domain. Removing the DNS does not disable those - they will keep collecting subscribers into a Kit account whose mail you can no longer send. Either replace the embeds with the new platform's widgets or take them down before flipping DNS.

Just want to rotate keys instead?

If you're keeping ConvertKit (Kit) 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: ConvertKit (Kit) 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 →

Other vendor de-authorization guides