Deauthorize transactional vendor
How to remove Mailgunfrom your domain's SPF and DKIM
Mailgun publishes authentication via an SPF include on your apex (or on a dedicated sending subdomain), a per-domain DKIM key (under a custom selector you picked when adding the domain), and a CNAME for the mg tracking subdomain.
When you'd want to do this
- Migrated to a different transactional sender (SendGrid, Postmark, Amazon SES) but never decommissioned Mailgun.
- Trialled Mailgun for a single project that never made it to production.
- Inherited a Mailgun configuration when acquiring a domain or company.
- Cutting per-vendor send authorizations as part of a broader consolidation.
What Mailgun 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 or sending subdomain (e.g. mg.example.com) | include:mailgun.org The SPF include. If you set up Mailgun on a subdomain (recommended), the SPF lives at that subdomain, not your apex. |
| TXT | <selector>._domainkey.<domain> | v=DKIM1; k=rsa; p=... The DKIM public key. Selector is whatever you chose at setup (often k1, mailo, or pic). Remove the whole TXT record. |
| CNAME | email.<domain> (e.g. email.acme.com) | mailgun.org Tracking subdomain CNAME. Used for click + open tracking. Remove if present. |
| MX | mg.<domain> or <sending subdomain> | mxa.mailgun.org / mxb.mailgun.org Only present if you set Mailgun up to receive mail at a subdomain (less common). Remove if Mailgun is no longer your inbound MTA. |
Step-by-step
- Stop sending through Mailgun 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 Mailgun 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. Mailgunshould 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 Mailgun include.
What you'll lose
Anything still hitting smtp.mailgun.org or the Mailgun HTTP API will fail authentication and the recipients will reject it. Open tracking + click tracking stops working immediately.
Webhooks (delivery events, bounces, complaints) keep firing until you disable them in the Mailgun console - even though the underlying mail isn't flowing.
Common gotchas
Subdomain vs apex setups behave differently. Mailgun's recommended setup uses a sending subdomain (e.g. mg.example.com). If you followed that, your apex SPF probably never had include:mailgun.org in the first place - the include lives on the subdomain. Don't edit the apex SPF looking for something that isn't there.
Custom DKIM selector confusion.Mailgun asks you to pick a selector at setup; the standard well-known list (k1, s1, default) won't catch yours if you chose something custom. Search your DNS for any TXT record matching *._domainkey.* that contains mailgun in the value.
Just want to rotate keys instead?
If you're keeping Mailgun 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: Mailgun 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 →