Prove that the affected message used the IP

Capture provider message ID, UTC time, outbound pool/IP, recipient provider, SMTP response or trusted Received evidence, and the official listing result. A provider range containing an address is not enough; shared pools rotate and an incident can affect one segment.

Confirm that the IP is provider-owned/shared rather than a dedicated address assigned to your account. Record the provider account, region, and sending stream.

Protect what you control

Review your recent campaigns, acquisition, complaints, bounces, credential access, API keys, templates, and links. Pause suspicious traffic, rotate compromised credentials, and reconcile suppression. Do not assume another tenant caused the issue merely because the pool is shared.

Keep normal legitimate volume stable where the provider recommends it; sudden migration to an unprepared IP or domain can create another reputation problem. Do not evade a receiver block by cycling provider accounts.

Escalate to the network owner

Provide a sanitized evidence pack: affected IDs/times, pool/IP, recipient response, official list/category, representative headers, scope, and your account-side checks. Ask whether the provider has already isolated the source, moved your stream, opened a removal case, or recommends a documented mitigation.

The provider controls tenant enforcement, routing, rDNS, pool composition, and most list-operator communication. Do not submit a removal request claiming network control you do not have.

Evaluate migration options deliberately

A dedicated IP gives more isolation and operational responsibility; it does not create good reputation automatically. Assess volume consistency, warm-up/traffic plan, reverse/forward DNS, monitoring, failover, and cost. For many low-volume senders, a well-managed shared pool can remain more appropriate.

Verify recovery

Monitor official listing status, provider responses, Gmail/Yahoo-specific dashboards where available, bounces, complaints, and controlled placement observations. Google notes that dashboard data is not real-time and can be absent at low volume; keep those limitations visible.

Close the incident when provider remediation is documented and representative traffic recovers across the affected path. Do not claim that one delisting proves every receiver has recovered or that shared infrastructure was the sole cause without evidence.