Five deliverability checks before swapping a client sending domain
Swapping a client's sending domain feels like a clean break. Mailbox providers treat it like a new sender audition. Agencies that cut over on a Friday and "monitor opens on Monday" usually spend the next month explaining why Client Co's pipeline went quiet.
Domain changes show up when a client rebrands, exits a burned subdomain, moves ESP or mailbox path, or finally separates marketing and outbound. The technical work is not exotic. The failure mode is skipping preflight while send windows keep running.
GTM already treats send windows, domain limits, and the compliance gate as reputation protection. A domain swap is the moment those controls either save you or expose a rushed migration.
Check 1: Inventory every current sending identity
Before DNS edits, list what actually sends today.
- Visible From domains
- Bounce / Return-Path domains
- DKIM selectors and signing domains
- Tracking domains
- Linked mailbox providers or relays
- Which streams are outbound, transactional, or marketing
DMARCPal's migration playbooks start here for a reason. You cannot authorize a new path if you do not know the old one. Agencies should do this per client workspace. Do not assume Client A's subdomain pattern matches Client B's.
If the inventory is incomplete, pause new volume on that client before you touch DNS.
Check 2: Publish and verify SPF, DKIM, and DMARC on the new path first
Do not send production outbound from the new domain until authentication passes on test mail.
- Add the new path to SPF while keeping the old path authorized during overlap
- Stay inside SPF's practical 10-lookup limit when both paths are live
- Publish DKIM keys for the new signer and confirm aligned signatures
- Confirm DMARC passes with alignment on the From domain
- Verify PTR, forward DNS, EHLO, and TLS if IPs change
SenderReputation.org calls authentication realignment the highest-risk technical step in ESP migrations. That holds for outbound domain swaps too. If the current DMARC policy is already reject, do not weaken it out of panic. Make both paths pass instead.
Seed-test from the exact tools that will send. A green check in a generic DNS UI is not the same as a production message with your headers.
Check 3: Move suppressions, unsubscribes, and complaint handling before cutover
A new domain with an old suppression gap is how you earn spam complaints on day one.
Confirm that hard bounces, unsubscribes, spam complaints, and manual do-not-contacts for that client are present in the outbound workspace that will send. CAN-SPAM still allows up to ten business days to honor commercial opt-outs. Gmail and Yahoo bulk-sender expectations are tighter in practice. Best practice for outbound is immediate honor.
If your compliance gate requires a verdict and an unsubscribe URL before send, keep that gate on during the migration. A domain swap is not a reason to bypass it.
Check 4: Warm with engaged, in-ICP traffic, not the full leftover list
New domains and new IPs need a reputation story. That story is engagement.
Start with recently engaged, clearly in-ICP contacts for that client. Keep volume inside the client's send windows and domain limits. Expand gradually over weeks if placement holds. DeliverabilityChecker and similar rebrand guides describe multi-week warmup and parallel sending for a reason. Dumping the entire old queue onto a cold domain teaches mailbox providers the wrong lesson.
Watch hard bounces, complaint signals, and placement. If bounce rate spikes, stop and fix list quality before you "catch up" volume. Pause rules that already protect client reputation still apply.
Check 5: Run overlap, then retire the old path on purpose
Keep the old domain authorized until mail in flight is done and delayed replies stop arriving. Move a small observable slice first. Only then shift the rest.
After cutover:
- Monitor Google Postmaster Tools and Microsoft SNDS where available
- Read DMARC aggregate reports for both domains during overlap
- Confirm tracking links, unsubscribe headers, and reply routing still resolve to the right client workspace
- Remove old SPF mechanisms and unused DKIM selectors only when the old path is idle
DataInnovation's ESP migration checklist keeps repeating the same operational truth: the first 48 to 72 hours after a sending change is when complaint and authentication mistakes become expensive. Put a human on the dashboards.
Agency-specific reminder
Never swap domains for multiple clients in the same window with the same on-call owner. Isolated workspaces help contain blast radius. Your calendar should too.
A clean domain swap is boring. Boring is the goal.
Sources
- https://dmarcpal.com/learn/email-provider-migration-playbook-esp-mailbox-platform-authentication-reputation
- https://dmarcpal.com/learn/email-server-migration-checklist-new-mta-spf-dkim-dmarc
- https://senderreputation.org/blog/esp-migration-sender-reputation-playbook
- https://deliverabilitychecker.com/resources/email-deliverability-after-rebrand
- https://datainnovation.io/en/blog/email-deliverability-drop-after-esp-migration-diagnosis-checklist-from-200-audits/
- /workspace/trygtm/knowledge/product.md
Need outbound with send windows, domain limits, and a compliance gate that stays on during migrations? Join the waitlist at https://trygtm.com/waitlist.