ASI uses a structured ten-week warm-up because capacity is not the same thing as sender trust.
A new private sending environment may be capable of serious daily volume on day one. Mailbox providers have not yet seen enough stable behaviour to trust it with that volume.
Advanced Subscriber Intelligence builds reputation gradually across the dedicated domain and IP while monitoring list quality, consent, complaints, bounces, provider pressure, content evidence, queue behaviour, engagement quality, and safety status.
Ten weeks is the operating framework. Progression is earned by evidence. A sender does not automatically advance because Monday arrived.
Evidence-Led Progression
Provider-Aware Pacing
Stability Before Scale
Warm-up is not a countdown to full volume.
It is a controlled proving period. ASI increases, holds, repeats, slows, or pauses the operating step according to the evidence surrounding the sender. The calendar provides structure. The evidence decides whether progression is safe.
What warm-up is actually proving
Mailbox providers are observing behaviour. ASI is observing whether the sender deserves the next operating step.
Stable identity
The sending domain, IP, sender identity, authentication, complaint routes, and message structure remain consistent enough to establish a recognisable pattern.
Responsible audience quality
The sender is using validated, permitted, unsuppressed recipients rather than testing its new reputation against inherited debris.
Controlled volume growth
Sending increases in bounded steps instead of creating a cold-volume shock that looks more like abuse than a serious operation.
Recoverable behaviour
When pressure appears, the sender slows, holds, investigates, and corrects rather than repeatedly driving into the same wall.
Four operating phases. No automatic promotion.
ASI does not publish a universal daily volume ladder because the safe rate depends on the licensed environment, data quality, provider mix, reputation evidence, and how the sender behaves during the proving period.
Establish the pattern
Begin cautiously with the cleanest available eligible audience. Confirm identity, authentication, complaint routes, provider behaviour, bounce evidence, and operational stability.
Grow under observation
Increase activity only while list health, complaints, provider response, queue behaviour, content evidence, and delivery conditions remain inside the protected range.
Prove repeatability
Show that stable behaviour can be repeated across multiple sends and provider lanes without accumulating complaint, bounce, or reputation pressure.
Confirm operating confidence
Use the final proving window to confirm that the sender can approach its approved operating lane without weakening the safety evidence built during the earlier stages.
A phase may be repeated, slowed, or held. Completing a week does not force ASI to increase volume when the evidence says the sender is not ready.
Warm-up progression is built from several evidence lanes.
No single open rate, dashboard score, or successful send can prove that the environment is ready for the next step.
Bounce evidence
Hard failures, repeated soft bounces, temporary rejections, provider reputation responses, and the quality of the data behind them.
Complaint and suppression evidence
Unsubscribes, complaints, abuse reports, suppression activity, and whether recipient-control routes are functioning properly.
Provider response
Acceptance, deferrals, rejection patterns, lane pressure, Google MX behaviour, and other provider-specific outcomes.
Content evidence
Draft Content Review warnings, subject and content risk, ignored suggestions, later edits, and the final sent version.
Queue and infrastructure health
Queue pressure, worker state, sending locks, operational services, bounce handling, and the health of the wider Linux environment.
Engagement quality
Useful human-confidence evidence can support understanding, but raw opens and clicks are not allowed to disguise weak permission, complaints, or provider pressure.
Unknown consent does not enter the Google warm-up lane.
During Google MX warm-up, marketing consent must explicitly equal Yes. Blank, null, unknown, or ambiguous consent is treated as No for that protected lane.
Automatic exclusion
Records without explicit marketing consent are automatically excluded from Google warm-up eligibility rather than placed in front of the operator as an approval prompt.
No global unsubscribe
Lane exclusion does not rewrite the subscriber as globally unsubscribed or suppressed. ASI records the reason for this specific eligibility decision.
Clearer starting evidence
The most sensitive provider lane begins with the clearest available permission evidence instead of using uncertainty as warm-up fuel.
Core owns the decision
The reason is recorded by ASI Core. The interface does not create an independent consent or eligibility truth.
A warm-up recipient still has to be eligible.
Warm-up changes the permitted operating volume and pacing. It does not suspend validation, consent, suppression, jurisdiction, Preflight, Queue Safety, complaint handling, or bounce controls.
Validation still applies
Warm-up is not the time to discover whether a purchased or inherited list contains dead domains, role accounts, or unsafe records.
Suppression still wins
An unsubscribe, complaint, block, or protected hold cannot be polished away because the sender wants more warm-up volume.
Preflight checks again
The selected audience is rechecked against current evidence before each campaign is queued.
Queue Safety remains active
If live evidence becomes unsafe, the campaign or provider lane can be held regardless of where the sender sits in the ten-week framework.
The right response to bad evidence is not always more volume.
ASI can hold or repeat the current warm-up step when the operating evidence no longer supports progression.
Complaint pressure
Complaint, abuse, unsubscribe, or recipient-control evidence suggests the audience or campaign behaviour needs correction.
Bounce or rejection deterioration
Hard failures, repeated temporary failures, provider rejection, or weakening list quality indicates that growth should stop.
Provider-specific concern
Google MX or another provider lane may need slower pacing or a hold without forcing every other provider into the same state.
Operational instability
Queue, worker, service, DNS, bounce, authentication, or infrastructure evidence shows the environment is not ready for additional load.
Give the new environment its best evidence first.
Warm-up works best when the operator behaves consistently and uses the strongest available audience, content, identity, and permission evidence.
Use the cleanest eligible audience
Begin with recipients supported by strong validation, permission, source, suppression, and relationship evidence.
Keep identity and cadence stable
Do not repeatedly change sender identity, domains, cadence, content style, or audience quality while trying to establish a reliable pattern.
Act on ASI warnings
Draft Content Review, Preflight, Queue Safety, Google MX, bounce, complaint, and operational warnings are evidence, not decorative weather icons.
Do not manufacture engagement
Warm-up is not improved by artificial activity, forced clicks, internal button-mashing, or pretending automated engagement is genuine human intent.
A setback does not mean starting from zero, but it does mean slowing down.
ASI preserves the evidence behind the hold so the sender can correct the likely cause, repeat the current phase, and resume cautiously under current conditions.
Review the evidence
Examine the campaign, audience, content, provider, bounce, queue, complaint, and infrastructure evidence surrounding the change.
Correct what can be corrected
Clean the data, fix content, repair infrastructure, adjust provider pacing, or resolve compliance and operational issues where the evidence supports it.
Repeat the proving step
The sender may remain at the current phase until stable evidence returns instead of progressing because the original schedule says it should.
Resume cautiously
Volume returns under bounded pacing and continued observation rather than snapping immediately back to the previous level.
A large legacy list does not justify an instant full-volume cutover.
Subscriber data can be migrated into ASI. The reputation of the previous platform, IP, or sending environment does not arrive inside the export file.
Stage the audience
Imported records move through validation, suppression, consent, source, jurisdiction, and eligibility controls before they influence warm-up.
Build reputation in the destination
The dedicated ASI domain and IP establish their own behaviour through the ten-week proving period.
Use a staged cutover
Business continuity can be planned while ASI earns the reputation required for the intended operating volume.
Preserve honest evidence
Legacy history may inform planning, but ASI does not pretend it observed provider behaviour or recipient events that occurred before cutover.
Ten weeks does not buy guaranteed inbox placement.
Mailbox providers control their own filtering and reputation decisions. Warm-up reduces avoidable risk and establishes better evidence. It does not grant immunity from poor data, weak content, complaints, inconsistent behaviour, or future provider changes.
No guaranteed inbox placement
No platform can force a mailbox provider to place every message in the inbox.
No permanent reputation certificate
Reputation remains live. Poor later behaviour can damage what was built during warm-up.
No permission bypass
Warm-up does not make unknown consent acceptable or convert a purchased list into a defensible audience.
No automatic full capacity
The licensed sending tier defines what the system can support, not what the sender is automatically entitled to use immediately.
Stable, repeatable sending.
The environment demonstrates controlled volume growth, sound list quality, functioning compliance routes, manageable provider response, healthy queue behaviour, and evidence that supports progression.
Volume rising faster than trust.
Complaints, weak consent, poor data, ignored content warnings, provider rejection, unstable queues, or repeated pressure indicate that the sender is trying to use capacity it has not yet earned.
Explore the surrounding ASI rails
Continue into Sending Engine & Queue Control, Google MX Protection, Subscriber Validation Pipeline, List Health & Validation, Email Compliance, and Migration & Merger Tools.
Ten weeks builds the framework. The evidence earns the progression.
Request a private Sender Review to examine your current domain and IP reputation, audience quality, consent evidence, provider mix, migration plan, sending volume, warm-up approach, and the risks that should be removed before serious scale begins.