Solved

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

Posted on 2013-06-04
2
2,077 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

PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

Question has a verified solution.

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

Scam emails are a huge burden for many businesses. Spotting one is not always easy. Follow our tips to identify if an email you receive is a scam.
This article explains how to install and use the NTBackup utility that comes with Windows Server.
In this video we show how to create an email address policy 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…
A short tutorial showing how to set up an email signature in Outlook on the Web (previously known as OWA). For free email signatures designs, visit https://www.mail-signatures.com/articles/signature-templates/?sts=6651 If you want to manage em…

809 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