Infrastructure, ESP and Migration Incidents

First 15 minutes

1. Confirm the affected Gmail traffic is using a multi-tenant IP and correlate delivery loss with that shared IP.
2. Ask the ESP whether another sender in the pool is driving throttling or blocking and document the remediation response.
3. Reduce nonessential affected Gmail volume while bounces or deferrals remain elevated.

Now

• Reduce affected Gmail volume until its SMTP error rate decreases.

Next 24 hours

• Choose a replacement path with explicit ownership for dedicated-IP reputation and blocklist monitoring if that option is used.
• When multiple IPs are available, separate account notifications from promotional messages.

Next 7 days

• Warm a new or cold dedicated SendGrid IP by increasing volume gradually according to traffic, history, engagement, and provider feedback.

Technical checks

Verification criteria

• The replacement path shows stable SMTP responses and reputation signals while volume is increased gradually across Gmail, other mailbox providers, and business-critical streams.

Escalation criteria

• Escalate the vendor or architecture decision when the ESP confirms persistent shared-pool throttling or blocking and cannot provide remediation; include the monitoring responsibility of any dedicated-IP option.

Prevention

• Separate message types across IPs when the architecture supports it, warm new dedicated IPs gradually, and monitor SMTP and reputation signals throughout the ramp.

Business impact

• Other senders' activity on a shared IP can reduce delivery rates or cause the affected customer's mail to be throttled or blocked.

Provider notes

• A SendGrid dedicated IP isolates the customer from other SendGrid users' IP reputations but makes the customer responsible for that IP's reputation and blocklist status.

Open questions

• The affected mailbox providers, SMTP-code distribution, current shared IPs, domain reputation, complaint rate, and ESP remediation record are not supplied.
• A safe choice among another shared pool, a dedicated IP, or a new ESP depends on stable volume, stream mix, provider capabilities, cost, and warmup capacity.

First 15 minutes

1. Confirm whether automated warmup is enabled, whether the warming IP reached its hourly limit, and whether another IP carried overflow.
2. Check Gmail authentication, forward and reverse DNS, TLS, formatting, applicable DMARC alignment, and Postmaster spam-rate signals.
3. Reduce the affected marketing stream to controlled warmup traffic and preserve critical transactional delivery on a separate warm route when possible.

Now

• Reduce the affected marketing stream to a controlled warmup volume and prioritize wanted, engaged recipients.

Next 24 hours

• If the dedicated IP was inactive for more than 30 days, warm it again under current SendGrid guidance.

Next 7 days

• Increase volume gradually only while provider-specific deferrals, complaints, authentication, and reputation remain stable.

Technical checks

Verification criteria

• Verify that warmup limits no longer produce overflow-related retries or message expiration risk for the affected stream.
• Increase volume only when provider deferrals, complaints, authentication, and reputation remain stable and Gmail requirements still pass where applicable.

Escalation criteria

• Escalate to SendGrid or the deliverability owner when automated warmup has no overflow capacity, retries approach expiration, or the controlled stream does not stabilize.

Prevention

• Begin new dedicated IPs at low to moderate volume and increase gradually.
• Rewarm a SendGrid dedicated IP after more than 30 days of inactivity and keep Gmail authentication and DNS requirements in the cutover checklist.

Business impact

• Warmup limits can create retries and, without another available IP, messages can expire after SendGrid's 72-hour retry window; authentication or Gmail requirement failures can compound the loss of delivery.

Provider notes

• A SendGrid dedicated IP isolates the account from other SendGrid users' IP reputations but not from domain, content, authentication, or list-quality signals.
• With automated warmup, traffic above the warming IP's hourly limit needs another available IP or can enter retries and eventually expire after the 72-hour retry window.

Open questions

• The cutover time, actual sending IP, prior IP history, warmup mode, overflow capacity, per-provider deferrals, domain authentication, recipient engagement, and stream mix are not provided.
• Warmup pace, provider response, inactivity handling, and minimum useful dedicated-IP volume vary by ESP and mailbox provider; SendGrid guidance is not a universal schedule.

First 15 minutes

1. Identify the SES Region, configuration set, and assigned IP pool used by the affected send.
2. If Virtual Deliverability Manager is enabled, drill metrics down by ISP, sending identity, and configuration set.
3. Review the account's bounce and complaint trends separately from mailbox-provider IP-reputation signals.

Now

• Prove the pool and stream, then reduce risky traffic while correcting bounce, complaint, list, and authentication causes.

Next 24 hours

• For a dedicated standard pool, restore gradual and consistent sending rather than returning abruptly to the prior pattern.

Next 7 days

• For shared routing, continue with SES identity and configuration-set evidence and AWS support instead of attributing the issue to an unknown neighboring sender.

Technical checks

Verification criteria

• Verify the affected Region, configuration set, and assigned pool from routing evidence for representative messages.
• Confirm that ISP-, identity-, and configuration-set metrics stabilize and that account bounce and complaint trends no longer threaten review or a sending pause.

Escalation criteria

• Escalate to AWS support only when shared-routing or provider-side evidence remains unresolved; if reputation, bounce, or complaint metrics continue to deteriorate on a sender-owned dedicated pool, escalate to the accountable internal deliverability owner.

Prevention

• Route streams through explicit configuration sets and assigned pools so shared and dedicated capacity can be proven later.
• For dedicated IPs, maintain consistent, predictable sending and monitor ISP, identity, and configuration-set metrics where Virtual Deliverability Manager is enabled.

Business impact

• Excessive SES bounce or complaint rates can place the account under review or pause its ability to send, regardless of whether the first signal was labeled poor IP reputation.

Provider notes

• SES uses shared IPs for new accounts by default; dedicated IPs are separately leased for the account's exclusive use.
• Virtual Deliverability Manager metrics are near real time and message records normally appear within minutes when the feature is enabled in the relevant account and Region.

Open questions

• The SES Region, configuration set, assigned pool, actual sending IP, alert text, affected ISP, identity, stream, and bounce or complaint trend are not provided.
• Shared, dedicated standard, and dedicated managed pools have different ownership, warmup, scaling, and observability behavior; the alert cannot be scoped without routing evidence.

First 15 minutes

1. Identify the actual outbound IP, SendGrid pool assignment, sending domain, and stream type for representative failures.
2. Compare IP- or pool-level failures with separately monitored domain-level spam and authentication signals.

Now

• Route the affected stream through its intended pool and keep transactional and marketing traffic separated where SendGrid pool controls are used.

Next 24 hours

• Monitor sending-domain spam and authentication signals separately from the actual outbound IP or pool.

Next 7 days

• If moving to a new dedicated IP, increase volume gradually and then maintain consistent volume.

Technical checks

Verification criteria

• Monitoring shows the intended outbound IP and pool for each stream while domain-level spam and authentication signals are tracked separately.

Escalation criteria

• Escalate to the ESP when a shared-pool neighbor appears to be changing IP reputation or causing throttling or blocking despite compliant sender behavior.

Prevention

• Maintain separate SendGrid IP pools for transactional and marketing traffic where isolation is required.
• Warm new dedicated IPs gradually and maintain consistent volume.

Business impact

• Negative shared-IP reputation can reduce delivery rates or trigger throttling and blocking, while domain reputation can continue to affect the sender after an IP change.

Provider notes

• SendGrid groups shared-IP customers by similar reputation, but pool placement can change and another sender can still affect the shared IP.

Open questions

• The actual ESP, outbound IPs, pool assignments, sending domains, stream mix, volumes, and mailbox-provider telemetry are not supplied.
• Mailbox providers weight IP, domain, content, authentication, complaints, and engagement differently and do not publish a universal reputation formula.
• A dedicated IP is not automatically safer: required volume and warm-up capacity depend on the sender and receiving provider, and no universal cutoff is supported here.

First 15 minutes

1. Record the actual outbound SMTP IP and the complete Gmail SMTP response.
2. Use available domain and IP reputation evidence to determine whether the current outbound path is the delivery constraint.
3. Check domain and IP reputation in Google Postmaster Tools when the traffic is eligible and the domain is verified.

Now

• Test any replacement provider's SPF and DKIM setup against current Gmail sender guidance before cutover.

Next 24 hours

• Compare a managed shared pool with a dedicated IP based on actual volume regularity, isolation needs, and operational control.

Next 7 days

• Cut over only after the replacement path authenticates the domain and passes receiver-specific delivery checks.

Technical checks

Verification criteria

• The current or replacement sending path has measurable domain and IP reputation evidence for Gmail rather than an assumption based on hosting type.
• Test messages from the proposed provider authenticate the domain with SPF and DKIM before production cutover.

Escalation criteria

• Escalate to the current host when it cannot identify the outbound SMTP IP or explain a matching Gmail 550 5.7.1 shared-reputation rejection.
• Escalate to the proposed provider when its Gmail authentication or sender-guideline checks fail before cutover.

Prevention

• Use a dedicated IP only when consistent, predictable sending can support the sender-owned reputation responsibility.
• Continuously verify that third-party senders authenticate the domain with SPF and DKIM and follow current receiver guidance.

Business impact

• If the outbound IP is shared and has negative reputation, other senders' activity can reduce delivery of your messages.

Provider notes

• A Gmail 550 5.7.1 response can identify poor shared-IP reputation; read the complete code and text before acting.
• AWS guidance favors shared IPs when volume is not large, regular, and predictable; it does not define a universal migration threshold.

Open questions

• No current primary GoDaddy document found in two searches states that the affected account's outbound SMTP IP is shared with unrelated tenants or that tenant reputation caused this incident.
• The actual outbound IP, whether it is shared, its receiver reputation, exact SMTP errors, and affected providers remain unknown.
• The best replacement architecture varies with volume, consistency, isolation needs, observability, and provider capabilities; dedicated IP is not universally better.

First 15 minutes

1. Compare pre- and post-migration bounce and deferral cohorts and reduce Gmail volume if the new path is producing more SMTP errors.
2. Test SPF, DKIM, and DMARC for every sending domain used on the new platform, including real received messages.
3. Normalize privacy-open and bot handling before comparing open rates, and prioritize clicks and purchases as stronger engagement signals.

Now

• Reduce Gmail volume when bounce or deferral errors rise, and ramp a newly introduced dedicated IP gradually.

Next 24 hours

• Recreate and test sending-domain authentication and import the required global or group unsubscribe records into the new account.

Next 7 days

• Increase traffic from the modified segment separately and continue a gradual ramp for any new dedicated IP.

Technical checks

Verification criteria

• Gmail SMTP error rates decline from the incident condition before volume is increased slowly.
• Real received messages pass the intended SPF, DKIM, and DMARC checks, and migrated unsubscribe records are present in the new account.
• Pre/post engagement is compared with consistent privacy handling and stronger signals such as clicks or purchases rather than raw opens alone.

Escalation criteria

• Escalate to the ESP or deliverability owner when bounce or deferral errors do not decline after volume reduction and a controlled new-IP ramp, or when suppression continuity cannot be confirmed.

Prevention

• Use a migration checklist that separates modified traffic, plans any new dedicated-IP ramp, retests authentication, transfers suppressions, and normalizes engagement definitions.

Business impact

• Rising Gmail bounces or deferrals during the migration can reduce customer reach, while missing migrated global unsubscribes can break suppression continuity.

Provider notes

• For SendGrid's documented partner-account migration, sender authentication must be set up manually and global unsubscribes must be exported and imported.
• Mailchimp documents that Apple Mail Privacy Protection inflates opens, so raw open rates are not comparable until tracking treatment is normalized.

Open questions

• It is unknown whether the migration changed dedicated versus shared IPs, sending domains, authentication records, tracking domains, or traffic allocation.
• The contribution of IP warmup, authentication, suppression migration, reputation, and metric-definition changes is unresolved without pre/post cohorts.
• Pre-migration and post-migration bounce, deferral, complaint, placement, and Apple Mail Privacy Protection-adjusted engagement data are not available.

First 15 minutes

1. Confirm whether the ESP has actually assigned shared IPs and whether it requires customer-specific IP warm-up.
2. Establish whether the visible or DKIM domain and any sending subdomain are new, unused, or already mature.
3. Separate the shared-IP service configuration from the new domain's history before choosing a ramp action.

Now

• Use distinct authenticated subdomains for transactional and promotional streams when introducing a new sending identity.

Next 24 hours

• Build an evidence-driven domain ramp without assuming one provider's numerical schedule is universal.

Next 7 days

• Adjust the ramp from receiver-specific bounce, engagement, and placement results.

Technical checks

Verification criteria

• Volume increases occur only after receiver-specific bounce, engagement, and placement evidence supports the next step.
• Domain evidence and shared-pool evidence are separately observed, with ESP support involved when pool reputation appears to be the failing signal.

Escalation criteria

• Escalate to the ESP when delivery evidence points to negative shared-pool reputation; slow the domain ramp when receiver-specific outcomes deteriorate.

Prevention

• Keep transactional and promotional mail on distinct authenticated subdomains and introduce each new subdomain gradually.
• Maintain a receiver-evidence-based ramp instead of a universal calendar or volume schedule.

Business impact

• A new domain can develop weak receiver reputation even on a ready shared pool, and a damaged shared-IP reputation can independently affect delivery.

Provider notes

• Twilio SendGrid says its shared IPs do not need individual IP warm-up, while Amazon SES describes its shared option as ready without additional IP configuration.

Open questions

• The domain and subdomain history, first-send date, expected volume, recipient mix, engagement, ESP, actual pool assignment, authentication, and current delivery evidence are not provided.
• Shared-IP readiness, pool management, domain-reputation behavior, receiver thresholds, and recommended ramp schedules vary among ESPs and mailbox providers.