Re: SMTP FQDN does not match DNS resolved name

Roman B. wrote:
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.


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.
.

Relevant Pages

  • Re: Changing IP of Mail server - Any gotchas?
    ... Bob Perez made a post then I commented below ... > DNS records once I confirm ... subscriber base to prevent folks from running mail servers (among other ... I'm assuming that your mail server is behind a NAT? ...
    (microsoft.public.exchange2000.admin)
  • RE: nslookup gives round robin results
    ... Can you manually work through your records in DNS and see if there is any ... Bola - Server Infrastructure Analysts ... and DCDIAG is reporting: ... \\hostname2.domainname.local, when we were trying to reach hostname. ...
    (microsoft.public.windows.server.dns)
  • Re: Strange problem with linux samba
    ... > When I ping -c1 silvermountain ... hostname resolution is performed through standard ... services that talk to a DNS server. ... will talk to DNS to look for a DNS ...
    (comp.protocols.smb)
  • Re: can not ping hostnames of other subnet
    ... > server from the second subnet there is no incoming outgoing filter on the ... >> Anytime you are trying to ping by hostname, the name needs to be resolved ... You need to verify this name resolution is working (DNS, ...
    (microsoft.public.win2000.ras_routing)
  • Summary: Brainstorming needed: impact of changing hostname
    ... A properly configured firewall is the key defense against outside world. ... ORACLE server or a file server. ... Some applications use he hostname for licensing too. ... Note how this makes changes seamless: if I bring online a new DNS server ...
    (SunManagers)
Loading