554 5.7.1 Relay Access Denied: Bad Address or Your Setup?

A 554 5.7.1 reply, most often with the text "Relay access denied", is a permanent refusal. It means the server you reached will not pass your message along. Either it does not accept mail for the recipient's domain, or it does not accept mail from you. If the same recipient domain always returns it while other domains deliver, remove those addresses, because the domain's mail setup is probably broken. If it happens across many unrelated domains, the problem is your own sending setup, and deleting addresses will not fix it. Verification catches the first kind before you send. SimpleVerifier Pro is $39 a month with the first 100,000 checks a month at full speed, then slower, never cut off, and 100 free checks to try it.

What the code means

554 is the standard SMTP reply for "transaction failed". RFC 3463 defines the enhanced status 5.7.1 as "delivery not authorized, message refused": the sender is not allowed to send to that destination, as a result of per-host or per-recipient filtering. It is permanent only.

So 554 5.7.1 is a general-purpose refusal, and the text after the code is what tells you which one. Common texts you will see:

554 5.7.1 <name@example.com>: Relay access denied
554 5.7.1 Service unavailable; Client host [203.0.113.5] blocked
554 5.7.1 Message rejected because it appears to be spam

The three lines are three different problems, which is why this code gets confused. We have a reference page for the code at /smtp/554-5-7-1.

The three causes, and who owns each

1. Relay access denied: the domain's mail setup is wrong

An SMTP server relays a message when it accepts mail for someone else's domain and passes it on. Servers are set to do that only for their own domains, or for authenticated users. When your message reaches a server that does not host the recipient's domain, it refuses with "relay access denied".

Microsoft describes the same situation in its Exchange Online nondelivery report documentation, which we read on 10 November 2026. Its 5.7.1 "Unable to relay" entry says the sending system is not allowed to send a message to a system that is not the final destination. Its listed common causes include a third party trying to use a receiving system to send spam, and an MX record for a domain pointing to a receiving system where that domain is not accepted. In the second case the administrator of the domain has to correct the MX record.

For you as a sender, that means: the address may be real, but the domain's DNS points your mail at a server that will not take it. You cannot fix it. You can stop sending until it works and tell the contact another way.

2. Blocked by the recipient's filtering: your IP or domain

When the text says client host blocked, or mentions a blocklist, spam, or policy, the server refused you, not the address. Nothing is wrong with the recipient. See Spamhaus listings explained and how to get off a blacklist. Slow down, find the cause, and follow restarting sending after a block.

3. Your sending system needs authentication

If you send through your own SMTP server or a script, relay denied can mean your system is not authorised to relay through the server you connected to: you are sending to an outside address through a server that expects you to log in. That is a configuration fault in your setup, and it affects every message.

How to tell which one you have

Open your bounce export and check three things:

What you see	Likely cause	Action
One recipient domain, many addresses, always relay denied	Recipient domain's MX or server setup	Pause that domain, remove the rows, try another channel
Many unrelated domains, text mentions host blocked or spam	Your IP or domain reputation	Stop, find the listing, fix before resuming
Every message, including to known-good addresses	Your sending system lacks authorisation	Fix SMTP authentication in the sending setup
Only a few random addresses	Bad data	Suppress them

The bounce message analyzer reads a pasted bounce and says which side owns it, and the bounce domain hotspot finder groups bounces by recipient domain so a single broken domain stands out from a general problem.

Step by step

1. Read the full text after 554 5.7.1. Relay access denied, client host blocked and spam rejection are different fixes.
2. Group by recipient domain. If one domain accounts for the bounces, go to step 3. If not, go to step 5.
3. Look at the domain's MX records. Use the bulk MX lookup on the bounced domains. An MX that points to a host with no relation to the domain, or to nothing, explains the refusal.
4. Suppress and move on. Remove those addresses and note the domain. Do not retry: a 5xx is final. Check later whether the domain's mail has been repaired.
5. Check your own side. Look for a blocklist entry on your sending IP and domain, confirm SPF, DKIM and DMARC pass, and confirm reverse DNS matches. The email DNS error checker covers the DNS side quickly.
6. Cut the volume. If reputation is the cause, sending more makes it worse.

For the wider triage after a spike, what to do after a high bounce rate covers the first 24 hours.

Why a cold email sender sees this more

Cold lists are built from scraped and enriched company domains. Many small business domains have changed hosting, expired, or been parked, and their DNS can point at mail servers that no longer host them. Those domains tend to produce relay denied, domain not found or no-mail-server bounces in clusters. Because each bounce counts against your sending domain, a list with a lot of them can push you over a platform's bounce limit quickly. Our guide to why cold emails bounce goes through the common causes.

Prevention: check the domain and the mailbox before sending

A verifier checks the things that cause this bounce on the recipient side. It looks up the domain's mail servers, connects to them, and asks whether the server would accept mail for the address. A domain whose MX points at a server that will not accept it comes back as invalid or risky, depending on how the server answers, so you see it before you send.

What it cannot do is clear a block on your own IP or fix authentication on your own system. If your bounces say your host is blocked, verification alone will not help, and sending more mail will not either. Our post on verified emails that still bounce explains the limits honestly.

A routine that works:

• Verify the list when you build it.
• Re-verify anything older than a few months before a big send.
• Group the invalid and risky results by domain and look for patterns.
• Send risky rows in a small batch first.

Try one address with the free email checker, or paste a batch into /verify.

How SimpleVerifier fits

SimpleVerifier Pro is $39 a month. The first 100,000 checks a month run at full speed, then slower, and you are never cut off. You can try 100 free checks first, no card. See pricing.

What not to do

• Do not retry relay denied. The reply is permanent.
• Do not delete your whole list because of one cluster. Group by domain first.
• Do not switch tools to "fix" it before you know which of the three causes it is. A new sending tool will show the same refusal.
• Do not ignore it. Repeated refused sends to broken domains inflate your bounce rate for no gain.

Bottom line

554 5.7.1 is a refusal and the words after it say who owns the fix. Relay denied clustered on one domain is a recipient problem, so remove or hold those rows. A block message across many domains is your reputation, so stop and fix it. Verify lists before sending to remove the first kind, and use the bounce doctor for the rest.