SMTP FQDN does not match DNS resolved name

I'm running a SBS 2003 server, and I get the message below when I run the
microsoft exchange troubleshooting assistant software. anyone know how I can
fix this.


The fully-qualified domain name of SMTP virtual server 'Default SMTP Virtual
Server' on server srv1 does not match the DNS resolved server name. This may
cause mail routing problems. SMTP virtual server: mycompany.org. DNS resolved
server name: srv1.mycompany.local.


Thanks
Roman

 

No, you don't fix it and you don't pay too much attention to the
Exchange troubleshooter, which is assuming that the Exchange
installation is that of a large organisation, which manages its own
public DNS service.

Best practice, as stated by Microsoft, is for the SBS domain to have a
name which is invalid on the Internet ('local' may have to be re-thought
soon, as custom TLDs seem to be on the way). The FQDN of the SBS SMTP
virtual server can be set to anything, but whatever it is must be able
to be resolved to a real non-private IP address using public DNS, the
address you send mail from. These two conditions mean that a
properly-configured SBS hostname can never match the SMTP FQDN. Don't
worry about it.

What you need to worry about is that the FQDN resolves to the IP address
you send mail from, if you're sending mail by DNS, and it's good
practice even if you're sending by smarthost (as you can temporarily
switch to DNS to test things). It usually simplifies things if it also
matches you domain's MX record, as the corresponding A record already
exists. Finally you need to ensure that the reverse DNS of your IP
address, the PTR record, can also be resolved by public DNS back to the
IP address. If the PTR matches your MX and/or SMTP FQDN, so much the
better, as it is alleged that some receiving mail servers check for this.

If you're sending email by smarthost and collecting by POP3, none of
this matters, but presumably then you wouldn't be running the Exchange
troubleshooter.

 

Joe,

I have a reverse DNS lookup with our ISP, which points our public ISP IP
address to mail.mycompany.com.
Question: When you talk about an A record. Are you talking Reverse Lookup
Zone in my DNS on my server? Sorry I'm a little confused. Right now my DNS
FORWARD and Reverse Lookup Zones contain A records that point to private IP
addresses.

Thanks in advance for your help. I very much appreciate it.

Roman

 

No, that's the reason for using an invalid domain name for the SBS. The
SBS DNS server is completely isolated from the outside world in terms of
its stored records, at least after a default installation. It is not
accessible publicly, and you don't normally need to make any changes to
it. Neither its hostnames nor its private IP addresses are visible to
the outside world.

All the DNS records needed for mail delivery and transmission will be
held in public DNS servers. The PTR record, also known as reverse DNS,
is in your ISP's reverse lookup zone for his IP address range. When
properly set up (and some ISPs are difficult about this) it will contain
a hostname which will appear in the forward lookup zone of (usually)
someone else's DNS server, which handles your public domain name. There
will be one or more A records, normal forward DNS records, and one or
more MX records for mail servers. There may be other kinds, but only
these two matter for email.

MX records contain hostnames, and there may be more than one for a
domain. They have a number associated with them, and numbered MX records
are tried in ascending order until a mail server replies, this is how
secondary or backup mail servers are specified. The A records are for
hostnames, and contain IP addresses. So each MX record must contain a
hostname, which must appear somewhere in the world as an A record, which
leads to an IP address. The PTR record for this address must contain a
hostname which has an A record which points back to the IP address.
Since more than one A record can exist for one IP address, then the
PTR/A pair of records do not need to refer to the same hostname as the
MX record (mine don't), but they often do.

To receive email by SMTP, you need an MX record and its associated A
record, both in the DNS server of your domain host. Typically the MX
hostname will be mail.domain.com, but it doesn't need to be. The A
record points to your public IP address. The domain host will either
configure these records on request, or to save itself the trouble, will
offer you a web page where you configure them.

To send mail by SMTP, it's a little more complicated, and depends on the
configuration of the server you're trying to send to. There are a few
rules that most mail servers seem to require senders to comply with, to
try to reduce the amount of spam sent to them. Almost all mail servers
now will want:

-The PTR record for your IP address to be a real hostname, which can be
looked up in public DNS as an A record.

-The A record to point back to your IP address.

-Your mail server's FQDN string (sent in the HELO or EHLO of an SMTP
transaction) to be a real hostname which has an A record in public DNS.

-This A record to also point back to your IP address.

As you can see, the simplest way to achieve this is to make up a
hostname for your mail server, such as mail.domain.com, and create an A
record for this at your domain host, leading to your IP address. You can
then set the domain MX record, the ISP's PTR record and the Exchange
FQDN to this hostname and all of these criteria will be satisfied. This
is a common configuration, so much so that some mail servers are alleged
to require it before accepting mail.

Now to the Exchange troubleshooter: if you were to use public IP
addresses on the servers within your network, and host your own public
DNS server, you would set your internal domain name to be same as the
public domain name. Your Exchange server would then really have the
hostname which the MX and other records would point to, and the
troubleshooter would be happy.

If you don't have multiple public IP addresses and host the public DNS
yourself, it is not advisable to use the public domain name internally,
as reaching external resources which use your domain name becomes messy.
Microsoft specifically advises against it with SBS. Therefore the
Exchange troubleshooter is never going to be happy about SBS, at least
in this respect.