SMTP error 5.7.1 Delivery not authorized, message refused

What SMTP error 5.7.1 means

Somebody decided you are not permitted to send to that recipient, and refused the message outright. It arrives as 550 5.7.1 in the overwhelming majority of cases, and on Microsoft 365 it is far more often a policy at one end or the other than a fault: a relay or connector restriction, a distribution list locked to internal senders, a blocked sender entry, or an anti-spoofing rule catching mail that claims to come from your own domain. The refusal happens inside the SMTP conversation, so the sender normally has a bounce within seconds of pressing send.

Security or policy status
Sent by The receiving mail server, or a security gateway or connector policy sitting in front of it
Common

What SMTP error 5.7.1 Delivery not authorized, message refused actually means

Taken literally the receiving side is saying this sender is not authorised to send to this destination. Not that the address is wrong, not that the mailbox is full, but that a policy said no. That policy can attach to the connecting IP address, the envelope sender, the authenticated user or the individual recipient, and the bare code does not tell you which. The separation from 5.1.1 is worth holding on to when triaging a queue of bounces: 5.1.1 means the mailbox does not exist, whilst this code means it exists perfectly well and you in particular have been refused. Where the same condition comes back as 451 5.7.1, the refusal is temporary, the sending server keeps retrying and nothing bounces until the retry window runs out. A receiver rejecting specifically on an SPF fail uses 5.7.23 instead, and one that failed several authentication checks at once uses 5.7.26, so the general code suggests the reason lay somewhere other than domain authentication.

The sender is not authorized to send to the destination. This can be the result of per-host or per-recipient filtering. This memo does not discuss the merits of any such filtering, but provides a mechanism to report such. This is useful only as a permanent error.
— RFC 3463

How 5.7.1 appears in a bounce

A server reporting this condition sends it alongside a three-digit reply code, and a bounce prints the two together. The registry lists these pairings for this status: 502 5.7.1, 503 5.7.1, 533 5.7.1, 550 5.7.1, 551 5.7.1. Which one you get depends on the point in the conversation at which the server refused. The registry also lists 451 and 454 for this condition, but those belong with 4.7.1 rather than with this code, because a reply code and the status beside it always agree on whether the failure is temporary or permanent.

The leading 5 is the server's verdict rather than part of the code's identity: it marks this as a permanent failure, which means the sending server has given up and returned the message. The same condition reported as 4.7.1 is the other verdict on the identical problem, so a log showing that form has not produced a bounce yet.

What causes SMTP error 5.7.1 on a business phone system

Relay refused for an unauthenticated device or applicationExchange Online will accept mail addressed to your own tenant from almost anywhere, but will not carry mail to an external recipient without either an authenticated session or an inbound connector that recognises the sending IP. A scanner set up to email staff works fine until the day somebody adds an external address to the address book.
A distribution list restricted to internal sendersNew Microsoft 365 groups and distribution lists default to requiring authenticated senders, which quietly means internal only. A shared address such as sales or info published on your website then rejects every external enquiry, and since the bounce goes to the enquirer nobody inside the business hears about it.
Anti-spoofing catching mail sent as your own domainA CRM, marketing platform or website contact form sending as an address at your domain, from an IP the domain does not authorise, looks exactly like impersonation. Both Microsoft 365 and Google Workspace treat unauthenticated mail claiming a domain they protect far more harshly than mail from a stranger.
A blocked sender entry at the far endThe recipient may have blocked the address themselves, or their administrator may have blocked your whole domain after a compromise at your end or theirs. Neither action generates any notification to you beyond the rejection itself.
Delivery restrictions on the individual mailboxExchange allows a mailbox to accept mail only from named senders. It is used on executive mailboxes, on internal-only notification accounts and on mailboxes that feed an automated process, and it is easy to forget it has been set.
Your sending address reputation at their gatewayMimecast, Proofpoint and Barracuda all keep their own reputation data, and a shared hosting IP or a newly registered domain starts from a poor position. This produces intermittent refusals that come and go, which is the pattern that most often gets misread as a fault.

How to fix SMTP error 5.7.1

Get the complete text of the rejectionAsk the sender to forward the non-delivery report itself rather than describe it. The useful part is the remote server response, which names the host that refused and usually the rule. Microsoft 365 reports frequently include a reference code and a link, both worth following before you theorise.
Work out which side owns the rule with two test messagesSend to the same recipient from an unrelated external account, and send from the original address to a completely different domain. If only the original pairing fails the policy is specific to the two of you; if everything from that sender fails, the problem is at your end.
Check message trace before touching any configurationMessage trace in the Exchange admin centre, or Email Log Search in Google Workspace, shows whether the message ever left, which connector carried it and what the receiving host said. That single screen resolves most of these without a change being made at all.
Give relaying devices the right submission methodFor a device that only emails colleagues, direct send to your tenant MX record needs no credentials. For one that emails externally, use authenticated submission on port 587 with its own licensed account, or a connector restricted to your fixed public IP. Choose one and document which, because mixing the two is how these faults recur.
Loosen the list restriction rather than the tenant policyWhere the fault is a public-facing distribution list, turn off the requirement for authenticated senders on that one group, or add the specific external sender to its allowed list. Do not solve it by relaxing anything tenant-wide.
Ask a human at the receiving organisationIf the block is theirs, no change at your end will shift it. Give their IT team the exact timestamp, the recipient, the sending IP address and the message identifier from the bounce. With those four things a release takes minutes; without them it takes days.

Fixing the underlying problem

This page explains the code. These guides walk through the fix in detail.

Questions about SMTP error 5.7.1

Will the sender always see a bounce, or can this fail silently?

With 550 the sender gets a non-delivery report almost immediately, because the message was refused during the conversation rather than accepted and then discarded. With 451 they hear nothing at first: it sits in a queue being retried, and only a delay notice and eventually a failure appear. The genuinely silent case is a device or application that never reports anything to a person at all.

Does this mean our domain has been blacklisted?

Sometimes, but it is not the first thing to assume. A rejection driven by a public blocklist normally names the list and gives a removal URL. A bare 5.7.1 with no list named is far more often a policy at the recipient organisation.

Why does our website contact form bounce when it emails our own staff?

The form is almost certainly sending with a From address at your domain, from your web host's IP address, which your domain does not authorise. Your own tenant then treats it as somebody impersonating you. Have the form send from an address on the hosting provider's domain and put the enquirer in Reply-To, which also stops enquiries landing in junk.

A supplier says they get this when emailing our sales address — what do we change?

Open the group in the Exchange admin centre and look at delivery management. If senders are required to be authenticated, that setting is rejecting every external message to the address. Turn it off for that group only, then send a test from an outside account to confirm.

Related SMTP status codes

Source. SMTP error 5.7.1 Delivery not authorized, message refused is defined in RFC 3463 and registered in the IANA SMTP Enhanced Status Codes registry. The causes and fixes above are drawn from our own experience supporting UK business email systems.

All Email delivery & SMTP codes