Outbound domains and mailboxes need a lifecycle: preparation, monitoring, incident handling, and a deliberate rotation decision. Diagnose performance drops before deciding to replace the sending identity. Burned is a label for several failure modes.1 Rejected messages, deferred messages, spam placement, and disappearing replies can all sit under that label, and those failure modes have different owners and fixes.2, 3 Fast rotation can damage deliverability more than it protects it.4 Authentication failure, abrupt volume changes, complaints, poor list quality, compromised accounts, shared sending IPs, and content or URL reputation can produce similar outcomes.5
Prepare before sending
Purchase and setup determine whether an identity is ready when demand arrives. Put the configuration gate in place before assigning traffic, and keep the record usable for later diagnosis.
Buy domains and mailboxes about a month before you need to send.6 Infrastructure setup includes purchasing the sending domains, configuring SPF, DKIM, and DMARC, and starting mailbox warm-up, which takes two to three weeks if done properly.7
The mailbox and domain gate should cover the sending identity, DNS, provider limits, bounce and complaint alerts, the tracking domain, pause controls, and quarantine work.8 Use it to answer practical questions:
- Which identity is sending this traffic?
- Which DNS records need checking before launch?
- Where will provider limits, bounces, and complaints appear?
- Who can pause traffic and quarantine an affected mailbox?
- Which tracking domain belongs to this sending path?
Proceed when those answers are recorded and someone can act on them without reconstructing the setup from memory.
Monitor the sending identity
Monitoring should show when an identity has changed enough to investigate. Keep routine checks separate from incident response so a missed dashboard signal does not become the only warning.
Monitor custom-domain status in the Sender Domains section.9 For routine monitoring, check monthly for email marketing domains.10 Review the status alongside bounce and complaint alerts, provider limits, and the sending pattern you intended to run.
When a status change or performance shift appears, record what changed and when.
Diagnose the failure
Start with observable receiving behavior. Identify the failure mode, the provider that saw it, and the part of the sending path that owns the fix.
Capture provider, SMTP, authentication, complaint, ownership, remediation, and go/no-go evidence in a 33-column CSV.11 Check whether the problem involves rejection, deferral, spam placement, disappearing replies, authentication, volume, list quality, account security, shared infrastructure, or content and URL reputation.
Google's Postmaster Tools dashboards separate spam rate, authentication, compliance, and delivery errors.12 Google warns that this data is delayed and may be absent at low volume.13 Treat the dashboard as one diagnostic input and compare it with provider-specific delivery records and mailbox alerts.
A blank dashboard cannot prove that the domain is healthy.14 If the symptom is visible while the dashboard is empty, keep working from delivery records, authentication checks, complaints, and the sending pattern.
Recover through containment and testing
Recovery starts by containing the affected traffic while normal business mail stays protected. Return the sending identity only after the cause has been addressed and controlled tests pass.
Stop the suspected bulk or automated traffic.15 Pause the campaign, sequence, connector, or compromised account that changed the normal sending pattern.16 Diagnose the failure by mailbox provider, capture provider-specific evidence, protect business-critical mail, and use the incident record to decide what can continue.17
Verify SPF, DKIM, and DMARC alignment, fix the source of complaints or failures, and resume only after controlled tests pass.18 There is no universal recovery timer for email deliverability incidents.19
Match the remedy to the fault. If authentication is the fault, fix the record. If the sending pattern is the fault, stop it. If an account or mailbox is the fault, isolate the affected sender while protecting normal mail. A new domain cannot explain or repair every failure that appears under its name.
Rotate or replace with a reason
Rotation belongs in planned capacity management. It becomes risky when it is an automatic response to weak reply or open rates.
One rotation model reports inbox placement falling from 92% in month 1 to 63% by month 10 when a domain stays in continuous service.20 The same model moves each cold email sending domain out of active duty every 4 to 6 months, rests it for 4 to 6 weeks, and keeps the total portfolio at 1.6 to 2 times the number of actively sending domains.21 Use that as a planning model for active, resting, and warming capacity, while the identity's incident history controls the decision.
Teams often switch domains and inboxes when reply rates decline or open rates weaken.22 Campaigns with strong inbox placement rarely rotate domains aggressively, build sender reputation slowly and stably, and protect behavioral consistency.23 Use a fresh identity only after the record shows what failed, the affected traffic is contained, and recovery tests give you a reason to retire or replace the old identity.
When tests pass, return the identity to service under controlled traffic. When they fail, keep it out of active sending while deciding whether the domain, mailbox, configuration, account, or sending pattern needs a different remedy.
What not to do
These mistakes can turn a recoverable incident into an unexplained rotation cycle.
- Treat the event as an operational incident before changing copy, buying another domain, or requesting delisting.24
- Most teams treat domains as disposable sending tools, while mailbox providers account for domain history when treating the sending path.25, 26
- Do not use a fixed countdown as the reason to restart traffic.19
- Do not read a blank Postmaster Tools dashboard as proof of health.14