550 permanent failure: the receiver refused your message for good

A receiving server refused your message for good, and 550 is the class of reply that says so. The code turns up in a bare 550 with a dotted code beside it, and in the Barracuda sentence 550 permanent failure for one or more recipients. Read your dotted code first, because the table below matches each one to its fix, and the Barracuda sentence has its own section further down.

Will your server retry a 550? No. Something has to change before you resend.

Permanent and temporary codes

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. Our Email bounced back page shows how to sort any bounce, including the 4xx side.

Dotted codes

Most receivers print a second, dotted code beside the 550. The 550 gives the class of reply, and the dotted code says which rule refused the message. Copy the whole reply out of the bounce before you close the notice. Then find your dotted code in the table below.

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	The receiver refused the message because your own published DMARC policy says to.	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 mentions a block	A filter refused you on reputation or content.	Message blocked if you sent from Gmail, and the sections below either way

You can clear only the 5.7.x codes by fixing your own DNS. The others need a person, either 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

If your bounce reads like this, a filter refused it:

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 you'll find the recipient who 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 replies

Barracuda explained those reason words in its knowledgebase. The live page now returns a 404. 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 refer to 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.

When your IP is on Barracuda's global list, the same appliance replies with a 554. Its SMTP Error Codes table gives this reply for Barracuda Reputation:

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)."

The BRBL lookup

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 20 Aug 2026 and got 127.0.0.2 back. Then I ran the same query for an unlisted address:

That returned an empty answer, with an NXDOMAIN status. An empty answer means the IP is not listed. In its BRBL setup instructions, Barracuda asks an operator to request access before filtering incoming mail with the list. I ran both queries above from a normal resolver and still got answers. Check an empty answer against the web lookup before you rule a listing out.

BRBL removal requests

The instructions on the removal request form ask for your email server's IP address, your email address, a phone number and a 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 a second time 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:

• 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 a cause that affects small offices. A single infected machine sending spam through a NAT gateway "can result in blocked email from the whole LAN". The same page says anyone running several computers behind such a gateway should block outgoing port 25 traffic from every machine that is not a mail server. Do that before you file the form.

SPF, DKIM and DMARC

A listing is a judgment 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.

Check for both problems. For the 5.7.x codes in the table above, fix your DNS. For a block, file the removal request and change whatever caused the spam. If you fix the DNS and resend while your IP is still listed, the refusal comes back, so file the removal request the same day. Each resend returns the same refusal and spends more of the reputation you are repairing.

A clean BRBL lookup

When the lookup comes back clean, the :blocked suffix comes from one company's own appliance, and only the admin who runs it 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 checks

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 checks the records behind the 5.7.x codes in the table above. It reads DNS only, so it doesn't check blocklists.

Where to start

Find the dotted code. If there is one, the table above links the page with your fix. If there is no dotted code and the bounce carries a :blocked suffix, run the BRBL lookup before you touch a DNS record. The lookup shows whether the problem is your own reputation or one company's local list.

DomainCanary watches for the next one. The Starter plan costs $19 a month for 3 domains. On it, we email you as soon as a report shows a failing source with no history on your domain. We also email you the day a source that had been passing starts failing. 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 lists, and we turn it into one email a week. Those reports carry counts and verdicts, and the refusal on your screen never reaches us. Receivers do not report a blocklist listing either, so run the lookup above yourself. Your first domain is free, and the alert on a source we have never seen comes with the Starter plan.