Deauthorize transactional vendor
How to remove SendGridfrom your domain's SPF and DKIM
SendGrid (now Twilio SendGrid) publishes authentication via three DNS records: an SPF include, a pair of CNAMEs that resolve into DKIM keys, and a tracking subdomain. Removing all three takes ~10 minutes in your DNS provider's console.
When you'd want to do this
- Switched to a different transactional sender (Postmark, Mailgun, Amazon SES) but never removed the old SendGrid records.
- Account was set up for a marketing experiment that never went into production.
- Acquired a domain that came with SendGrid configured by the previous owner.
- Consolidating to one transactional sender to reduce per-vendor compromise surface.
What SendGrid 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:sendgrid.net The SPF include. Remove just this token from your existing v=spf1 record; leave the rest of the record alone. |
| CNAME | s1._domainkey.example.com | s1.domainkey.u<account-id>.wl.sendgrid.net First of two DKIM selector CNAMEs. The account-id varies; delete the whole record. |
| CNAME | s2._domainkey.example.com | s2.domainkey.u<account-id>.wl.sendgrid.net Second DKIM selector CNAME. Same deal as s1. |
| CNAME | em<digits>.example.com (e.g. em123.acme.com) | u<account-id>.wl.sendgrid.net Tracking subdomain. Used for link click + open tracking. Mail still works without this, but you should remove it - it is dead infrastructure. |
| CNAME | url<digits>.example.com | sendgrid.net Optional - older SendGrid setups also publish a url-tracking CNAME. Check your DNS for any url* subdomain pointing at SendGrid. |
Step-by-step
- Stop sending through SendGrid 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 SendGrid 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. SendGridshould 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 SendGrid include.
What you'll lose
Anything still wired up to send through SendGrid will start failing SPF + DKIM alignment. Recipients on Gmail / Yahoo (which enforce DMARC strictly for bulk senders) will quarantine or reject those messages.
The SendGrid account itself stays open - you can re-add the DNS records later if you change your mind. Stop the subscription separately in your SendGrid billing settings.
Common gotchas
Find every app sending through SendGrid first. Common ones: your password-reset flow, transactional order emails, the marketing platform that forwards through SendGrid SMTP, the analytics tool that emails scheduled reports. Search your codebase for smtp.sendgrid.net and any SENDGRID_API_KEY references before flipping DNS.
SendGrid's "reverse DNS" record is separate. If you set up dedicated IPs, you may have an additional record under O1.ptr<digits>. That can stay - it's an A record that SendGrid will stop pointing your way once your contract ends.
Just want to rotate keys instead?
If you're keeping SendGrid 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: SendGrid 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 →