554 5.7.1: Relay access denied or client host rejected

554 5.7.1 is the form of the policy refusal that mail servers send as "transaction failed". In the wild it often reads relay access denied or client host rejected. The first means a wrong server or missing login. The second means your host is on a list or has bad DNS.

Bounce type

Hard bounce (permanent)

Usually caused on

Your sending side

Terlido report label

Blocked by the provider

What the standard says

RFC 5321 defines 554 as "transaction failed", a general permanent failure at the end of the exchange. RFC 3463 defines 5.7.1 as "Delivery not authorized, message refused". The enhanced code is the same as on the 550 5.7.1 page. Only the reply code differs, and the text after it carries the real reason.

What the mailbox providers say

• Microsoft 365 / Outlook (5.7.1): “Unable to relay” Source
• Postfix / generic (554 5.7.1): “Relay access denied”
• Postfix / generic (554 5.7.1): “Client host rejected”

Common causes

• You sent mail through a server that is not allowed to relay for you, for example because you did not log in first.
• Your SMTP settings point to the wrong server, or the port and login do not match.
• The connecting IP or hostname is on a blocklist that the receiver checks.
• The sending IP has no valid reverse DNS, or the name does not match, so the receiver rejects the host.
• A mail route that sends mail to a server that is not the right one for the recipient domain.
• A recent move from one SMTP host to another where the new host does not accept your login.

How to fix it

• Check the SMTP host, port, username and password for the mailbox and make sure authentication is on.
• Confirm that you are sending to the correct mail server for the recipient domain, using its MX records.
• Check your IP and domain against blocklists, and ask the list owner for removal if you are listed.
• Set a reverse DNS record for your sending IP that matches the name your server uses.
• Send a test message after every change to SMTP settings, and read the full reply from the server.
• If a blocklist caused the refusal, fix the underlying problem first and request removal only afterwards.

Is it a deliverability problem?

Relay denied is a setup fault on your side and is fixed by correct settings. Client host rejected points to reputation or DNS and is a real sender problem. Both stop all mail from that host, so fix them before you send more. Because these refusals affect all mail from that host and not one message, they show up fast and in large numbers. If you see many of them within a few minutes, stop the campaign and fix the host before you resume.

How Terlido handles it

When a bounce message for this code arrives in a connected mailbox, Terlido reads the status code. An enhanced code that starts with 5 is a hard bounce. In the campaign Reports tab this one is grouped as "Blocked by the provider".

On a hard bounce Terlido adds the address to the workspace blocklist with the reason "hard bounce", so no campaign emails it again. The lead stops in that campaign as bounced, its lead score goes down by 15, and the bounce counts toward the campaign's bounce rate.

Once a campaign has at least 20 sends, it pauses itself when hard bounces divided by sends goes over the campaign's maximum bounce rate. The default is 5%. If the cause was on your side and you fixed it, you can remove the entry on the Blocklist page of your account settings and try again.

Terlido treats every 5.x.x code as a hard bounce, so it blocklists the recipient even when the real cause is your own sending setup. After you fix the sending side, remove the entry from the blocklist if you want to contact that person again.

Free tools that help

• Email blocklist checkerCheck a bounded set of named public blocklists.
• Reverse DNS checkerCheck PTR and forward matching for a public IP.
• MX lookupShow a domain's mail exchanger records.

Related error codes

• 550 5.7.1: Delivery not authorized, message refused
• 550 5.7.25: Sending IP has no reverse DNS record
• 550 5.7.606: Microsoft banned the sending IP

Sources

• RFC 5321: Simple Mail Transfer Protocol (reply codes, section 4.2)
• RFC 3463: Enhanced Mail System Status Codes
• Microsoft: NDRs and SMTP errors in Exchange Online