Incident: Block Bounces

A block bounce is a permanent refusal aimed at you, the sender, not at one address. It means a provider like Gmail or Outlook has stopped accepting your email. This playbook shows you how to tell which kind of block you have, what to do in the first hours, and how to recover without making it worse.

What a block bounce is

The receiving server answers every delivery with a reply code. A code starting with 5 is a permanent refusal: your server gives up. A code starting with 4 is temporary and gets retried (a soft bounce).

Permanent refusals come in two kinds:

• The address is the problem (hard bounce). It doesn’t exist, for example 550 5.1.1. Remove it and move on.
• You are the problem (block bounce). The server refuses mail from your IP address (the number that identifies your sending server), your domain or your setup, often with 550 5.7.1. This hits all your email to that provider.

Which kind of block is it?

Read the code and the text after it. The text usually names the reason. [domain] and [IP] stand for your domain and your server’s IP address.

Authentication blocks

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

Your email failed authentication: the checks that prove it really comes from your domain. They use three DNS records:

• SPF: the list of servers allowed to send for your domain
• DKIM: a signature that proves the email came from your domain
• DMARC: your instruction for what to do when those checks fail

Since May 2025, Outlook.com refuses bulk mail without them using its own code:

550 5.7.515 Access denied, sending domain [domain] does not meet the
required authentication level.

Check:

1. Look up SPF with the DNS lookup. Does it include every service that sends for you?
2. Is DKIM signing on, and does the public key in DNS match the signing key?
3. Is DMARC aligned? The domain in the visible From address must match the domain that passed SPF or DKIM.
4. Send a test to the test inbox, or paste headers into the header analyzer, to see which check fails.

Fix: correct the failing record. Add any new email service to SPF and set up DKIM for it. After changing DKIM keys, check the new public key is published. DNS changes usually show up within minutes to a few hours. The record’s TTL (how long other servers may keep the old copy) sets the upper limit.

Reputation blocks

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

Your reputation (the provider’s trust in your domain and IP) has fallen so far that it refuses your email.

Check:

1. Your spam rate and delivery errors in Google Postmaster Tools (Google’s free dashboard for senders).
2. Red IPs in Microsoft SNDS (its free dashboard for IP addresses).
3. Blocklists such as Spamhaus and Barracuda.
4. Complaint rates of recent campaigns.
5. Signs of spam trap hits (addresses that exist to catch bad lists), such as a blocklisting soon after mailing an old list.

Fix: this is the hardest kind, because reputation is slow to rebuild. Send only to your most engaged readers, fix the cause (a bad list, ignored complaints, spam trap hits), and raise volume slowly. The reputation recovery playbook gives the full plan.

Blocklist 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/

Your IP or domain is on a blocklist (a public list of spam sources) that the receiving server checks.

Check:

1. Look up your IP or domain on the list named in the reply, then use a multi-list checker to find any others.
2. Note which list it is. Spamhaus, for example, has lists for IP addresses (such as the SBL and XBL) and for domains (the DBL).
3. Find out why: a spam trap hit, many complaints, or a hacked server or account.

Fix:

1. Fix the cause first. Otherwise you’ll be listed again.
2. Request removal on the list’s own website. Spamhaus wants to see what you fixed. SpamCop listings expire by themselves, usually about a day after reports stop. Barracuda has a removal form and usually acts within hours.
3. Keep checking that you stay off the list.

Blocks caused by your own DMARC policy

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

Your DMARC policy is p=reject, which tells receivers to refuse email that fails your checks. This email failed both SPF and DKIM alignment, so the receiver did what you asked.

Check: confirm the policy is p=reject, then use your DMARC reports to find the failing source. It’s usually a service sending for you, such as a CRM, help desk or billing tool, without DKIM set up for your domain.

Fix:

• Set up DKIM for that service with your domain. This is the best fix.
• Or add it to SPF, if it uses your domain in its bounce address (the envelope sender).
• If a service can’t be fixed, move it to a subdomain such as billing.shop.example with its own DMARC policy.

Volume blocks

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

You sent too much, too fast. The text says “temporarily”, but the 5xx code means your server won’t retry. Some providers use 5xx where 4xx would fit better.

Check: did your hourly or daily volume jump above normal, for example during an IP warm-up (slowly raising volume on a new IP)?

Fix: slow down now. Slow the warm-up schedule if you’re on one. Set per-provider speed limits, and spread large sends over more hours.

The four-step response

When you find a block, work through these steps in order. Don’t change several things at once in a panic.

Step 1: Find out how bad it is (first 30 minutes)

• Which providers? A block at all of them usually means a blocklist or broken authentication.
• Which IPs and sending domains? One, or all?
• Which kind of block? Authentication, reputation, blocklist, DMARC policy or volume?
• How big? What share of your email is bouncing?

Step 2: Find the cause (first 2 hours)

Run the checks for your kind of block from the section above. Also look at:

• Recent changes: DNS edits, new servers, new sending services.
• Recent campaigns: complaints, bounces, falling opens and clicks.
• Your logs: group refusals by code and receiving domain, as the SMTP log playbook shows.

Step 3: Stop the damage (first 4 hours)

Cause	What to do now
SPF or DKIM failure	Fix the DNS record and wait for it to update
DMARC refusal	Fix alignment for the failing service
Spamhaus listing	Fix the cause, then request removal
Complaint-driven block	Stop mailing unengaged readers and lower volume
Volume spike	Slow down and set speed limits
Hacked account	Lock it, change passwords, check what was sent

Step 4: Recover (days to weeks)

1. For two weeks, send only to people who opened or clicked recently.
2. Check bounces, Postmaster Tools and SNDS daily. Bounces should fall steadily.
3. Raise volume slowly, as you would when warming up a new IP.
4. Write down the cause, the fix and how you’ll prevent it.

Preventing blocks

• Authentication. Check your records weekly with the DNS lookup. Add a rua tag to your DMARC record so providers send you aggregate reports (daily summaries of who sent email as your domain). Investigate any source that fails.
• Reputation. Check Postmaster Tools daily and SNDS weekly. Track complaints per campaign. Gmail and Yahoo require bulk senders to stay under 0.3%, and Google recommends under 0.1%.
• Your list. Remove an address the first time it hard bounces. Stop mailing people inactive for about six months, or try to win them back first. Check new addresses at signup.
• Volume. Warm up new IPs slowly. Avoid sudden jumps: doubling overnight is already a big one. Set per-provider speed limits.

Asking the provider for help

If you’ve fixed the cause, been removed from blocklists, and the block continues, contact the provider. Reaching a postmaster covers this in detail.

• Gmail: the sender contact form linked from Google’s sender guidelines.
• Outlook.com and Hotmail: the sender support form on Microsoft’s postmaster site. For Microsoft 365 business mailboxes, the delist portal at sender.office.com.
• Yahoo: the support form on Yahoo’s sender site.

Include exact error messages, IPs and dates. Explain what you found and what you fixed, and show that you authenticate and keep complaints low. Be polite and patient: replies can take days.

Checklist

• Read the full reply text. It usually names the kind of block.
• Find out how bad it is before you change anything.
• Check authentication, blocklists, dashboards and recent changes.
• Fix the cause before you ask to be removed from any list.
• Send only to engaged readers until the block clears, then raise volume slowly.
• Write down what happened and how you’ll prevent it.
• Contact the provider only after you’ve fixed the cause.