All blogs & guides

PRACTICAL OUTREACH

Email Authentication Change Control Checklist

By TransmitInbox team · Published 2026-11-01

Changing an email platform, agency, CRM, relay, or mailbox provider can break deliverability without changing the copy of a single message. The risk is usually not the migration itself; it is the missing record of which system sends what, which domain authenticates it, and who owns the rollback.

This checklist gives B2B owners, sales teams, and marketers a repeatable way to review email authentication before and after a sending change.

Start with an inventory, not a DNS edit

Before anyone changes SPF, DKIM, DMARC, or routing, list every system that sends mail using your domains. Include systems that are easy to overlook:

• Google Workspace or Microsoft 365 mailboxes
• Cold email platforms and SMTP relays
• CRM and marketing automation tools
• Website forms, billing systems, support desks, and calendar tools
• Recruiting, customer success, and transactional applications
• Security gateways, forwarding services, and internal mail rules

For each sender, record the visible From domain, envelope or return-path domain, DKIM signing domain, sending platform, purpose, owner, and approximate traffic pattern. Do not assume that two tools sending from the same From address authenticate in the same way.

A useful hypothetical example: a sales team sends from alex@example.com, while the platform uses bounce.vendor-mail.com for the envelope sender and signs with vendor-mail.com. That may be operationally normal, but it needs to be checked for alignment and ownership before a platform change.

Define the change boundary

Write down exactly what is changing and what is staying. “We are switching email tools” is too broad to support a safe review. A better change note might say:

• Outbound sales mail moves from Platform A to Platform B.
• Microsoft 365 remains the mailbox provider for replies.
• The visible From domain remains example.com.
• The vendor will use a dedicated subdomain for DKIM and return-path records.
• Marketing and transactional systems are not part of this migration.

This boundary prevents a common failure: editing the root domain’s records to support one new tool and unintentionally removing authorization for several existing senders.

Assign one technical owner, one business owner, and one person responsible for approval. The technical owner can publish DNS records, but the business owner should confirm that the change does not disrupt replies, opt-outs, invoices, or customer notifications.

Check SPF, DKIM, and DMARC as a set

SPF answers whether a sending source is authorized for the envelope sender domain. DKIM checks whether the message carries a valid signature. DMARC evaluates whether an authenticated domain aligns with the domain shown in the visible From address. A passing result in one layer does not prove that the complete sending path is healthy.

For each sending system, verify:

1. The correct SPF authorization exists, without deleting other required providers.
2. The DKIM selector and public key are published at the expected hostname.
3. The message is actually signed after the platform is enabled.
4. The DKIM signing domain or SPF-authenticated domain aligns with the From domain where required.
5. The DMARC record still points to a monitored reporting address.

Google’s sender guidance requires authentication and alignment for relevant mail, while Microsoft’s troubleshooting guidance highlights misalignment, missing DNS records, and message modification by gateways as recurring causes of failure. Use the message headers from a real test message rather than relying only on a vendor’s setup screen.

For protocol background, review the SPF, DKIM and DMARC troubleshooting checklist and the DMARC reports guide.

Test the complete message path

A DNS lookup can show that a record exists. It cannot prove that the live message uses the record correctly. Send controlled messages to test addresses at the major recipient environments relevant to your buyers, then inspect the received headers.

Capture at least:

• SPF, DKIM, and DMARC results
• The envelope-from or return-path domain
• The DKIM d= domain and selector
• The visible From domain
• Any gateway, relay, or forwarding hop
• Whether replies return to the intended mailbox

Test both a normal message and the final production format. A plain-text test can pass while the campaign version fails after link tracking, disclaimers, HTML changes, or a security gateway modifies the body. Microsoft documents that intermediary modification can invalidate DKIM, so the final route matters.

Also test operational controls. Reply to the message, use the unsubscribe process, trigger a bounce, and confirm that the sales or marketing owner sees each event. Authentication is important, but a migration that loses opt-outs or replies is still a failed change.

Use a controlled rollout and rollback

Do not switch every mailbox or campaign at once unless the sending path is already well understood. Start with a small, clearly identified group and define the observation period in advance. During the rollout, monitor authentication results, bounces, deferrals, complaints, replies, and placement signals available from your providers.

Keep the previous configuration documented until the new route has passed its tests. A rollback plan should state:

• Which DNS records can be restored
• Which platform setting disables the new sender
• Who approves the rollback
• How queued messages will be handled
• How unsubscribed contacts are protected during the transition

Avoid making several unrelated DNS changes during the same window. If SPF, DKIM, a gateway, and a campaign workflow all change together, the team may not know which change caused the failure.

Before approval, confirm:

• Every sender using the domain is documented.
• The change boundary excludes unrelated systems.
• SPF was reviewed for preservation, not just addition.
• DKIM signing was confirmed in a real received message.
• DMARC alignment was checked against the visible From domain.
• Replies, bounces, complaints, and opt-outs have named owners.
• Test messages covered the production route and message format.
• A rollback decision, owner, and time window are written down.

For a broader operational framework, compare this process with the email deliverability incident runbook. If your team is changing platforms while campaigns are active, managed deliverability help can document the sending inventory, validate the message path, and coordinate a safer rollout without taking ownership away from your team.