Exchange mail flow guides › Authentication and SMTP errors

“550 5.7.1 Unable to relay” when a connector submits to Exchange: accepted domains and receive connector permissions

Exchange answers 550 5.7.1 Unable to relay when an SMTP session without relay permission names a recipient whose domain is not an accepted domain of the Exchange organization. For a POP3/IMAP connector that delivers provider mail to your own mailboxes the fix is almost always the missing accepted domain, not a change to the connector software and not relay permission; relay permission on a receive connector is only needed for a host that must send through Exchange to recipients outside your domains.

Updated on 2026-09-28

The Exchange behaviour on this page is taken from Microsoft Learn, where it is documented for Exchange Server 2016, 2019 and Subscription Edition; the connector side is taken from the POPcon knowledge base, whose article on this error covers Exchange 2003 to 2016. The reply is one row in our table of Exchange SMTP error codes; this page is the long version of that row.

What Exchange checks before it answers “Unable to relay”

Every SMTP session arrives on a receive connector, and the receive connector gives the session a set of permissions. Microsoft’s description of the one that matters here (Receive connectors in Exchange Server): ms-Exch-SMTP-Accept-Any-Recipient “allows SMTP clients or servers to relay messages through the Receive connector. If this permission isn’t granted, only messages that are sent to recipients in accepted domains that are configured for the Exchange organization are accepted by the Receive connector.”

So the reply depends on two things only: which permissions the session has, and whether the recipient’s domain is an accepted domain.

Session	Permissions the session receives (per Microsoft)	Recipient in an accepted domain	Recipient in any other domain
Anonymous — permission group Anonymous users	ms-Exch-Accept-Headers-Routing, ms-Exch-SMTP-Accept-Any-Sender, ms-Exch-SMTP-Accept-Authoritative-Domain-Sender, ms-Exch-SMTP-Submit — no relay permission	Accepted	550 5.7.1 Unable to relay
Anonymous, on a dedicated connector where the relay permission was added for NT AUTHORITY\ANONYMOUS LOGON	The four above plus ms-Exch-SMTP-Accept-Any-Recipient	Accepted	Accepted and relayed
Externally secured — permission group Exchange servers with the authentication mechanism Externally secured	Includes ms-Exch-SMTP-Accept-Any-Recipient, and also ms-Exch-Bypass-Anti-Spam and ms-Exch-Bypass-Message-Size-Limit	Accepted	Accepted and relayed

The default connector for inbound mail, Default Frontend <ServerName>, listens on TCP port 25 for all IPv4 and IPv6 addresses and carries the permission group Anonymous users out of the box; Microsoft calls it “the common messaging entry point into your Exchange organization”. That is the first row of the table: mail for your accepted domains is taken, everything else is refused. It is the behaviour you want from a server that is reachable on port 25.

Case 1: the connector delivers mail for your own mailboxes

A POP3/IMAP connector such as POPcon downloads the messages from the provider mailboxes and hands them to Exchange over standard unauthenticated SMTP, the same way an internet mail server would. The recipients are your own users. If Exchange refuses them with 550 5.7.1 Unable to relay, Exchange does not regard their domain as its own. In the words of our knowledge base article “550 5.7.1 Unable to relay” error from Exchange: the internet domain has not been added to the list of accepted domains, and Exchange rejects delivery for any domain it does not own.

This happens most often on a freshly installed server. When the first Exchange Mailbox server is installed, the fully qualified domain name of the Active Directory forest root domain is configured as the authoritative domain (Accepted domains in Exchange Server). If the forest is called company.local and the mailboxes at the provider are @company.com, the internet domain is simply not on the list yet.

1. Read the rejected recipient from the log. For POPcon the file is POPconSrv.log in the program directory. Note the domain part of the address Exchange refused.
2. Compare it with the accepted domains. In the Exchange admin center open Mail flow › Accepted domains, or run the command Microsoft gives for the check: Get-AcceptedDomain | Format-Table -Auto Name,DomainName,DomainType,Default,AddressBookEnabled.
3. Add the domain as an authoritative domain. Click Add, enter a descriptive name and the domain, and select Authoritative. In the Exchange Management Shell: New-AcceptedDomain -Name "Company internet domain" -DomainName company.com — the domain type defaults to Authoritative (Procedures for accepted domains). An accepted domain is either a single domain or a domain with subdomains (*.company.com); according to Microsoft the value cannot be changed from one form to the other afterwards. On Exchange 2003 the equivalent is the Default Policy under Recipients › Recipient Policies.
4. Check the connector’s own domain list. POPcon has a field Accepted Recipient Domains in its POP3/IMAP configuration. With a catch-all mailbox it uses this list to decide which recipients are local; the knowledge base explains why the connector needs the accepted domains. Enter the domain without the @ sign — company.com, not @company.com (details).
5. Deliver the rejected messages again. POPcon has moved them to its BADMAIL folder. Move the .msg files into the PICKUP subfolder and they are delivered in the next retrieval cycle (how to resend them).

Nothing in these steps touches the permissions of the receive connector, and nothing needs to: the session is anonymous, the recipient is now in an accepted domain, and that combination is accepted. The complete setup, with the receive connector settings a connector does need (anonymous users, message size), is in How to download POP3 and IMAP mailboxes into Exchange and, with screenshots, in the Exchange 2013 / 2016 configuration guide.

Which receive connector is answering?

If the domain is on the list and the reply does not go away, make sure the session lands on the connector you think it does. Several receive connectors can listen on port 25 of the same server. Exchange picks the one whose remote IP address range is the most specific match for the connecting host; Microsoft’s example has one connector for 192.168.1.0-192.168.1.255 and one for 192.168.1.75, and a connection from 192.168.1.75 is accepted by the second. A connector created years ago for a scanner or a fax service with a narrow range that happens to include the connector’s machine takes the sessions away from the Default Frontend connector — with whatever permission groups it was given.

List what is there with the properties Microsoft uses for the same check: Get-ReceiveConnector | Format-List Name,Enabled,TransportRole,Bindings,RemoteIPRanges,PermissionGroups. In the Exchange admin center the ranges are on the Scoping tab of each connector under Mail flow › Receive connectors, the permission groups on the Security tab.

Case 2: a host really has to relay to external recipients

A different situation produces the same reply: a device or application on your network — Microsoft names web servers, database servers, monitoring applications and other network devices — submits mail to Exchange that is addressed to recipients on the internet. Here the accepted domains cannot help, because the recipient domains are not yours. The host needs the relay permission, and Microsoft’s procedure (Allow anonymous relay on Exchange servers) is strict about where it goes:

• Create a dedicated receive connector. Microsoft: “Don’t attempt to add anonymous relay capability to the default Receive connectors that are created by Exchange.”
• Create it in the Front End Transport service (role Frontend Transport, type Custom), bound to port 25.
• Under Remote network settings remove the entry 0.0.0.0-255.255.255.255 and enter only the IP addresses of the hosts that may relay. Microsoft’s advice is to err on the side of being too specific.

In the shell the same connector is created with New-ReceiveConnector -Name "Anonymous Relay" -TransportRole FrontendTransport -Custom -Bindings 0.0.0.0:25 -RemoteIpRanges 192.168.5.10,192.168.5.11. Then the permission is granted in one of two ways — one or the other, not both:

Method	How it is configured	What Exchange treats the host as	Consequences named by Microsoft
Anonymous with relay permission	Exchange Management Shell only: Set-ReceiveConnector "Anonymous Relay" -PermissionGroups AnonymousUsers, then Get-ReceiveConnector "Anonymous Relay" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "Ms-Exch-SMTP-Accept-Any-Recipient"	An anonymous sender	Grants the minimum required permissions; messages do not bypass antispam or message size limit checks; the sender address is not resolved to a display name in the global address list
Externally secured	Exchange admin center, Security tab: authentication Externally secured, permission group Exchange servers; or Set-ReceiveConnector "Anonymous Relay" -AuthMechanism ExternalAuthoritative -PermissionGroups ExchangeServers	An authenticated, completely trusted sender	Easier to configure; messages bypass antispam and message size limit checks; the host can submit messages as if they originated from internal senders

A POP3/IMAP connector that only delivers inbound mail belongs to case 1 and does not need such a connector. The knowledge base shows how to have individual addresses forwarded to a mailbox on the internet with a mail contact in Exchange, which leaves the forwarding to Exchange itself.

Testing the receive connector by hand

Microsoft’s test for the relay connector works for case 1 as well, and it shows the reply at the exact command that triggers it. From the machine the connector runs on, open a command prompt with the Telnet client installed:

1. telnet, then OPEN <Exchange server IP> 25
2. EHLO
3. MAIL FROM:sender@example.org
4. RCPT TO:user@company.com

The answer to RCPT TO is the result: 250 2.1.5 Recipient OK means Exchange accepts that recipient from this host, 550 5.7.1 Unable to relay means it does not. Repeat the command with a recipient in each of your domains; a domain that is refused is a domain missing from the accepted domains. QUIT ends the session without sending anything.

Replies that look similar and are not

Reply	What is different	Where the fix is
550 5.7.1 Unable to relay	The recipient’s domain is not an accepted domain and the session has no relay permission	Accepted domains (case 1) or a dedicated relay connector (case 2)
530 5.7.1 Client was not authenticated	The receive connector accepts only authenticated sessions; the recipient has not been looked at yet	Tick Anonymous users on the receive connector (article)
550 5.5.1 user unknown	The domain is accepted, but no recipient has that address	Assign the address in Active Directory (article)
503 5.5.2 need Rcpt command	Every recipient of the message was refused before, so no recipient was left when the message body was announced	Look at the reply to the recipient one line earlier in the log (article)

Frequently asked questions

More in the Exchange mail flow guides, on the POPcon product page, the POPcon download page or in the knowledge base. Auf Deutsch: 550 5.7.1 Unable to relay bei der Übergabe an Exchange.