Email Authentication Vendor Offboarding Checklist

Remove an email authentication vendor by enumerating every DNS, selector, and permission artifact it used, then stage and verify deletions in a controlled window. This checklist focuses on concrete records and evidence you must collect before, during, and after removal to avoid leaving stale authorization paths or disrupting legitimate mailflows.

Inventory: enumerate records, owners, and evidence

Start by compiling a single inventory that lists SPF includes, DKIM selectors, DMARC rua/rua URIs, tracking CNAMEs, MX/route changes, delegated subdomains, and any API keys or SMTP credentials the vendor used. Record the DNS owner, change window, and proof of use (example: recent authenticated message headers showing SPF/DKIM alignment). If records are not present in DNS but the vendor had delegated zones or API access, log how that delegation was granted and where to revoke it. Decision boundary: stop when every auth surface (SPF, DKIM, DMARC, MX, delegated DNS, and application-level credentials) has at least one linked evidence item. Evidence limits: header examples are acceptable but avoid relying on a single historical sample to prove ongoing use.

Prioritization and scheduling: choose a safe cutover window

Classify items as high-risk (active MX/Sender IPs, DKIM selectors seen in recent headers, shared domain SPF includes) and low-risk (unused selectors, dormant CNAMEs for tracking that show no recent traffic). Schedule removals during low-volume windows and coordinate with recipients or internal bounce monitoring. Sequence: revoke API/SMTP credentials only after DNS paths are removed or test-originating IPs are blocked, to avoid sudden bounces or retry storms. Evidence limits: you may have provider logs showing no egress for weeks — treat that as directional, not absolute; retain a rollback plan for 48–72 hours after each change.

Making DNS changes: exact edits and verification steps

For SPF, remove vendor includes and then shorten and re-evaluate SPF length and term order to avoid exceeding lookup limits (per RFC 7208) 1. For DKIM, remove selectors published by the vendor and ensure no sending system is still signing with them; if you cannot confirm, replace the DNS TXT with a short-lived deny value and monitor failure logs. For DMARC, remove any rua/fo URIs pointing to vendor addresses and update aggregate/reporting destinations. Verification: use DNS query tools to confirm TTLs, then check live messages for absence of vendor signatures and for any new SPF/DKIM failures. Cite RFC guidance for SPF/DKIM semantics when in doubt 13.

Permissions and administrative access: revoke and document

Revoke the vendor’s access to DNS providers, email services, certificate management, and any hosted dashboards. Record who revoked access and time-stamp each revocation. If the vendor managed delegated DNS zones, re-delegate or import zone files into your account and lock down registrar contacts. Decision boundary: if access cannot be revoked immediately, restrict vendor accounts to read-only and rotate any shared secrets; escalate to legal if contractual access removal is blocked. Note uncertainty about provider-specific APIs — follow provider docs for revocation steps rather than assuming a single method.

Monitoring and post-removal validation

Monitor bounce rates, DMARC aggregate reports, and inbound complaint rates for 7–14 days after removal. Confirm no new messages contain the vendor’s DKIM selector in headers and that SPF no longer passes based on the vendor includes. Use mailbox sampling to verify end-to-end delivery for critical flows and maintain a ticketed incident response path in case of regressions. Evidence limits: DMARC reports can be delayed or aggregated; treat absence of reports as inconclusive for the first 48 hours and use message header sampling as a timely check.

Practical checklist

• Export a signed inventory of SPF includes, DKIM selectors (with sample headers), DMARC rua/rua URIs, tracking CNAMEs, MX changes, and delegated DNS zones.
• Confirm last-seen timestamp for each DKIM selector and vendor sending IP using message headers or provider logs.
• Schedule a maintenance window and notify stakeholders; include rollback owner and TTL-aware timing.
• Remove vendor SPF include(s); validate SPF string length and lookup count per RFC 7208 1.
• Delete DKIM selector DNS TXT records or replace with a short-lived deny value; block vendor-signing keys in sending systems.
• Remove vendor DMARC reporting URIs and update aggregate/reporting addresses; preserve copies of reports for two weeks.
• Revoke vendor access to DNS, email admin consoles, certificate stores, and rotate any shared credentials or API keys.
• Monitor DMARC, SPF, bounce rates, and mailbox headers for 7–14 days; escalate if vendor artifacts still appear.
• Archive evidence of change (DNS queries, screenshots, ticket notes) and mark the inventory as retired with timestamps and owner.

Where RepMail fits

Use this checklist as an operational decision aid in RepMail workflows: attach the inventory and evidence items to the offboarding ticket, use the checklist items as explicit task steps, and record post-change monitoring results as ticketed evidence. The checklist structure helps outbound teams avoid stale auth surfaces and provides clear stop conditions and owners for each change.

Continue with A/B Testing Cold Email With Small Samples for the next step in the workflow.

Related RepMail guides

• Authentication Drift Detection: Compare Intended and Observed Senders
• Authentication-Results Header: Reading Receiver Assertions

Sources