Incident: Block Bounces

What Is a Block Bounce?

A block bounce is a permanent rejection (5xx SMTP response) where the receiving server explicitly refuses to accept your message. Unlike soft bounces (temporary 4xx responses), block bounces mean the receiving server has made a definitive decision: this message is not welcome.

Block bounces come in two varieties:

Recipient-level blocks: The specific address doesn’t exist or can’t receive mail (550 5.1.1). These are addressable by suppressing the invalid address.

Sender-level blocks: The receiving server is rejecting mail from your IP, domain, or sending identity (550 5.7.1). These indicate a reputation or policy problem that affects all your mail to that provider.

This playbook focuses on sender-level blocks — the ones that signal a deliverability crisis.

Identifying Block Types

Authentication Blocks

550 5.7.26 This message does not have authentication information or
fails to pass authentication checks.

Cause: SPF fails, DKIM signature is invalid, or DMARC policy triggers rejection.

Diagnosis:

1. Check SPF record for your sending domain — does it include all sending IPs?
2. Verify DKIM signing is active and the public key matches the signing key
3. Check DMARC alignment — does the RFC5322.From domain align with SPF and/or DKIM domains?
4. Use Mailwel’s Header Analyzer to trace authentication results in a test message

Resolution:

• Fix the authentication record that’s failing
• If you recently changed ESPs or added a sending service, update SPF to include their IPs
• If DKIM keys were rotated, verify the new public key is published in DNS
• Allow 24–48 hours for DNS propagation after fixes

Reputation Blocks

550 5.7.1 [domain] Our system has detected that this message is likely
unsolicited mail. This message has been blocked.

Cause: Your domain or IP reputation has degraded to the point where the provider is permanently rejecting your mail.

Diagnosis:

1. Check Google Postmaster Tools — is domain reputation “Low” or “Bad”?
2. Check Microsoft SNDS — are your IPs showing red status?
3. Check blocklists — are you listed on Spamhaus, Barracuda, or others?
4. Review complaint rates for recent campaigns
5. Check for spam trap hits

Resolution: This is the hardest type to fix because reputation is slow to rebuild:

1. Immediately stop sending to unengaged subscribers
2. Reduce volume to only your most engaged segment
3. Fix the root cause (list quality, complaint handling, trap hits)
4. Gradually rebuild volume as reputation improves
5. Monitor Postmaster Tools daily for reputation recovery

Blocklist-Driven Blocks

553 5.7.1 [BL21] Connections will not be accepted from [IP],
because the ip is in Spamhaus's list; see http://www.spamhaus.org/

Cause: Your sending IP or domain is listed on a DNS-based blocklist that the receiving server queries during SMTP processing.

Diagnosis:

1. Query the blocklist mentioned in the rejection message
2. Check MXToolbox or Multirbl for comprehensive blocklist status
3. Identify which specific list (SBL, XBL, CBL, DBL) you’re on
4. Determine the listing reason (spam trap hit, complaint volume, compromised IP)

Resolution:

1. Identify and fix the root cause before requesting delisting
2. Submit a delisting request through the blocklist’s removal process
3. For Spamhaus SBL: requires evidence of remediation
4. For SpamCop: auto-expires in 24–48 hours after complaints stop
5. For Barracuda: self-service removal, typically processed within hours
6. Monitor to ensure you don’t get re-listed

Policy Blocks

550 5.7.25 [domain] Unauthenticated email from [domain] is not
accepted due to domain's DMARC policy.

Cause: Your DMARC policy is set to p=reject, and the message failed both SPF and DKIM alignment. The receiving server is honoring your own DMARC policy.

Diagnosis:

1. Check your DMARC record — is the policy p=reject?
2. Identify which sending flow is failing alignment
3. Common cause: a third-party service sending on your behalf without proper DKIM signing

Resolution:

• Configure the third-party service to sign with your domain’s DKIM
• Or add the service’s sending IPs to your SPF record
• If you can’t fix alignment for a specific flow, consider a subdomain with a different DMARC policy

Volume/Rate Blocks

550 5.7.1 Mail from [IP] has been temporarily rate limited due to
very high volume. Please try again later.

Cause: Despite the 550 code (some providers misuse 5xx for what should be 4xx), this is a volume-based block triggered by sending too much too fast.

Diagnosis:

1. Check how much volume you sent in the last hour/day
2. Compare to your normal sending pattern
3. If you recently increased volume, the spike may have triggered defenses

Resolution:

• Reduce sending rate immediately
• If you’re warming up a new IP, slow down the warmup schedule
• Implement per-provider rate limiting in your MTA
• Spread sends across a longer time window

The Block Bounce Triage Process

When you discover a block, follow this systematic process:

Step 1: Scope Assessment (First 30 Minutes)

• Which providers are blocking? Global blocks (all providers) vs. single-provider blocks require different responses
• Which IPs are affected? One IP or all sending IPs?
• Which domains are affected? One domain or all sending domains?
• What’s the error category? Authentication, reputation, blocklist, or policy?
• How many messages are affected? What percentage of total volume is bouncing?

Step 2: Root Cause Identification (First 2 Hours)

• Check authentication: Run SPF, DKIM, DMARC checks through Mailwel’s DNS Lookup tool
• Check blocklists: Query Spamhaus, Barracuda, SpamCop, SORBS
• Check reputation tools: Google Postmaster Tools, Microsoft SNDS
• Check recent changes: DNS modifications, infrastructure changes, new sending services
• Check recent campaigns: Complaint rates, bounce rates, engagement drops
• Check bounce logs: Categorize all recent rejections by error code and recipient domain

Step 3: Immediate Mitigation (First 4 Hours)

Based on the root cause:

Step 4: Recovery (Days to Weeks)

After mitigating the immediate cause:

1. Send only to engaged subscribers for the first 2 weeks
2. Monitor bounce rates daily — they should decrease steadily
3. Check reputation tools daily — look for reputation recovery signals
4. Gradually increase volume as reputation improves (similar to IP warmup)
5. Document the incident — what caused it, what fixed it, and what prevention measures to implement

Prevention Strategies

Authentication Monitoring

• Run weekly authentication checks using Mailwel’s DNS Lookup
• Set up DMARC aggregate reports (rua tag) and review weekly
• Monitor DMARC forensic reports (ruf tag) for alignment failures
• Set up alerts for any DMARC policy failures exceeding 1% of volume

Reputation Monitoring

• Check Google Postmaster Tools daily (domain reputation, IP reputation, spam rate)
• Check Microsoft SNDS weekly (IP status, trap hits)
• Monitor complaint rates per campaign (threshold: 0.05%)
• Monitor engagement metrics for decline trends

List Hygiene

• Process hard bounces immediately (suppress on first 5xx)
• Sunset unengaged subscribers after 180 days of inactivity
• Validate new addresses at signup (syntax, MX verification)
• Run periodic list validation through a verification service

Volume Management

• Warm up new IPs gradually (follow the warmup plan)
• Don’t spike volume more than 2x in a single day
• Implement per-provider rate limits in your MTA
• Spread large campaigns across multiple hours

Escalation: When to Contact the Provider

If you’ve fixed the root cause and requested blocklist delisting but blocks persist:

Gmail: Use the Gmail Postmaster Troubleshooter or submit a bulk sender contact form. Include your domain, affected IPs, DMARC alignment evidence, and description of remediation steps taken.

Microsoft: Use the Microsoft Sender Support form (https://sender.office.com). Include the NDR (Non-Delivery Report) text, affected IPs, and remediation details.

Yahoo: Use Yahoo’s Postmaster page to report deliverability issues. Include bounce message details and evidence of compliance.

General approach when escalating:

1. Be specific — include exact error messages, IPs, dates
2. Show evidence of remediation — what you found and what you fixed
3. Demonstrate good practices — authentication, list management, complaint rates
4. Be patient — provider support teams process many requests and may take days to respond
5. Don’t be combative — you’re asking for help, not demanding access

Block bounces are the email equivalent of a fire alarm. They’re loud, urgent, and demand immediate attention. But like fire alarms, the response should be systematic: assess the scope, identify the source, contain the damage, and prevent recurrence. Panic and rapid changes often make things worse. Follow the process.