SMTP error code · permanent failure (5xx)
SMTP error 550 5.7.1: delivery not authorized, message refused
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 17, 2026
550 5.7.1 is the catch-all "delivery not authorized" rejection: the receiving server deliberately refused your message. The bounce text tells you which variant you hit: failed SPF/DKIM/DMARC authentication, a relay the server won't perform, a blocklisted sending IP, or a recipient-side restriction. It's permanent; fix the cause the text names, then re-send.
550 5.7.1 at a glance | |
|---|---|
| Code | 550 5.7.1 |
| Class | Permanent (5xx): the message was refused and will not retry |
| Category | Policy |
| Side at fault | Either side |
| 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.
Gmail (Google Workspace) — sender or recipient policy
550 5.7.1 The user or domain that you are sending to (or from) has a policy that prohibits the email that you sent.Source: knowledge.workspace.google.com
Gmail (Google Workspace) — unauthorized direct sending
550 5.7.1 The IP you're using to send email is not authorized to send email directly to our servers.Source: knowledge.workspace.google.com
Gmail (Google Workspace) — low IP reputation
550 5.7.1 This message is likely suspicious due to the very low reputation of the sending IP address.Source: knowledge.workspace.google.com
Microsoft 365 (Exchange Online) — recipient requires authenticated senders
550 5.7.1 RESOLVER.RST.AuthRequired; authentication required [Stage: CreateMessage]Source: learn.microsoft.com
Microsoft 365 (Exchange Online) — sending IP on Microsoft's blocklist
550 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
Microsoft 365 (Exchange Online) — blocklisted IP hidden by the customer's IP Allow list
550 5.7.1 Unable To Relay: Blocked by Customer Allow listSource: learn.microsoft.com
Exchange Server (on-premises) — relay not allowed for this sender
550 5.7.1 Unable to relaySource: learn.microsoft.com
Generic MTAs — the RFC 3463 standard text
550 5.7.1 Delivery not authorized, message refusedSource: www.rfc-editor.org
Why you're seeing 550 5.7.1
5.7.1 is the broadest security code in the SMTP standard. RFC 3463 defines it as "delivery not authorized, message refused" (the sender is not authorized to send to this destination) and deliberately says nothing about why. So every provider reuses it for its own refusals: Gmail returns it for admin-policy and IP-reputation refusals, Exchange Online for denied relays, blocklisted IPs, and recipients that only accept authenticated senders, and countless MTAs for per-host or per-recipient filtering. That's why the number alone can't be diagnosed. The human-readable text after 550 5.7.1 is the actual verdict. Match it against the variants above, then work the fix that matches. The one constant: some policy on the receiving side judged your message unauthorized, and it will keep doing so until something changes.
Likely causes, ranked
| Likely cause | What's happening |
|---|---|
| The message failed SPF, DKIM, or DMARC | A common trigger. Generic MTAs and third-party gateways often return a bare `550 5.7.1` for authentication failures: a sending service missing from your SPF record, or DKIM signing left off, is enough to make your mail look unauthorized. Gmail and Microsoft 365 use more specific codes for DMARC rejections (`550 5.7.26` and `550 5.7.509`, both in the related codes below), and Gmail's 5.7.1 "policy that prohibits" variant signals a Workspace admin or organization policy, not DMARC. |
| You're relaying through a server that won't relay for you | The classic Exchange wording. A printer, scanner, or line-of-business app submits mail through a server that doesn't recognize it as an authenticated or internal sender, so the server refuses to pass the message on. Common right after migrations, IP changes, or password rotations. |
| The sending IP is on a blocklist | Exchange Online's blocklist variant and Gmail's low-reputation variant both fit here. So does Exchange's "Blocked by Customer Allow list" NDR, despite the relay wording: the tenant's own IP Allow list hides the blocklist's name. The receiving side checked your connecting IP against a real-time blocklist or its own reputation data and refused the connection outright; nothing about this specific message mattered. |
| The recipient's organization restricts who can send to that address | Restricted distribution groups, mail-enabled public folders that require authenticated senders, moderated recipients, and per-recipient allow-lists all bounce outsiders with 5.7.1. Your mail and your DNS are fine: the restriction lives entirely on their side. |
| You're sending directly to the provider from an unauthorized IP | Gmail refuses direct SMTP connections from IPs it considers unfit to send, typically dynamic or consumer ranges, or IPv6 senders without matching PTR records. Mail must go out through a proper mail server or smarthost instead. |
| A mail flow rule or content filter refused the message | Microsoft 365 transport rules and third-party gateways commonly reject with a 5.7.1 when a message trips an org-level rule: attachment types, keywords, geo restrictions. The bounce usually carries the custom text the admin configured. |
How to fix 550 5.7.1
Check the sending domain's DMARC, SPF, and DKIM first
Authentication failures are a common trigger and the only variant you can fully fix in DNS. Run the domain from the bounced message's From address through the free DMARC checker below. It shows what your SPF, DKIM, and DMARC records currently tell receivers, and whether your own policy could be ordering the rejection.
Run the check now
Enter the sending domain and the check runs instantly on the next page. Free, no signup.
Match your bounce text to a variant
The number is ambiguous; the sentence after it is not. Relay wording means a submission problem, blocklist wording means a reputation problem, a named group or folder means a recipient-side restriction. The exact string decides which of the next steps applies.
Fix authentication: SPF includes and DKIM signing
Add every service that sends as your domain to your SPF record and verify it with the free SPF checker at /tools/spf, staying under the 10-DNS-lookup limit. Enable DKIM signing for your domain (not the provider's default) at each service. If your DMARC policy is
p=reject, any legitimate source you missed will bounce exactly like this.If it says relay: authenticate the submission
This step is for the classic "Unable to relay" or "not authorized to relay" wording, but not "Blocked by Customer Allow list", which is a blocklist problem (next step). Stop submitting anonymously: point the device or app at authenticated SMTP submission (SMTP AUTH on port 587 with a real account) or set up a connector scoped to its IP address. A mail server only relays for senders it can identify, and this error means it couldn't identify yours.
If it names a blocklist: check your IP and domain reputation
Run the connecting IP through /tools/ip-reputation and the domain through /tools/domain-reputation, then check public blocklists with /tools/blocklist-checker. Microsoft's own variant tells you where to send the delisting request; public RBLs each have their own removal process. If the bounce says "Blocked by Customer Allow list", your own settings are hiding the culprit: remove the sending IP from the IP Allow list under connection filtering in the Exchange admin center, and the NDR will name the actual blocklist. Then delist. Fix the leak (open relay, compromised account, spam burst) before requesting removal, or you'll be relisted.
If only one recipient bounces: ask their admin, then re-send
A single failing address while everything else delivers points at a recipient-side restriction only their email admin can lift. Once the cause is fixed, whichever it was, re-send the message yourself: 550 is a permanent failure, so nothing retries automatically.
Related free tools: SPF checker · Domain reputation · Blocklist checker
Authentication is the fix, not a workaround
Every path out of 550 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
550 5.7.1 is the most ambiguous ticket in an MSP queue: the same code covers a client's scan-to-email copier that lost relay rights, a tenant whose SPF never listed the new CRM, and a mail server that landed on a blocklist over the weekend. Triaging it bounce-by-bounce across fifty client domains doesn't scale. But the biggest slice, the authentication variant, is preventable fleet-wide. Palisade hosts and manages the SPF, DKIM, DMARC, and MTA-STS records for every client domain, watches the DMARC reports so unauthenticated senders surface before they start bouncing, and advances each domain to p=reject automatically. It plugs into ConnectWise, HaloPSA, and Autotask so the fix lands in your existing workflow, and your own MSP domain is a free NFR domain you can prove it on first.