SMTP error code · permanent failure (5xx)
SMTP error 554 5.7.1: message refused or relay access denied
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 16, 2026
554 5.7.1 is a permanent policy rejection: the receiving server refused your message, most often because your sending IP is on a blocklist, your sender reputation is poor, or a relay rule doesn't recognize you. It will not retry on its own. Find the blocklist named in the bounce, fix the root cause, delist, and re-send.
554 5.7.1 at a glance | |
|---|---|
| Code | 554 5.7.1 |
| Class | Permanent (5xx): the message was refused and will not retry |
| Category | Policy |
| Side at fault | Sender |
| Auth-related | Yes (SPF/DKIM/DMARC) |
What the bounce actually says
The exact wording varies by provider. These are the documented strings, verbatim. Match yours to pin down which variant you hit.
Generic MTA — DNSBL rejection (Spamhaus, Postfix-style)
554 5.7.1 Service unavailable; Client host [11.22.33.44] blocked using sbl-xbl.spamhaus.orgSource: github.com
Microsoft 365 (Exchange Online Protection) — IP on Microsoft's blocklist
554 5.7.1 5.7.1 Service unavailable; Client host [xxx.xxx.xxx.xxx] blocked using Blocklist 1; To request removal from this list please forward this message to delist@microsoft.comSource: learn.microsoft.com
Postfix — default relay refusal
554 5.7.1 554 5.7.1 <user@domain.com>: Relay access deniedSource: access.redhat.com
RFC 3463 — standard meaning of enhanced status 5.7.1
554 5.7.1 Delivery not authorized, message refused — The sender is not authorized to send to the destination. This can be the result of per-host or per-recipient filtering.Source: www.rfc-editor.org
Why you're seeing 554 5.7.1
554 5.7.1 pairs RFC 5321's catch-all rejection (554, transaction failed) with enhanced status 5.7.1, "delivery not authorized, message refused" (RFC 3463). In practice it means policy stopped your mail: the connecting IP is on a DNS blocklist, the message tripped a spam or reputation filter, or the server refused to relay it at all. The words after the code tell you which one you hit: a named blocklist means an IP-reputation problem, Relay access denied means an SMTP routing or authentication problem, and a bare policy refusal means the receiver's filters scored the message as unwanted. The same 5.7.1 status also arrives prefixed 550 5.7.1 from Gmail and Microsoft 365, so treat the two as one family and read the text, not the prefix.
Likely causes, ranked
| Likely cause | What's happening |
|---|---|
| Your sending IP is on a DNS blocklist | The most common trigger, and the bounce usually names the list: `zen.spamhaus.org` on Postfix-style servers, "Blocklist 1" in Microsoft 365 NDRs. Once the IP is listed, every message it sends to servers that use that list is refused until it's delisted. |
| Poor IP or domain reputation tripped the spam filter | No named list, just a policy verdict. The receiver's own filtering scored the message as unwanted: spam-like content, a sudden volume spike, high complaint rates, or a history of failed authentication from your domain or IP. |
| Relay access denied: the server won't forward your mail | Postfix's default wording for this code. Either you're sending through a server unauthenticated (or on port 25 instead of the authenticated submission port), a device or app points at the wrong outbound server, or, on the receiving side, the destination domain is missing from the server's accepted or relay domain configuration. |
| A compromised mailbox or device got the IP listed | Blocklists list IPs because spam actually left them. A hacked mailbox, an infected machine, or an open relay on your network sends the spam; the `554 5.7.1` bounces on your legitimate mail are the symptom. Delisting without finding the leak just gets you relisted. |
| Missing SPF, DKIM, or DMARC is dragging reputation down | Unauthenticated mail scores worse with every reputation system feeding these policy verdicts, and a domain without DMARC enforcement can be freely spoofed: spammers burn its reputation and the legitimate owner collects the bounces. |
| Recipient-side restrictions | In Microsoft 365 the same 5.7.1 family covers restricted distribution groups, public folders that require authenticated senders, and mail flow rules. That's configuration on the recipient's side, not your reputation; the NDR text names the restricted group or folder when this is the case. |
How to fix 554 5.7.1
Check your sending IP against the major blocklists
Take the sending server's IP from the bounce (or from the Received headers of a sent message) and run it through the free blocklist checker below. If the bounce already names a list, this confirms the listing and shows any other lists you're on that haven't bounced mail yet.
Run the check now
Enter the sending domain and the check runs instantly on the next page. Free, no signup.
Read the words after the code
The text after
554 5.7.1picks your path: a named blocklist means delisting work,Relay access deniedmeans an SMTP routing or authentication fix, and a generic spam or policy verdict means reputation work. Don't request delisting for a relay error; it won't help.Find and fix the root cause before requesting delisting
Check for a compromised mailbox, an infected device, an open relay, or a purchased list before you ask for removal; delisting without fixing the leak means relisting within days. Then follow the removal path in the bounce itself: Spamhaus links its lookup and removal page, and Microsoft asks you to forward the NDR to delist@microsoft.com.
Fix relay errors with authenticated submission
If the bounce says
Relay access denied, point the sending device or app at your provider's submission endpoint on port 587 with a username and password, not anonymous port 25. If it's your own inbound server rejecting mail addressed to your domain, add the domain to its accepted or relay domain configuration.Check how reputation systems score your domain and IP
Run the sending domain through the free domain reputation checker at /tools/domain-reputation and the IP through /tools/ip-reputation. Reputation-only blocks (no named list) recover gradually as clean, authenticated mail replaces whatever triggered the verdict.
Authenticate the domain, then re-send
Publish SPF and DKIM for every service sending as your domain and verify the DMARC record at /tools/dmarc. Authenticated mail protects the reputation you just repaired. Because 554 is permanent, nothing retries on its own: once the listing clears, re-send whatever bounced.
Related free tools: IP reputation checker · Domain reputation checker · DMARC checker
Authentication is the fix, not a workaround
Every path out of 554 5.7.1 runs through the same three DNS records: SPF, DKIM, and DMARC. Mailbox providers no longer treat them as best practice; they're the entry ticket, and a domain that drifts out of alignment starts bouncing again without anyone changing a thing on your side.
The durable fix is enforcement: publish correct records, watch the DMARC reports for senders you missed, and move the domain to p=reject so receivers drop spoofed mail instead of bouncing yours.
Enforce it — don't just monitor it
Palisade's AI agent takes domains all the way to enforcement: hosted SPF, DKIM, DMARC, and MTA-STS records, DMARC reports monitored continuously, and policies advanced to p=reject automatically. Your first domain is free, and the full product is open for 15 days, no card.
Free 15-day trial · No credit card · Your own domain free forever (NFR)
Why it matters for MSPs
A blocklisted IP rarely hurts just one mailbox. When a client's firewall relay, scan-to-email copier, or line-of-business server lands on a blocklist, every domain sending through that IP starts bouncing with 554 5.7.1, and if the trigger was a compromised mailbox, the next listing is a matter of time. Palisade covers the prevention side across a fleet: it hosts and manages SPF, DKIM, and DMARC for every client domain, and its AI agent drives each one to p=reject, so spoofed mail can't burn a client's reputation while you work the delisting queue. The DMARC reports double as a map of every IP legitimately sending as each domain: exactly the list of tenant systems to check when a listing hits. It plugs into ConnectWise, HaloPSA, and Autotask, the first domain is free, and your own MSP domain runs as a free NFR domain so you can prove it on yourself first.