'You do not have permission to send to this recipient' error

The most common scenario in which I've seen this particular error is when companies are using a Cisco PIX firewall with xxxx configured. If you have a PIX, you'll want to ensure that the Mailguard feature is set according to the following Microsoft Knowledge Base article 320027: Cannot send or receive email messages behind a Cisco PIX firewall.

MEMBER FEEDBACK TO THIS ASK THE EXPERT Q&A:

I have this exact same problem, a specific few users get:

mail@somedomain.com on 08/03/2006 11:20
               You do not have permission to send to this recipient.
               For assistance, contact your system administrator.
               MSEXCH:MSExchangeIS:/DC=local/DC=domainname:servername
 
and
 
martin@somedomain.com on 08/03/2006 09:36 
               You do not have permission to send to this recipient.
               For assistance, contact your system administrator.
                for myipaddress>

We do not have a complicated setup. We have one server running Small Business Server 2003 Premium Edition. I have spent hours looking at this issue and have found nothing to solve it.

Are my users authenticating? Why can't they send through my server?
—F.T.

******************************************

Unfortunately 5.7.1 errors are, as you're finding out, one of the more troublesome errors to resolve. Given that you don't have a PIX, here are some other things to check:

1. Launch Exchange System Manager (ESM) and navigate to the SMTP virtual server you are using to send messages to the Internet. View Properties -> Access -> Relay and ensure that the "Allow computers which successfully authenticate to relay" checkbox is not checked.
2. Troll through the application event log on your Exchange server for errors from source MSExchangeTransport around the time of the non-delivery report (specifically look for Event ID 1709 or 1710 or any errors/warnings from MSExchangeTransport).
3. Temporarily enable maximum diagnostics logging on MSExchangTransport, the Queuing Engine, and the Connection Manager for the server hosting a problematic user. Then have this user send a message to an address that typically sends non-delivery reports (NDRs) with a 5.7.1 error. Turn diagnostics logging back off, and troll the application event log on the Exchange server in question for errors or warnings specific to the message in question. (Tip: search the description field of the events for the Message-ID of the particular message). If you find specific errors or warnings, look those up on TechNet or write back if you need help resolving things further.
4. Check whether 5.7.1 NDRs are happening for all messages sent from any user within your organization to a specific internet SMTP domain, or whether these errors seem specific to a given sender. If the former is the case, then you may want to contact the email administrator for the target SMTP domain (i.e., send an email to postmaster@<company.com>) asking them to confirm that their MX records are pointing to the appropriate SMTP gateway .(You can actually test this by looking up the target domain's public DNS record and attempting to telnet to port 25 of any MX records listed in the DNS record. I described how to send test messages via telnet in "How to troubleshoot problems receiving external email." The receiving server may actually send you a more specific error message through SMTP commands in response to telnet than you're getting in the NDR.

Needless to say, there are many possibilities. Let us know how this works, and please write back with more details if these steps don't resolve the issues.
—David Sengupta, Server Administration Expert

******************************************

In response to item #1 (keeping the "Allow computers which successfully authenticate to relay" checkbox unchecked), it has been my understanding that you want this checked to block relaying from anyone outside of your network. Would this be correct?
—Ron Z.

******************************************

If this is of sufficient concern for you, my only other suggestion is to escalate to Microsoft PSS. There are too many possibilities for me to give a definitive response above and beyond what I have suggested in the two responses here.
—David Sengupta, Server Administration Expert

******************************************

We just received this error message today. As you suggest in your response, the error normally appears when there is a restriction -- either when relaying restrictions are set on the default SMTP virtual server in ESM, or on a network device that prevents SMTP traffic from reaching its destination.

Our Exchange environment consists of several Active Directory domains and multiple Administrative Groups (over 30 and growing). The problem was triggered when an organizational unit (OU) administrator moved his two Exchange servers from one OU to another. The OU administrator does not have write access to the Exchange Domain Servers security group, so when the distinguished name (DN) was updated in Active Directory, the DN in the security group remained the same.

The problem was resolved when we removed the two Exchange servers from the security group, allowed intrasite replication to take place, and re-added them back in.
—Ted O.

******************************************

This should resolve the problem: How to send emails with Microsoft Exchange using a different From address.
—JB P.

Do you have comments on this Ask the Expert Q&A? Let us know.

Related information from SearchExchange.com: