Deauthorize transactional vendor
How to remove Amazon SESfrom your domain's SPF and DKIM
Amazon SES (Simple Email Service) publishes an SPF include, three CNAME records that resolve into DKIM keys (one per rotated key), and an optional MX + SPF pair on a 'MAIL FROM' subdomain. Common to inherit when a serverless app or AWS-native marketing tool is decommissioned.
When you'd want to do this
- Decommissioned the AWS application that sent through SES.
- Switched the project's mail to a dedicated ESP (Postmark, SendGrid, Mailgun).
- Consolidating to one transactional sender across the org.
- AWS account is being shut down or migrated.
What Amazon SES 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:amazonses.com The Amazon SES SPF include. Remove this token from your v=spf1 record. |
| CNAME | <token1>._domainkey.example.com (3 CNAMEs) | <token1>.dkim.amazonses.com SES verifies DKIM via three CNAMEs at unique tokens (e.g. abcdefghijklmnop._domainkey). Identify them by the .dkim.amazonses.com target. Remove all three. |
| MX | feedback.<region>.amazonses.com or a feedback subdomain | 10 feedback-smtp.<region>.amazonses.com Custom MAIL FROM domain (optional setup). Only present if you set up bounce / complaint handling on a subdomain. Remove if you did. |
| TXT | MAIL FROM subdomain (e.g. mail.example.com) | v=spf1 include:amazonses.com -all SPF on the custom MAIL FROM subdomain. Remove the whole record if you remove the MX. |
Step-by-step
- Stop sending through Amazon SES 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 Amazon SES 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. Amazon SESshould 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 Amazon SES include.
What you'll lose
All mail still flowing through Amazon SES (transactional emails, AWS event notifications routed via SES, application password-resets, etc.) fails authentication. Recipients quarantine or reject.
SNS topic subscriptions to SES (bounce / complaint notifications) keep firing for a while as queued mail attempts fail; turn those off in the SNS console once the DNS change has propagated.
Common gotchas
SES is per-region.If you verified the domain in multiple AWS regions (us-east-1, eu-west-1, etc.), each region has its own DKIM CNAME tokens at the SAME three host names. Removing the records breaks SES sending in every region. If you want to keep sending from one region but stop another, deverify the domain in the region you're shutting down via the SES console first.
EasyDKIM rotates keys.Amazon SES rotates DKIM keys automatically. The CNAME tokens you published point at SES-managed targets; when SES rotates, the CNAME target's value changes but the CNAME host stays the same. So you only ever published 3 CNAMEs, regardless of how many rotations have happened.
Just want to rotate keys instead?
If you're keeping Amazon SES 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: Amazon SES 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 →