?
Solved

Exhange 2007 - FQDN not correct in SMTP greeting, does not match reverse DNS (PTR) record

Posted on 2013-06-04
2
Medium Priority
?
2,135 Views
Last Modified: 2013-06-25
Windows Server 2008
Exchange 2007, SP3
Server Name = Exchange

I have an ISP suddenly rejecting our email.  They have said we are not sending the correct response in our SMTP greeting.  We've had no other large or small ISP's block our email.

We are replying to HELO with the name "exchange.domain.local".  Our MX record points to mail.domain.com

It seems I need to modify a Hub Transport setting to show the <.com> not <.local> FQDN.

I'm wondering about the details and what's the better approach.

- Is it best to not offer any details in an SMTP greeting.
- Where does the change need to be made?  I tested making some changes, but nothing worked.  

I have one Exchange 2007 server with Mailbox, Client Access and Hub Transport roles.

Adding a wrinkle is - we use Google Postini for inbound email filtering inbound, but we send directly outbound.

Using DNSStuff.com for testing.
----------
Internally, I telnet to the Exchange server, port 25.

HELO
250    exchange.domain.local     HELLO   [10.#.#.#]
-----------
external telnet is blocked by firewall rules
Ping mail.domain.com replies with the correct IP 209.#.#.#
-----------
from MX Toolbox

SMTP Reverse DNS Mismatch       Warning - Reverse DNS does not match SMTP Banner
-----------
DNSStuff - SMTP Greeting test, for my-address@domain.com,

Test Status:  WARNING: The hostname in the SMTP greeting does not match the reverse DNS (PTR) record for your mail server. This probably won't cause any harm, but may be a technical violation of RFC5321
----------
In Exchange
- Organizational Config - Hub Transport - Send Connectors - Exchange Internet (enabled)
     "Specify the FQDN..." is blank
- Server Config - Hub Transport
     - Client Exchange
     - Default Exchange
Both show "Specify FQDN..." as exchange.domain.local

What I tested:
- I first changed the send connector, adding mail.domain.com and restarted the MS Exchange Transport server
- Tested from DNSStuff site, got same .local result
- Second, reset send connector to null, set Client Exchange FQDN to mail.domain.com, restart transport service, tested, still get warning

Do I need to wait for my local change to update externally?  I didn't want to leave a potentially incorrect setting, then leave it overnight if it broke email processing.

I looked at MS help in Exchange and it said to NOT change the default server FQDN or I'd screw up internal email.

Any help or advise is much appreciated

Thanks - Dale
0
Comment
Question by:agradmin
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
2 Comments
 
LVL 63

Accepted Solution

by:
Simon Butler (Sembee) earned 1500 total points
ID: 39220672
If you use one of the testing sites you will get invalid results.
This is because Exchange has two sets of FQDNs, one for inbound email and one for outbound email. The testing sites can only see the inbound email and will "presume" that it is the same for outbound email, which is not the case.
Having the local name on inbound email will not affect email delivery. The FQDN for inbound email is set on the Receive Connectors, but the only supported values are the server's real FQDN (what you have now), the server's NETBIOS name or blank. An external FQDN is not valid.

For sending email, the usual advice is to set the FQDN on the Send Connector to match your PTR and have the PTR set as the same value as your MX record, with matching A record.
However as you use Postini, you will need to have a valid A record and PTR combination that doesn't match your MX record.

If you continue to have problems then look at using Postini for outbound email as well.

Simon.
0
 

Author Closing Comment

by:agradmin
ID: 39276242
While trying to figure out the solution (and a vacation interruption), the issue seems to have cleared with the recipient ISP (a small vendor).  I had no problems emailing any other ISP big or small.

I never made any changes but things worked after a two to three week gap.

Thanks for some useful info that still may come into use at a later time.
0

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

If you troubleshoot Outlook for clients, you may want to know a bit more about the OST file before doing your next job. IMAP can cause a lot of drama if removed in the accounts without backing up.
New style of hardware planning for Microsoft Exchange server.
To show how to generate a certificate request in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.:  First we need to log into the Exchange Admin Center. Navigate to the Servers >> Certificates…
The video tutorial explains the basics of the Exchange server Database Availability groups. The components of this video include: 1. Automatic Failover 2. Failover Clustering 3. Active Manager
Suggested Courses
Course of the Month12 days, 15 hours left to enroll

777 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question