Bounce and error codes

550 permanent failure means the receiver refused for good

Last updated 2026-08-28

Two different bounces share this code. One is the bare SMTP class, where a server refused a message and the log shows a 550 with a dotted code beside it. The other is a specific sentence, 550 permanent failure for one or more recipients, which comes from a filtering gateway in front of the recipient. Read your dotted code first, because the table below names the fix for each one. The Barracuda sentence has its own section further down.

550 is permanent, 4xx is a delay

RFC 5321 sorts every SMTP reply by its first digit, and that digit says whether you wait or act. A 4yz reply is temporary. The RFC says those replies "can be successful if repeated without any change in command form or in properties of the sender or receiver". The sending server queues the message and retries. A 5yz reply is final. RFC 5321 tells the SMTP client that it "SHOULD not again attempt delivery to the same server without user review of the message and response and appropriate intervention". The copy you sent is gone. Something has to change before the next attempt: the address, your DNS, your sending IP, or the receiver's own rules.

Your own server received the refusal, so the person you wrote to has no copy of it. Their thread shows nothing new, and they have no reason to chase you.

550 is the broadest reply in that class. RFC 5321 defines it as "Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons)". That last clause is why one number covers a typo in an address and a spam block on your whole domain. Email bounced back walks the full triage for any bounce, including the 4xx side.

Dotted codes name the rule that fired

Most receivers print a second, dotted code beside the 550. The 550 names the class, and the dotted code names the rule that fired. Copy the whole reply out of the bounce before you close the notice. The dotted code decides which of the fixes below is yours.

After the 550	What the receiver decided	Where to go
5.1.1	The mailbox does not exist. RFC 3463 calls it "Bad destination mailbox address".	Email bounced back
5.7.1 with DMARC in the text	Your own published policy told the receiver to refuse the message.	550 5.7.1 rejected per DMARC policy
5.7.23	SPF validation failed. Microsoft words it as a Sender Policy Framework violation.	550 5.7.23
5.7.26	More than one authentication check failed. Gmail prints it as 550-5.7.26.	550-5.7.26
5.7.509	Microsoft evaluated DMARC, and the message did not pass.	550 5.7.509
5.7.515	The From domain misses Microsoft's bulk-sender requirements.	550 5.7.515
No dotted code, and the text names a block	A filter refused you on reputation or content.	Message blocked if you sent from Gmail, and the sections below either way

Only the 5.7.x codes clear from your own DNS. The others need a person: the sender who typed the address, or an admin at the company that refused you.

The 5.7.2x codes come from RFC 7372. It registered a code for each failure: 5.7.20 through 5.7.22 for DKIM, 5.7.23 and 5.7.24 for SPF, 5.7.25 for reverse DNS, and 5.7.26 when more than one check failed. Every code in that family points at your DNS and your sending platform, so the recipient's admin cannot clear one for you.

550 permanent failure for one or more recipients comes from a filter

If your bounce reads like this, you are in the second group:

Your own mail system wrote the smtp; prefix when it built the notice. It is the diagnostic-type of the Diagnostic-Code field that RFC 3464 defines. The reply starts at the 550. Inside the brackets sit the two things worth reading: which recipient was refused, and the single word that says why.

Postmark's SMTP Field Manual files this exact string under Barracuda, and describes it as a message "being blocked for content or domain related reasons". I went looking for that sentence in Barracuda's own docs and could not find it. The article the Field Manual cites now returns a 404. Those docs do not confirm the wording, so act on the word after the colon.

Barracuda's blocked wording points at one customer's own list

Barracuda's knowledgebase told senders what those reason words mean. The live page 404s now, and the archived page on blocked senders still reads:

• Sender address rejected: Blocked means "either the sender's email address, or domain has been added to the Barracuda's customizable blocklist".
• Client host rejected: Blocked means "the sender's public IP address has been added to the Barracuda's customizable blocklist".
• Message content rejected, UBE means "the content of the message was recognized as spam".

Both Blocked replies point at one list, the customizable blocklist inside the appliance of the company you were writing to. An admin there added your address, your domain or your IP to it, and nobody outside that company can take it off.

The same appliance answers a global listing with a different code. Its SMTP Error Codes table puts Barracuda Reputation on a 554, not a 550:

The same table lists a second 554 for public lists: "Service unavailable; client host blocked. The final sending domain or IP address may be on a Real Time Blocklist (RBL)."

Check whether your IP is on the BRBL

The BRBL is public, and anyone can query it. Open Barracuda Central's lookup and enter the public IP of the server that sent the mail. Do not use your office IP, and do not use the domain. Read the IP out of the Received: header of a message you sent.

You can also ask DNS directly. The list answers on b.barracudacentral.org, with the IP reversed octet by octet in front of it. The zone has a test address that is always listed:

I ran that on 2026-08-20 and got 127.0.0.2 back. Then I ran the same query for an address nobody has listed:

That returned an empty answer, with an NXDOMAIN status. An empty answer means the IP is not listed. The BRBL setup instructions ask an operator to request access before filtering incoming mail with the list. Both queries above ran from a normal resolver and still answered. Check an empty answer against the web lookup before you rule a listing out.

Request removal, then fix what caused it

The removal request form has 6 fields. Its own instructions name 4 of them: your email server's IP address, your email address, a phone number, and an optional reason for removal. The form marks Reason for Removal optional. Fill it in anyway. The page says a request with a valid explanation is typically "investigated and processed within 12 hours of submission".

The same page says the list "is generated by automated systems", so "requests without valid information will be ignored". It also says "multiple requests will also be ignored", so filing the form again on Tuesday gets both requests ignored.

Write the reason as an incident report: what caused the spam, what you changed, and the date you changed it. Barracuda publishes the causes it sees, and it names 8:

• A virus on your email server that has been sending out spam.
• An email server that is set up wrong.
• Your own PC, infected with a virus or a botnet program.
• Someone else's PC on your network, infected the same way.
• A dynamic IP address that a known spammer used before you.
• Bulk mail from marketing that does not comply with the CAN-SPAM Act.
• An insecure wireless network that strangers are sending through.
• In rare cases, a misconfigured Barracuda Spam Firewall at the recipient's end.

The archived listing methodology adds one that catches small offices out. A single infected machine sending spam through a NAT gateway "can result in blocked email from the whole LAN". The same page tells anyone running several computers behind such a gateway to block outgoing port 25 traffic from every machine that is not a mail server. Do that before you file the form.

DNS records do not clear a listing

A listing is a judgement about an IP address, and your SPF, DKIM and DMARC records describe one message at a time. A perfect set of records does not take your IP off the BRBL, and a delisted IP still fails DMARC when nothing aligns.

You do both. The 5.7.x rows in the table above are the DNS half. The block rows need the removal request, plus the change in behaviour behind it. Fix the DNS, resend into the same listing, and the refusal comes back, so file the removal request the same day. A 550 is permanent, so a resend returns the same refusal and spends more of the reputation you are repairing.

A clean BRBL lookup means the block is local

The :blocked suffix then names one company's own appliance, and the admin who runs it is the only person who can clear you.

Collect the addresses that bounced from your last send and read their domains. If they all end in the same domain, one company is refusing you and everyone else is taking your mail. Reach your contact there by phone or from a different address. Ask them to send their mail admin the exact bounce text, the sending IP and the timestamp. Their admin can search the Message Log for it. When that log gives Score as the reason, Barracuda's troubleshooting page for Email Gateway Defense tells the admin what to do. They select the message and click Report as Incorrectly Blocked, which sends it to Barracuda for review.

If the bounces span several unrelated domains, every one of those receivers is judging the same sending IP or the same domain. Go back to the lookup, and check Spamhaus as well.

Free lookups for the listing and the records

Nothing here needs an account.

• Barracuda Central's lookup covers the BRBL and takes an IP or a domain.
• Spamhaus runs a free Reputation Checker for the lists most receivers weight heaviest. The two lists are built from different data, so an IP absent from the BRBL can still sit on a Spamhaus list.
• Our own SPF, DKIM and DMARC checker answers the 5.7.x half of the table above. It reads DNS, so it cannot see a blocklist.

Start with the dotted code, then the lookup

Find the dotted code. If there is one, it names your fix and the table above names the page. If there is no dotted code and the bounce carries a :blocked suffix, run the BRBL lookup before you touch a DNS record. That answer tells you which of the two you have: your own reputation, or one company's local list. This 550 is a verdict on one message to one receiver on one day.

DomainCanary is our product, and this paragraph sells it. Pro costs $19 a month for 5 domains, and it writes to you as soon as a report shows a failing source with no history on your domain. A source already in your history raises no second alert, so a familiar sender that starts failing waits for the weekly digest. Receivers already count the messages from every IP using your domain and mark which of them aligned. That summary goes to whatever address your rua= tag names, and we parse it into one email a week across the 5 domains that share an address. Those reports carry counts and verdicts, and the refusal on your screen never reaches us. Receivers do not report a blocklist listing either, which is why the lookup above stays its own job. Your first domain is free, and the alert on a source we have never seen comes with Pro.