Domain and mailbox lifecycle

Run domain and mailbox lifecycle as an operating loop. Start with the failure you can observe, identify the unit causing it, then choose containment, repair, restart, or planned rotation. The label burned covers several diagnoses.¹ It can describe rejected or deferred messages, spam placement, or delivered mail whose replies disappear.² These failure modes have different owners and fixes.³ Contain the send, diagnose the failure by mailbox provider, protect business-critical mail, and use evidence to decide when to restart.⁴ No universal recovery timer exists.⁵

Run the lifecycle in order

1

Classify

2

Contain

3

Diagnose

4

Repair

5

Restart

1. Classify
2. Contain
3. Diagnose
4. Repair
5. Restart

The work follows a decision path. Move to the next stage when the current one has produced the record or test result it needs.

Stage	What you are trying to learn	Example question
Classify	What failed, and where does the symptom appear?	Which receiving system is rejecting, deferring, filtering, or losing the reply?
Contain	Which traffic needs to stop while normal mail continues?	Which campaign, sequence, connector, or account changed the sending pattern?
Diagnose	What caused the failure, and which unit owns it?	What do provider, SMTP, authentication, and complaint records show?
Repair	Has the cause been fixed?	What changed, and how will we test that change?
Restart	Do controlled tests support sending again?	What result gives us a go decision?
Rotate or retire	Is this a scheduled lifecycle move or an incident response?	Should this domain move to rest, or does the incident still need work?
Monitor	Who checks status and makes the next pause decision?	Who owns the next check and what would trigger a pause?

Classify the incident

The first job is to separate symptoms from causes. A delivery problem that looks like a domain issue can begin in authentication, volume, list quality, an account, an IP, or the content being sent.

The symptom can be visible while its cause remains hidden.⁶ Similar outcomes can come from authentication failure, an abrupt volume change, recipient complaints, poor list quality, a compromised account, a shared sending IP, or content and URL reputation.⁷ Record the affected receiving system and the exact failure mode before changing copy or infrastructure. Describe what happened in terms a provider or operator can investigate.

Contain before you change infrastructure

Pause the campaign, sequence, connector, or compromised account that changed the normal sending pattern.⁸ Stop the suspected bulk or automated traffic.⁹ Protect normal business mail while the incident is open. Treat the event as an operational incident before changing copy, buying another domain, or asking for delisting.¹⁰ Record the scope once the suspected source is paused.

Diagnose by receiving system

Diagnosis needs provider-level records because one receiving system can show a different failure from another. Build one incident record that lets you compare the symptom, owner, fix, and restart decision.

Google's Postmaster Tools dashboards separate spam rate, authentication, compliance, and delivery errors.¹¹ Their data is delayed and may be absent at low volume.¹² A blank dashboard does not prove that the domain is healthy.¹³

Use a 33-column CSV to capture provider, SMTP, authentication, complaint, ownership, remediation, and go/no-go evidence.¹⁴ Check the records against the failure you classified earlier. If the provider evidence points to authentication, move to configuration repair. If it points to complaints, list quality, content, or a compromised account, fix that source before testing the domain again.

Repair and restart from evidence

Repair the cause you found, then make the restart a controlled test. A pause without diagnosis leaves the same failure ready to return.

Verify SPF, DKIM, and DMARC alignment, fix the source of complaints or failures, and resume only after controlled tests pass.¹⁵ Use the incident record to state what changed and what result would justify a wider send. Resume when the test passes and the go/no-go field has a clear decision.

Decide what should change

A lifecycle decision should identify the smallest unit that needs attention. This keeps a mailbox problem, an account problem, and a domain problem from becoming one vague replacement decision.

A burned domain can mean that the domain or the infrastructure sending on its behalf is no longer being treated normally by one or more receiving systems.¹⁶ Use the incident record to decide whether the affected unit is a mailbox account, a connector, an infrastructure path, or the domain itself. The remediation and go/no-go fields should carry that decision forward. If the cause is still unclear, keep the affected traffic contained and continue diagnosis.

Run planned domain rotation separately

Routine rotation follows a schedule, while incident response follows the failure record. Mixing them encourages emergency switching when the task is diagnosis.

Use parallel pools of active, resting, and warm-up domains.¹⁷ A published rotation practice recommends moving each cold email sending domain out of active duty every 4 to 6 months, resting it for 4 to 6 weeks, and keeping a total portfolio 1.6 to 2 times the number of actively sending domains.¹⁸ Treat those intervals as an operating plan, then adjust from the condition of the domains you can observe.

Continuous service can show a long decline in placement. One reported average moves from 92% inbox placement in the first month to 78% by month 6 and 63% by month 10.¹⁹ These are averages. Individual domains can hold up better or degrade faster, but the trend is universal.²⁰ Email providers maintain rolling reputation windows of 30 to 90 days, and a domain active for 6 months accumulates more negative signals than one active for 6 weeks.²¹ Use the resting pool to make the scheduled move without forcing an incident decision onto a healthy active domain.

When a domain leaves active duty, record its status, the reason for the move, and the condition required for return. When a warm-up domain is ready, assign it only after the incident and ownership records are clear. The lifecycle is working when a replacement is available before a sending domain becomes the only path for outbound traffic.

Monitor ownership and status

Monitoring works when someone owns the check and everyone knows what result triggers a pause. Put the check into the operating routine before a domain enters active sending.

Monitor custom-domain status in the Sender Domains section.²² A monthly check is recommended for routine monitoring of email marketing domains.²³ Record who handles domain registration, mailbox creation, authentication, warm-up, sender-group assignment, problem monitoring, and pause decisions.²⁴ Give each action a named owner in the operating record so a warning does not wait for a meeting.

What not to do

• Do not answer weak campaign signals by switching domains and inboxes immediately, because quick switching can damage deliverability.²⁵
• Do not rotate aggressively as the default response; strong placement tends to come from slow reputation building and consistent sending behavior.²⁶
• Do not put an outbound domain into sending before it has been warmed.²⁷
• Without replacement planning, the domain's limited useful lifespan goes unmanaged.²⁸

Keep the incident record beside the rotation schedule, with the affected unit and next decision visible.