Solved

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

Posted on 2013-06-04
2
2,026 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
2 Comments
 
LVL 63

Accepted Solution

by:
Simon Butler (Sembee) earned 500 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

Free book by J.Peter Bruzzese, Microsoft MVP

Are you using Office 365? Trying to set up email signatures but you’re struggling with transport rules and connectors? Let renowned Microsoft MVP J.Peter Bruzzese show you how in this exclusive e-book on Office 365 email signatures. Better yet, it’s free!

Join & Write a Comment

ADCs have gained traction within the last decade, largely due to increased demand for legacy load balancing appliances to handle more advanced application delivery requirements and improve application performance.
This article explains in simple steps how to renew expiring Exchange Server Internal Transport Certificate.
In this video we show how to create an Accepted Domain 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 Mail Flow >> Ac…
The basic steps you have just learned will be implemented in this video. The basic steps are shown to configure an Exchange DAG in a live working Exchange Server Environment and manage the same (Exchange Server 2010 Software is used in a Windows Ser…

708 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

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now