This article is a consolidation of the following previously available articles: 322358, 840468 and 924235

When you try to send or receive messages on a computer that is running Microsoft Exchange Server 2003, Microsoft Exchange 2000 Server, or MIcrosoft Windows Small Business Server 2003, you experience one of the following symptoms:

•	Exchange server does not accept Simple Mail Transfer Protocol (SMTP) messages from certain Internet domains.
•	Exchange server cannot deliver SMTP messages to certain Internet domains.

If you do a reverse Domain Name System (DNS) query, you may notice that the Exchange server that is sending the SMTP message cannot be resolved. If you take a Network Monitor trace, you may notice that there are NBT queries before the Exchange server disconnects.

The sender may receive the following non-delivery report (NDR) that contains the 5.5.0 error code. This code indicates a generic SMTP failure.
Note You may also receive the following error code: #5.5.4 Transaction failed.

Additionally, the Windows Event viewer on the Exchange server that is sending the message may contain an event 4000 or an event 4001 that is similar to the following:

Event Type: Warning
Event Source: MSExchangeTransport
Event ID: 4000
Description: Message delivery to the remote domain ' destination.com ' failed for the following reason: SMTP protocol error

Back to the top

Typically, this problem occurs if the destination SMTP server performs a reverse lookup and if one of the following conditions is true:

•	The IP address does not match the domain name that is used in the return address of the e-mail message.
•	A pointer (PTR) record does not exist or is not valid for the source SMTP server's IP address.

For example, consider the following scenario. The domain name that is used in the return address of the message is source.com. You send the message to a different domain. The destination SMTP server then performs a reverse lookup on the incoming message. If the PTR record for the source.com domain does not exist or is incorrect, the destination SMTP server does not deliver the message.

Note If your Network adapter that is connected to the Internet is using a dynamic IP address, you may have to configure Exchange Server to route mail from the source.com domain through an SMTP connector to a smart host.

Note You can configure the Exchange server to reject incoming connections by specifying a domain name on the SMTP virtual server. When this is done, reverse lookups are performed on all connection attempts. This setting is available under Connection Control on the Access tab when you right-click the SMTP virtual server and then click Properties.

Back to the top

To resolve this problem, follow these steps:

1.

Make sure that your public DNS records that are hosted on your DNS server are correct. On your DNS server, examine the following: • You must have an MX record for your domain that points to a valid Host (A) record. For example, the MX record for source.com points to mail.source.com. mail.source.com is a valid e-mail server. • Make sure that the Host (A) record points to a valid IP Address. For example, make sure that mail.source.com points to 209.54.61.76. This is the correct public IP Address for your e-mail server.

2.

For every SMTP server or Exchange Server computer that sends outgoing Internet e-mail, make sure that there is a valid PTR record for the Public IP address of that sending SMTP server or Exchange Server computer. This may be a firewall, a router, or another device that used to publish your domain information to an IP address that is visible by Internet hosts. For example, your Exchange Server computer is behind a firewall with an internal IP of 10.10.10.1, and the firewall has an external IP of 4.3.2.1. When the Exchange Server computer sends e-mail to source.comdomain through the firewall, the receiving mail server sees that the 4.3.2.1 IP address is connecting for SMTP Communication. The receiving e-mail server performs a reverse DNS lookup against this IP address, not necessarily the MX record. The e-mail server must find a PTR for 4.3.2.1 pointing to a valid host record in the source.com domain.

Back to the top

Reverse Lookup causes additional overhead on servers, but is commonly used to help prevent environments from getting unsolicited e-mail messages (spam). You can configure your SMTP server to perform reverse lookups on incoming e-mail messages. This makes sure that the IP address and the fully qualified domain name (FQDN) of the sender's e-mail message server match the sender's domain name.

The mail servers of some Internet domains require that you create a valid PTR record that points the sending server's IP address to the local SMTP domain namespace. Sometimes these mail servers require that the PTR record match the actual FQDN of their SMTP Virtual Server on Exchange. Typically, this is the MX record. These Internet domains include AOL.com, Qwest.net, Mindspring, Earthlink, and Hotmail. To send mail to these domains, create a valid PTR or a reverse lookup record on your company’s external or Internet DNS server.

If you telnet to the destination server's SMTP port and then attempt an SMTP conversation, the conversation will look similar to the following:Additionally, if you telnet to port 25 on one of the AOL MX records, the following appears:

Back to the top

This behavior is by design.

Back to the top

For more information about reverse DNS lookup for incoming messages, click the following article number to view the article in the Microsoft Knowledge Base: For more information about PTR records, click the following article numbers to view the articles in the Microsoft Knowledge Base: For more information about DNS and about reverse lookup zones, visit the following Microsoft Web site:
For more information about configuring an SMTP connector in Exchange 2000 and Exchange Server 2003, click the following article number to view the article in the Microsoft Knowledge Base: For more information about how to use port 25 to test SMTP communication, click the following article number to view the article in the Microsoft Knowledge Base: For more information about similar problems in Microsoft Exchange Server 5.5, click the following article number to view the article in the Microsoft Knowledge Base:

Back to the top