IP warming during an email platform migration

Map the old and new IP or pool, From address, DKIM and return-path domains, tracking links and message streams with your provider.

• Dedicated IP: its reputation is associated with your traffic. A new IP needs a suitable ramp and enough appropriate ongoing volume.
• Shared IP: the provider manages a pool used by multiple senders. Your own domain, audience quality and sending behaviour still matter.
• Managed dedicated IP: the provider automates parts of warming and routing. Confirm which decisions remain yours.

Domain and IP reputation are different signals. An established domain does not give a new IP its history, and changing platforms does not erase a domain problem. Avoid unnecessary identity changes. [5]

Check real messages from the new platform. Verify SPF and DKIM pass, and DMARC passes through aligned SPF or DKIM. Check TLS and forward/reverse DNS. Keep both authorized systems correctly configured during the overlap. [1]

Test unsubscribe handling, replies, links and reporting. Check the applicable Gmail, Yahoo and Outlook.com requirements; their consumer and bulk-sender scopes differ. [2][4][16]

Correct authentication failures before expanding affected traffic. Volume adjustments cannot repair authentication. [20]

Reconcile subscription status and scope, opt-outs, complaints, invalid-address suppressions, preferences, recent sends and reliable engagement history. Keep subscribed, unsubscribed and cleaned records distinct. Importing an address must not reactivate an excluded person. [10]

Rebuild segments and check sample records against the old platform. Verify timestamps, event definitions and identity matching. If history cannot be imported, preserve the eligibility decision through documented source-system segments or mapped fields. Keep exclusions and recent-send history current across both systems. [10][13]

Start with eligible people showing recent, credible engagement relevant to the message. Define “recent” against your normal cadence, rather than copying a universal 30-, 60- or 90-day rule. Exclude stale or uncertain-permission records from early batches. [9][22]

• B2B: genuine clicks, replies or relevant subscriber activity can inform selection.
• B2C: clicks and purchases add context; a purchase alone does not establish marketing permission.
• Opens can be inflated by Apple Mail Privacy Protection, and scanners can generate clicks. Use bot filtering and additional evidence.

Count unique people as well as messages. Preserve expected frequency, deduplicate across systems and include automated sends. Do not repeatedly contact a small engaged group just to fill a warming target. [4][13]

Review old and new sends together. Adobe recommends increasing the new platform’s share while winding down the old. Gmail evaluates volume at both domain and IP levels. [8][1]

Our recommendation: transfer suitable traffic within the established overall cadence while separately limiting the new infrastructure. Avoid adding a second full programme to unchanged old-platform volume. Include other tools using the same sending domain. [8][1]

Daily totals need not be identical. Plan for legitimate growth and seasonality. Track combined sender-domain volume, each IP or pool, each receiving provider and per-person frequency against healthy historical patterns.

The sending domain identifies your mail. The recipient domain follows the recipient’s @ sign. The receiving provider runs the mailbox or gateway; several business domains may share one. An email app does not reliably identify the mailbox’s host. [1][7][14]

Keep a sensible provider mix across eligible cohorts. Progress at one provider does not establish history elsewhere. Exact proportions need not match, but a new concentration needs a measured introduction. [7]

Name the reviewer, evidence sources and pause conditions. Review at least daily during active warming and before each increase. Allow for reporting delays and the message’s response window. [13][3]

Retain each cohort’s selected and suppressed counts, unique recipients, actual sends, provider breakdown and sender configuration. Reconcile acceptance, delays, bounces, complaints, unsubscribes and meaningful responses. “Sent,” “delivered” and “replied” describe different stages. [19]

Compare the migrated cohort with its relevant old-platform baseline using comparable content, cadence, elapsed time and metric definitions. An engaged group becoming unusually quiet warrants investigation before expansion. It does not prove each quiet recipient has a delivery problem. [14][11][12]

Check in order: Did the right people qualify? Did messages leave? What did receiving servers report? Are links, tracking, replies and conversion events working? Did content or timing change? Server acceptance alone does not prove inbox placement. [14][19]

Read actual failure reasons. Invalid addresses, authentication errors and reputation blocks require different responses. Preserve suppressions; do not retry excluded addresses or remove safeguards to force delivery. [15]

Agree warning thresholds with the provider. No universal daily-volume recipe, bounce percentage or completion date makes every migration safe. [8][15]

Overall averages can hide a provider deteriorating. Review delivery, complaints and meaningful engagement by provider or relevant business-domain group. [14][13]

• Gmail: Postmaster Tools covers personal Gmail traffic. Google recommends user-reported spam below 0.1% and avoiding 0.3% or higher. Delayed or missing data, and very low spam rates, do not establish good inbox placement.
• Yahoo: monitor complaints and available feedback-loop data. Its below-0.3% requirement uses Yahoo’s calculation, which may differ from your platform’s metric.
• Outlook.com: use SNDS and junk-email reporting where you or your provider have IP access. For Microsoft 365 business recipients, follow the non-delivery report and separate external-sender guidance.

Published complaint limits are not a budget to use up. Investigate deterioration early.

Separate marketing and genuinely transactional streams using supported IP or DKIM-domain arrangements. Password resets and order confirmations have different timing needs from newsletters. An automated promotion is still promotional. [4][5][22]

Plan transactional migration separately. Do not manufacture traffic, delay essential messages to fill a ramp, or add promotions to essential notifications. [1][22]

Document an available, authorized fallback before cutover. Carry current suppressions, send history and message identifiers across any routing reversal to prevent duplicates. Use fallback to contain faults, not evade rejections.

Complete cutover when normal eligible traffic, monitoring and response handling are reliable, and an owner can pause and recover the process. Continue monitoring: warmup does not guarantee inbox placement. [5][20]

Amazon SES documents ML-assisted dedicated-IP warming with provider-specific adaptation. Salesforce Einstein Messaging Insights flags unusual engagement for investigation. These existing capabilities do not establish that a cross-platform AI review will accelerate warming or guarantee inbox placement. [23][7][24]

A proposed ExactWork pilot would provide a read-only first pass across authorized old/new aggregate results and the agreed baseline. Deterministic checks handle consent status, suppressions, frequency and duplicates. AI organizes evidence and highlights questions.

• Show the source, period, cohort, provider and denominator.
• Separate confirmed failures from missing data and measurement changes.
• Suggest investigate, hold, reduce or consider the next increase, with uncertainty.
• A person validates the evidence and approves every operational change.

Test alongside human review first. Measure time saved, missed issues, false alarms and evidence accuracy. Missing data is insufficient evidence. Keep recipient data out of unapproved services and never manufacture opens, clicks or replies.