Problem

Mail bounces with 550 5.7.1 Unable to relay, and it’s coming from a Microsoft mail server — on-premises Exchange, the built-in IIS SMTP service, or Exchange Online. The message was refused outright: the server declined to forward it. This is not a spam verdict and not a missing mailbox. It’s an authorization refusal — the server decided it isn’t allowed to carry this particular message to this particular destination.

Symptoms

  • The NDR reads 550 5.7.1 Unable to relay (Exchange/IIS) — or in Microsoft 365, 550 5.7.54 Unable to relay recipient in non-accepted domain or 550 5.7.64 TenantAttribution; Relay Access Denied.
  • A printer, scanner, copier, or line-of-business app that emails to outside recipients fails, while mail to internal mailboxes on the same server goes through.
  • A user’s Outlook or phone sends fine, but an unauthenticated device or script using the same server bounces.
  • It started after a migration, a move to a new send-from IP, a firmware update on a multifunction printer, or a switch from an old open relay to a locked-down one.
  • Sending to your own internal domain works; sending to Gmail, a customer, or any external domain gets 550 5.7.1.

What This Error Actually Means

“Relay” is what an SMTP server does when it accepts a message and forwards it toward a mailbox it doesn’t host itself. Every modern mail server refuses to relay for senders it doesn’t trust — open relays were strip-mined by spammers decades ago, so the default everywhere is now “relay for no one unless I know you.” When Exchange says 550 5.7.1 Unable to relay, it means exactly that: you asked it to deliver to a domain it isn’t responsible for, and it doesn’t consider you authorized to make that request.

The enhanced status is RFC 3463’s X.7.1, “Delivery not authorized, message refused”. The 550 basic code is a permanent rejection — retrying the identical submission from the same unauthorized sender changes nothing.

The critical distinction, and the one people miss for hours: Exchange decides relay authorization from who is connecting and how, not from the content of the mail. A message is allowed to relay to an external recipient only if the sender is authenticated, or is connecting from an IP on a Receive Connector that has been explicitly granted the “accept any recipient” permission. Miss both, and any external recipient triggers 550 5.7.1 — because to the server, an external address it isn’t hosting looks identical to a stranger asking it to launder mail to a third party.

This is the same authorization refusal as 554 5.7.1 Relay access denied on Postfix and Sendmail — same enhanced status, same root cause, just Microsoft’s wording and timing.

Top 3 Causes

  1. A device or app relays anonymously to an external recipient (the classic case). A printer, scanner, monitoring script, or CRM connects to port 25 without authenticating and tries to send to an outside domain. The default Receive Connector accepts anonymous mail only for your own accepted domains — it will take a message addressed to your internal users, but it refuses to relay to external addresses for an anonymous sender. The moment the recipient is external, you get 550 5.7.1. This is the overwhelming majority of these bounces.
  2. The sending IP isn’t scoped to a relay connector. You created (or inherited) an anonymous relay Receive Connector, but the device’s source IP isn’t inside its RemoteIPRanges, or a different connector with a broader range is matching the connection first. Exchange picks the connector by the most specific matching IP range, so an app that moved hosts, a new NAT/egress address, or a fresh VM IP can silently fall onto the wrong connector — one that doesn’t grant relay.
  3. The recipient domain should be internal but isn’t an accepted domain. After a migration or a hybrid split, mail to a domain you think you host is treated as external because it was never added as an accepted domain (or the connector routing it is gone). The server has no record that it’s responsible for that domain, so relaying to it is refused exactly like relaying to a stranger. In Microsoft 365 this is the specific 5.7.54 case.

Diagnose with DechoNet

  • Email Check on the recipient’s domain confirms whether the address is genuinely external and where its MX points. If a recipient you assumed was internal actually resolves to an outside mail host, you’ve found a missing accepted domain — the server is right to call it a relay. If it’s legitimately external, the fix is on the sending side: authentication or a scoped relay connector.
  • Email Header Analyzer reads the bounce (NDR) and tells you which host and connector refused, and at which SMTP stage. Confirm the code is 5.7.1 relay refusal — not 5.1.1 (bad mailbox), not 5.7.606/5.7.511 (IP or sender block), which look similar but have completely different fixes.
  • DNS Check shows the recipient domain’s MX records. A stale or split MX left by a migration is a common reason mail for a domain you meant to host is quietly treated as external.

Resolution Checklist

  • Confirm the direction and the recipient. Is the failing mail going to an external domain, or to one you believe you host? An Email Check on the recipient settles it — and forks everything below.
  • Anonymous device to external recipients: prefer authenticated submission. Point the device or app at port 587 with a mailbox or service-account credential and STARTTLS. An authenticated sender is allowed to relay, so no connector surgery is needed.
  • If the device can’t authenticate: create a dedicated anonymous relay Receive Connector, scope RemoteIPRanges to that device’s exact IP, set -PermissionGroups AnonymousUsers, and grant relay with Add-ADPermission ... -ExtendedRights "Ms-Exch-SMTP-Accept-Any-Recipient". Never widen the range to a whole subnet you don’t control.
  • Check that no broader Receive Connector is matching the connection first — Exchange uses the most specific RemoteIPRanges match. Two connectors overlapping an IP is a classic silent misroute.
  • Recipient should be internal: add the domain as an accepted domain (and confirm the routing/connector for it), then resend. In Microsoft 365, verify the domain in the tenant.
  • Microsoft 365 to external domains: use client SMTP submission on smtp.office365.com:587, direct send to your own domains, or a proper certificate/IP-scoped connector — pick the supported path that matches your scenario. Anonymous relay to arbitrary external recipients isn’t offered.
  • Resend after each change. 550 is permanent, so nothing clears until the sender is actually authorized.

When to Escalate

  • If the device is authenticating on 587 with valid credentials and still bounces 550 5.7.1, hand the SMTP transcript to whoever administers the Exchange org — the mailbox may be blocked from client submission, or a transport rule may be intercepting it.
  • If you don’t run the mail server (you’re relaying through a hosted Exchange or a provider), the relay authorization is theirs to grant. Give them the exact bounce and the source IP; the 550 5.7.1 and reporting host tell them precisely which connector needs your sender.
  • If a recipient domain you own is being treated as external even after adding it as accepted, the fault is likely a routing or connector misconfiguration on the server side — the SMTP transcript points your Exchange admin at it.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.