## TL;DR
A 5.7.1 blocked bounce on a dedicated IP means a blocklist has the IP listed, and sending through it keeps failing until the listing is resolved. Pause sends from the IP, find which blocklist listed it and why (complaints, bad list hygiene, or content), fix the underlying cause, request delisting, then warm the IP back up gradually.

## The query

```text
sendgrid '550 5.7.1 blocked'  -  agent's dedicated IP landed on a blocklist
```

## Steps

### 1. Pause sends on the listed IP and confirm the listing
Stop the agent's sends from the dedicated IP and check the IP against major blocklists with a multi-RBL lookup tool. Note exactly which lists show the IP; the delisting path differs per list.

Expected: you have the list name (or names) with the IP flagged.

### 2. Fix the cause before requesting delisting
Check SendGrid stats for the IP: complaint rate, bounce rate, and which campaigns spiked. Scrub hard bounces and complainers from the list, and fix whatever drove the complaints (stale list, misleading subject lines, missing unsubscribe handling). Delisting without fixing the cause gets you relisted within days.

Expected: complaint and bounce drivers identified and cleaned lists ready.

### 3. Request delisting from each blocklist
Follow each blocklist's delisting process with evidence the cause is fixed. Most process requests within 24 to 72 hours. Track the request; some lists require a follow-up.

Expected: the IP clears from every listing blocklist.

### 4. Warm the IP back up gradually
Restart sending at low volume to your most engaged recipients and ramp over one to two weeks. Monitor blocklist status and complaint rates daily during the ramp.

Expected: delivery returns to normal with no new listings during the ramp.

## Use this when

- SendGrid bounces cite 550 5.7.1 blocked on a dedicated IP
- Delivery to multiple providers collapses at once (blocklist, not one provider's filter)
- A multi-RBL lookup shows the sending IP listed

## Not for this skill when

- The bounce is Gmail 5.7.26 (authentication, not reputation)
- The IP is shared (reputation is SendGrid's pool, handled differently)
- Mail is deferred with 4xx codes rather than rejected with 5xx

## Variant phrasings

### sendgrid dedicated ip blocked 550 5.7.1
Short form. Same diagnose-cause-delist-warmup sequence.

### our sendgrid ip got blocklisted
Operator phrasing. Start with the multi-RBL lookup to name the list.

### sendgrid 5.7.1 blocked sending from dedicated ip
Word-order variant of the same bounce. Identical handling.

## Why it happens
Blocklists track IPs by complaint and bounce behavior. A dedicated IP concentrates all of one sender's behavior, so a stale list, an aggressive campaign, or a spam-trap hit lists the IP directly. Receiving providers then reject everything from it. Agents trigger this by mailing large unscrubbed lists at full speed with no warmup and no suppression hygiene.

## Edge cases

- Some blocklists auto-expire listings after a quiet period; others require manual requests. Check the specific list's policy.
- If the IP keeps getting relisted, the list source is the problem: audit where addresses come from before warming again.
- A brand-new dedicated IP with no warmup can look suspicious to blocklists. Never skip the ramp on a fresh IP.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_nwyGPFmJ7Kvuk0GpEJV9FQ