Deliverability
Part of Email platform selection and migration
Warming a new sending setup after migration
Plan a gradual sending ramp after an email-platform migration, using route checks and receiver feedback to guide each increase.
Warm a migrated sending setup by checking what changed, sending first to eligible people who expect the mail and increasing volume in response to receiver feedback.
A new platform does not automatically erase a domain's sending history, but it may change the underlying route. Identify that change before choosing a ramp.
Establish the starting position
Record the old and new visible From domain, authenticated domain, sending service and any dedicated or shared route identified by the providers. Include campaigns and automations.
Note usual frequency and volume, the recipient-domain mix and known bounce or complaint issues. If the programme has been dormant, review address age and permission separately; a ramp cannot establish consent.
Check each new route with a controlled received message. Inspect its From address and authentication results against the provider's setup instructions. Resolve confirmed authentication faults before expanding, and treat authentication as one factor among several; meeting it does not guarantee inbox placement.
Choose the first audience
Start with a manageable group eligible for the planned content and likely to expect it. A recent signup or deliberate preference can help identify that group.
A recorded open alone is weak evidence of human interest, and a new platform's “subscribed” label does not establish permission. Apply current opt-outs before selection.
Keep the message within the promise those people received. Use a sustainable rhythm rather than a burst intended to manufacture activity.
A gradual increase in volume, with consistent rates and no sudden spikes, is a common approach; there is no universal daily quota. After significant changes to sending infrastructure or headers, treat the affected traffic separately.
Review each increase
Set a review point after each planned increase. Keep attempted sends and available receiver responses by recipient domain, along with bounces, deferrals, complaints and the audience used.
If Postmaster Tools is available, use it for the personal Gmail portion of mail.
| Observation | Next step |
|---|---|
| Authentication fault or policy rejection on the new route | Hold that route, correct the confirmed issue and check again. |
| More deferrals or bounces as volume rises | Slow the affected traffic and inspect receiver replies. |
| Stable responses for the current eligible group | Consider the next planned increase with the same checks. |
| Little receiver data | Record the visibility gap rather than treating an empty dashboard as success. |
These are decisions to make from the organisation's own results, not a guaranteed schedule. A platform's reported delivery does not show that each message reached an inbox. If trouble is concentrated at one recipient service, investigate that pattern before changing every route.
Keep the ramp tied to the migration
Confirm that new signups, opt-outs and automations use the intended platform during the ramp. Avoid parallel campaigns from old and new systems to the same people. Record each volume change, audience definition, message type, configuration change and receiver response.
Move to routine sending when the required routes work, exclusions remain effective and the team has enough feedback from its own recipient mix to manage the next normal send. There is no fixed number of warm-up days. Continue watching later imports and infrastructure changes that could alter the conditions checked during the first sends.
