Deauthorize transactional vendor
How to remove Postmarkfrom your domain's SPF and DKIM
Postmark (transactional sender owned by ActiveCampaign) publishes via an SPF include, a single DKIM TXT record under a date-style selector, and a return-path CNAME. The selector convention makes Postmark recognizable by inspection.
When you'd want to do this
- Switched transactional sender (back to SendGrid, over to Mailgun, in-house via Amazon SES).
- Postmark was set up for a side-project app that has been retired.
- Server-level account closure (every Postmark server is its own send identity - sometimes you keep the account but drop one server).
- Cutting per-vendor send authorizations to shrink the spoof surface.
What Postmark 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:spf.mtasv.net The Postmark SPF include. The mtasv.net domain dates from before ActiveCampaign bought Postmark - newer setups may use postmarkapp.com. |
| TXT | <date>._domainkey.example.com (e.g. 20210112._domainkey) | v=DKIM1; k=rsa; p=... Postmark uses date-style selectors. Look for a TXT under any 8-digit numeric selector at _domainkey - it'll be Postmark's. |
| CNAME | pm-bounces.example.com | pm.mtasv.net Return-path / bounce-handling CNAME. Required for full Postmark setup. Remove during de-authorization. |
Step-by-step
- Stop sending through Postmark 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 Postmark 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. Postmarkshould 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 Postmark include.
What you'll lose
Mail still hitting Postmark's API fails authentication at the receiver. Postmark's bounce-webhook handling keeps firing for a few hours of queued retries.
Postmark sends transactional templates inline - any campaigns / message streams set up there stop being able to send as your domain.
Common gotchas
Multiple Postmark servers = multiple keys. Postmark separates "Servers" (each is a logical send identity). If you ran more than one server on the same domain, you may have more than one DKIM selector published. Look for ALL TXT records at *._domainkey. matching a date-style selector.
spf.mtasv.net vs postmarkapp.com. Older accounts publish the mtasv.net include (legacy infrastructure). Newer ones may publish postmarkapp.com directly. Either one is Postmark - check the actual include and remove whichever you have.
Just want to rotate keys instead?
If you're keeping Postmark 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: Postmark 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 →