This article describes the following:
- How to troubleshoot mail relay issues in Exchange Server 2003 and in Exchange 2000 Server
- How to prevent your Exchange computer from being used as an open mail relay
- How to set up SMTP domains for incoming mail and relay mail in Exchange
Exchange provides full Simple Mail Transfer Protocol (SMTP) mail services. The Exchange SMTP server can be used to receive mail and to relay mail to other Exchange computers on your network or to other SMTP servers on the Internet. Mail relay permits Exchange mail clients to send mail to users in other organizations. If mail relay is not permitted, the Exchange computer can only receive and send mail for users who are in the same mail domain as the Exchange computer.
When it relays mail, the Exchange computer can forward mail that is addressed to mail domains other than its own domain. This behavior lets Exchange forward mail to any internal or external network SMTP server.
You must be careful when Internet users can access your Exchange computer. This is because your Exchange computer may be used as a mail relay by unscrupulous users. These users may forward mail to your Exchange SMTP server to distribute unsolicited commercial mail, also known as spam, to many computers. This could have an adverse effect on the available bandwidth for your Internet connection. Additionally, it could lead to your Exchange computer being added to "black hole" lists of open mail relays. If your Exchange computer is added to such a list, other mail servers might not accept mail from your domain.
Symptoms of mail relay issues
One or more of the following symptoms can occur when you experience mail relay issues.
Click here to expand or collapse the list
- You receive non-delivery reports (NDRs) that contain error code 5.0.0, 5.7.1, or 5.7.3.
- You can't send mail to an increasing number of domains.
- Unsolicited commercial email appears in your mail queues, and you detect that your Exchange computer sends unsolicited commercial email.
- A remote domain informs you that it receives unsolicited commercial email from your Exchange computer.
- One or more of the following events is logged in the Application log:
Event Type: Warning
Event Source: MSExchangeTransport
Event Category: SMTP Protocol
Event ID: 1709
Computer: Computer_Name
Description: An SMTP client did not authenticate before attempting to send mail. Access was denied. Data: 0000: 05 00 07 80 ...?
Event Type: Warning
Event Source: MSExchangeTransport
Event Category: SMTP Protocol
Event ID: 1710
Computer: Computer_Name
Description: An SMTP client authenticated as user "NT AUTHORITY\ANONYMOUS LOGON" attempted to send as " User.one @ domain.edu ". Access was denied because the authenticated client does not have permission to Send As this SMTP address. Data: 0000: 05 00 07 80 ...?
Event Type: Error
Event Source: MSExchangeTransport
Event Category: SMTP Protocol
Event ID: 7004
Date: Date
Time: Time
User: N/A
Computer: Computer_Name
Description:
The description for Event ID ( 7004 ) in Source ( MSExchangeTransport ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: 1, 1, from, helo, 571 from IP Address We do not relay from you. ,HELO Domain_Name.com You will find mail stuck in the Remote Delivery queue to a remote domain, and the event log does not give you any details on the remote domain name. If you telnet to the remote domain on port 25, you will find that the connection is dropped immediately with the same error in the above event log entry: 571 from IP Address We do not relay from you.
Date: Date
Source: MSExchangeTransport
Time: Time
Category: (3)
Type: Warning
Event ID: 4001
User: N/A
Computer: Computer_Name
Description:
Message delivery to the remote domain 'Mail.Example.Com' failed. The error message is 'An SMTP protocol error occurred'. , MAIL, 553 5.3.0 Mail from ip address refused, see http://mail-abuse.org/rbl+/lookup.cgi? ip address Data: 0000: d7 02 04 c0
Date: Date
Source: MSExchangeTransport
Time: Time
Category: (3)
Type: Warning
Event ID: 4001
User: N/A
Computer: Computer_Name
Description: Message delivery to the remote domain 'Mail.Example.Com' failed. The error message is 'An SMTP protocol error occurred'. , MAIL, 550 Mail from dial-up rejected; see http://mail-abuse.org/dul/enduser.htm or contact Example helpdesk at. Data: 0000: d7 02 04 c0
Date: Date
Source: MSExchangeTransport
Time: Time
Category: (3)
Type: Warning
Event ID: 4001
User: N/A
Computer: Computer_Name
Description:
Message delivery to the remote domain 'Mail.Example.Com' failed. The error message is 'An SMTP protocol error occurred'. , MAIL, 550 5.7.1 Mail from Ip_Address refused by blackhole site dialups.mail-abuse.org. Data: 0000: d7 02 04 c0
Date: Date
Source: MSExchangeTransport
Time: Time
Category: (3)
Type: Warning
Event ID: 4001
User: N/A
Computer: Computer_Name
Description:
Message delivery to the remote domain 'Mail.Example.Com' failed. The error message is 'An SMTP protocol error occurred'. , RCPT, 554 Service unavailable; [Ip_Address] blocked using dialups.mail-abuse.org. Data: 0000: d7 02 04 c0
Possible causes of NDRs that contain error code 5.0.0, 5.7.1, or 5.7.3
Click here to expand or collapse the list
Error code 5.0.0 or 5.7.1 can occur if the following condition is true:
- Your Exchange computer is listed as a messaging server that sends unsolicited commercial email.
Error code 5.7.1 can occur if one or more of the following conditions is true:
- The sender of the message does not have the privileges that are required to
complete delivery.
- You try to relay your mail by using a second server, and the second server does not
let you relay mail. The remote server returns a 5.7.1 error code.
- You do not have a recipient policy configured for the domain
to which the message is sent.
- The recipient has mailbox delivery restrictions enabled. For example, the recipient's mailbox delivery restriction is configured to receive mail only from a specified list. Other mail is rejected.
- A distribution list is configured to restrict mail delivery to messages from authenticated
users. Mail that is sent from an anonymous session is rejected.
- Your Exchange computer is on an unsolicited commercial email list. Your Exchange computer may be listed as an open relay.
- The fully qualified domain name (FQDN) of your Exchange computer ends with ".Local".
- A Microsoft Windows NT 4.0 or Windows 2000 Domain Name System (DNS) server receives a non-authoritative response from a root hint or forwarder. Then, the Windows NT 4.0 server or Windows 2000 DNS server sends a server failure back to the mail server that queried for a domain that has not been configured with a Mail Exchange (MX) record. This behavior occurs when the Windows NT 4.0 server or Windows 2000 DNS server receives a start of authority (SOA) record from a non-authoritative resource. Newer BIND versions cache empty-authoritative responses. Windows DNS servers consider empty-authoritative responses to be referrals. When Windows DNS servers receive these responses, the responses are disregarded. Additionally, the client receives a server failure instead of an SOA record.
- The DS2MB metabase key is corrupted.
- The Allow all computers which successfully authenticate to relay, regardless of the list above check box is not selected on the SMTP virtual server.
- Anonymous access to the SMTP virtual servers is disabled.
Error code 5.7.3 can occur if the one of following conditions is true:
- Anonymous authentication is not permitted by the destination server.
- The destination server cannot find the intended recipient.
Error code 5.7.1 or 5.7.3 can occur if one of the following conditions is true:
- The DNS feature is configured incorrectly.
- Users have email addresses that do not match any one of the existing recipient policies. Typically, proxy addresses should match at least one recipient policy.
- You use Microsoft ISA Server 2000, and one of the following conditions is true:
- The external IP address of the ISA server is changed.
- The IP address of the SMTP publishing rule is updated to reflect the new external IP address of the ISA server.
- The Isactrl service is not restarted after the IP address of the SMTP publishing rule is updated.
Possible causes of events 1701, 1709, 1710, 4001, and 7004
Click here to expand or collapse the list
Event 1701, 1709, 1710, 4001, or 7004 is logged in the Application log when one of the following conditions is true:
- Events 1709 and 1710 occur when an NDR that contains error code 5.7.1 is generated by your Exchange computer.
- Event 1701 occurs when an NDR that contains error code 5.7.3 is received by your Exchange computer.
- Events 7004 and 4001 occur if other mail servers list your Exchange computer as a messaging server that sends unsolicited commercial email or if your Exchange computer is an open mail relay.
If your Exchange computer is configured as an open mail relay that sends unsolicited commercial email
If other mail servers list your Exchange computer as a messaging server that sends unsolicited commercial email, you may experience one or more of the following symptoms:
- You cannot send mail to an increasing number of domains.
- Unsolicited commercial email appears in your mail queues, and you detect that your Exchange computer sends unsolicited commercial email.
- A remote domain informs you that it receives unsolicited commercial email from your Exchange computer.
- You receive NDRs that contain error code 5.0.0 or 5.7.1.
- Events 7004 and 4001 are logged in the Application log.
This issue can occur if your Exchange computer is configured as an open mail relay. Alternatively, this issue can occur if an account on your Exchange computer has been compromised and is being used as a mail relay.
To resolve this issue, click here to expand or collapse the steps
- Verify that your Exchange computer is not an open mail relay. To do this, follow these steps:
- Click Start, point to Programs, point to Microsoft Exchange, and then click System Manager.
- In Exchange System Manager, expand the following object:
Servers\Your_Exchange_Server_Name\Protocols\SMTP
- Right-click the virtual SMTP server where you want to prevent mail relay, and then click Properties.
- Click the Access tab, and then click Relay.
- By default, open relay is blocked. The default settings are as follows:
- The Only the list below check box is selected.
- The Allow all computers which successfully authenticate to relay, regardless of the list above check box is selected.
- If you must permit a single computer, a group of computers, or a domain to relay through the server, click Add. In the Computer dialog box, click the appropriate selection for the computers that you want to relay through the server. Then, type the required information.
Note
Enabling access by IP address or by domain name is helpful for users who do not authenticate with the Exchange computer. - In the Relay Restrictions dialog box, click OK.
- Click Apply, and then click OK in the Default SMTP Virtual Server Properties dialog box.
If your Exchange computer continues to relay messages to external domains, your Exchange computer has an SMTP connector that allows for relay.
For more information about how to prevent relay through an SMTP connector, click the following article number to view the article in the Microsoft Knowledge Base:
314734
Relay restrictions on default virtual SMTP server are not working
- To determine whether your Exchange computer is on an unsolicited commercial email list, visit the following website:
Microsoft provides third-party contact information to help you find technical support. This contact information may change without notice. Microsoft does not guarantee the accuracy of this third-party contact information.
- Determine whether your Exchange computer is on an AOL unsolicited commercial email list. If you determine that your Exchange computer is listed on an AOL unsolicited commercial email list, remove your Exchange computer from the list. For information about how to do this, visit the following AOL website:
- Determine whether your Exchange computer is on the Mail-Abuse.org list of organizations that send unsolicited commercial email. To do this, follow these steps:
- Visit the following website:
- On the MAPS lookup page, type the publicly accessible IP address of your Exchange computer, and then press Enter.
Note MAPS stands for Mail Abuse Prevention System.
- Remove your Exchange computer from the Mail-Abuse.org list. To do this, follow these steps:
- Visit the following website:
- Type the publicly accessible IP address of your Exchange computer in the You can search this index. Type the keywords you want to search for box, and then press Enter.
- Follow any other instructions to complete the removal of your Exchange computer from the list.
- Remove your Exchange computer from any open relay block list that is not covered by Mail-Abuse.org. OpenRBL.org maintains a query engine that links to over 35 open relay block lists. Each list maintains a separate list of open relay mail servers. Therefore, your Exchange computer may appear on some, but not all, lists.
- Visit the following website, and then query on your Exchange computer's IP address or FQDN:
- If your Exchange computer is on any one of the open relay block lists, you receive a link to that specific list provider's website.
- The website for that list provider typically provides instructions about how to remove your Exchange computer from that list.
Note Follow the list-removal process for every list that includes your Exchange computer. When you remove your Exchange computer from one list, your Exchange computer may not be removed from all lists.
If your Exchange computer is not listed on any real-time block lists, you may have to contact the mail server administrator for the remote domain to which you cannot send mail. Then, request that your Exchange computer be manually removed from the administrator's block list. Not all administrators use real-time block lists. Some administrators maintain their own lists. You must contact these administrators directly.
If mail relay occurs from an account on an Exchange computer that is not configured as an open mail relay
Determine whether an account on your Exchange computer sends authenticated relayed mail.
To do this, click here to expand or collapse the steps
- Click Start, point to Programs, point to Microsoft Exchange, and then click System Manager.
- In Exchange System Manager, right-click Your_Exchange_Server_Name, and then click Properties.
- Click the Diagnostic Logging tab.
- In the Services list, click MSExchange Transport.
- In the Categories list, click Authentication, and then click Maximum in the Logging level area.
- Click Apply, click OK, and then exit Exchange System Manager.
- Click Start, point to Programs, point to Administrative Tools, and then click Services.
- Right-click Simple Mail Transport Protocol (SMTP), and then click Restart.
- Click Start, point to Programs, point to Administrative Tools, and then click Event Viewer.
- In Event Viewer, search the Application log for event 1708. Event 1708 indicates that the account authenticates with the Exchange computer to send relayed mail.
Prevent an account from authenticating with the Exchange computer to send relayed mail.
To do this, click here to expand or collapse the steps�
- Click Start, point to Programs, point to Microsoft Exchange, and then click System Manager.
- In Exchange System Manager, expand the following object:
Servers\Your_Exchange_Server_Name\Protocols\SMTP
- Right-click Default SMTP Virtual Server, and then click Properties.
- Click the Access tab, and then click Relay.
- Depending on your environment, complete one of the following procedures:
- If a POP3 client does not have to relay mail, clear the Allow all computers which successfully authenticate to relay regardless of the list above check box. Change the password and the name of the account that is used for mail relay.
- If specific clients or servers must relay mail, add them to the list in the Relay Restrictions dialog box.
How to set up SMTP domains for incoming mail and for relay mail
You may want to accept mail for one or more of the following classes of Internet SMTP domains:
- Domains that are local to your Exchange organization
- Domains that are not local to your Exchange organization
- Domains that are shared between your Exchange organization and another SMTP server
Domains that are local to your Exchange organization
To accept mail from domains that are local to your Exchange organization, create a recipient policy that includes an address that is similar to the following:
SMTP:@Domain.Domain_Root
For more information about how to create a recipient policy, click the following article number to view the article in the Microsoft Knowledge Base:
249299
How to configure recipient policies in Exchange
Domains that are not local to your Exchange organization
To accept mail from domains that are not local to your Exchange organization, create an SMTP connector.
For more information about how to configure an SMTP connector, click the following article number to view the article in the Microsoft Knowledge Base:
265293
How to configure the SMTP connector in Exchange 200x
Domains that are shared between your Exchange organization and another SMTP server
To accept mail from domains that are shared between your Exchange organization and another SMTP server, set up an SMTP connector. To do this, follow the steps in the "Domains that are not local to your Exchange organization" section. However, when you add the domain to your recipient policies so that your users can receive mail from the address, clear the
This Exchange Organization is responsible for all mail delivery to this address check box.
For more information about how to share SMTP domains together with another mail system, click the following article number to view the article in the Microsoft Knowledge Base:
321721
How to share an SMTP address spaces in Exchange 2000 Server or in Exchange Server 2003
How to troubleshoot NDRs that contain error code 5.7.1 or 5.7.3
Error codes 5.7.1 and 5.7.3 and Application log events 1709, 1710, or 1701 occur under various conditions. The following scenarios describe these conditions and explain how to resolve the respective NDRs and Application log events.
Note NDRs that contain error code 5.7.1 may contain the following message:
�The originator does not have permission to submit message.�
This message can be misleading because it implies that the sender has a permissions problem. However, the actual reason for this NDR is that the remote domain has prohibited the domain that is sending the mail from relaying the mail.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
262354
Misleading NDR when sending to remote domain that does not allow relay
Scenario 1: Authenticated computers are not allowed to relay mail
If the
Allow all computers which successfully authenticate to relay regardless of the list above check box is not selected on the SMTP virtual server, you may receive NDRs that contain error code 5.7.1. To select the
Allow all computers which successfully authenticate to relay regardless of the list above�check box, follow these steps.
Click here to expand or collapse the steps
- Click Start, point to Programs, point to Microsoft Exchange, and then click System Manager.
- In Exchange System Manager, expand the following object:
Servers\Your_Exchange_Server_Name\Protocols\SMTP
- Right-click the SMTP virtual server object, and then click Properties.
- Click the Access tab, and then click Relay. Select the Allow all computers which successfully authenticate to relay regardless of the list above check box.
Scenario 2: Anonymous access to SMTP virtual servers is disabled
If the
Anonymous access check box is not selected, you may receive NDRs that contain error code 5.7.1. To select the
Anonymous access�check box, follow these steps.
Click here to expand or collapse the steps
- Click Start, point to Programs, point to Microsoft Exchange, and then click System Manager.
- In Exchange System Manager, expand the following object:
Servers\Your_Exchange_Server_Name\Protocols\SMTP
- Right-click the SMTP virtual server object, and then click Properties.
- Click the Access tab, and then click Authentication.
- Click to select the Anonymous access check box.
- Click OK two times.
- Right-click the SMTP virtual server, and then click Stop.
- Right-click the SMTP virtual server, and then click Start.
- Click Start, point to Programs, point to Administrative Tools, and then click Services.
- Right-click Simple Mail Transport Protocol (SMTP), and then click Restart.
- Right-click Microsoft Exchange Routing Engine, and then click Restart.
Scenario 3: The DNS feature is configured incorrectly
If the DNS feature is configured incorrectly, you may receive NDRs that contain error code 5.7.1 or 5.7.3. Additionally, event 1701, 1709, or 1710 may be logged in the Application log. To troubleshoot the DNS configuration, make sure that mail exchanger (MX) records point to the correct SMTP virtual server. If the DNS feature is configured incorrectly, incoming SMTP connection attempts may randomly connect to the wrong SMTP virtual server.
Scenario 4: There is no matching recipient policy for proxy addresses
If users in an organization have email addresses that do not match any of the existing recipient policies in the organization, senders who send mail to these users may receive NDRs that contain error code 5.7.1 or 5.7.3. Additionally, event 1707, 1709, or 1710 may be logged in the Application log. Typically, the proxy addresses of users in the organization should match at least one recipient policy in the organization.
Note The term "proxy addresses" refers to the SMTP domains that are local to the organization.
For more information about how to create new recipient policies or how to update existing recipient policies, click the following article number to view the article in the Microsoft Knowledge Base:
319065
How to work with the Exchange Recipient Update Service
Scenario 5: The destination server requires additional authentication
If anonymous authentication is not permitted by the destination server, you may receive NDRs that contain error code 5.7.3. Make sure that the sending client or the sending server can authenticate to the destination server.
Note Error code 5.7.3 can also occur when the destination server cannot find the intended recipient.
Scenario 6: The ISA Server 2000 SMTP publishing rule is not updated
If you use ISA Server 2000, and the SMTP publishing rule is not updated, you may receive NDRs that contain error code 5.7.1 or 5.7.3. Additionally event 1701, 1709, or 1710 may be logged in the Application log. This issue occurs if you use ISA Server 2000 and one of the following conditions is true:
- The external IP address of the ISA server is changed.
- The IP address of the SMTP publishing rule is not updated to reflect the new external IP address of the ISA server.
- The Isactrl service is not restarted after the IP address of the SMTP publishing rule is updated.