This article was initially published by Mr Roger Buck on 01 Aug 2001. As the original URL http://www.saas.nsw.edu.au/solutions/dns.html does not provide the article anymore, I temporary provide the text here.

A archive version of this article is also available here.

---

Solving DNS & Email Server Validation Problems

Is my DNS a Mess ...?       Most Probably, Yes!

---

Surveys Show that 80% of DNS Domain Name Servers are Misconfigured. Chances are high that many email messages are blocked… or possibly lost forever…. without mail administrators being any the wiser. This article shows you how to analyse and solve most DNS related MTA configuration problems Original source for this article is BIND8 for NT and other sites by Len Conrad… on how to build and configure, relay-only mail hubs for aggressive anti-spam defense with increased reliabiilty and throughput. This is just a re-hash of what you will find there.

---

How to stop DNS from Blocking Valid EMail Delivery

Until IP Version 6 becomes widely implemented, validation of email connection will (mostly) remain dependent on the current Domain Name Service (DNS).Growing popularity of Mail Tranfser Agents (MTA) such as postfix, by Wietse Venema and IBM, qmail, and sendmail is partly due to their capacity to validate any other mail servers who wish to send them mail.

Validation helps reduce the volume of Unsolicited Bulk Email (UBM or SPAM) with enhanced security, efficiency and reliability for Internet mail services in general.

Using postfix as as example, just take a look at one set of such validation options:

“Postfix Configuration – UCE Controls”

… to see how these MTA’s can really slam shut the mail door to any but the most trustworthy and identifiable mail servers.

How DNS Queries are used to Validate SMTP Clients

Take a moment to look at at this portion of an Ipswitch Imail SMTPD server log. The log shows what information is provided by the SMTP client that is trying to send email to our SMTPD server:

Figure 1:

Armed with our log information, let’s consider the validation procedures that various mail servers will run against our (and our hosted clients’) attempts to send mail?

DNS Authentication Tests Run by Email Servers:

Validating the ip address of the SMTP client:

1. Query DNS for the PTR record of ip address (reverse lookup)
2. Does the PTR record for this ip exist?
   If NO: then reject the mail.
3. Does the PTR record refer to the HELO/EHLO hostname?
   If NO: then reject the mail.
4. Does the ip address’s PTR hostname have an A record??
   If NO: then reject the mail.
5. Does the ip address’s PTR hostname have an MX record??
   If NO: then reject the mail.
6. Is the ip address in Mail-Abuse.org’s MAPS (or similar) databases of black-holes, open-relays, or dial-ups?
   If YES: then reject the mail.
7. Is the DNS reverse delegation valid and/or correct?
   If NO: then reject the mail.

Validating the HELO/EHLO hostname information:

1. Does the hostname resolve to an DNS A or MX record? [3]
   If NO: then reject the mail.
2. Is the hostname a FQHN: Fully Qualified Host Name ?
   If NO: then reject the mail.
3. If there is an A record, is that ip address in one of the MAPS databases for black-holes, open-relays, or dial-ups?
   If YES: then reject the mail.

Validating the MAIL FROM: @sender.domain information:

1. Does sender.domain resolve to a DNS A or MX record?
   If NO: then reject the mail.
2. Is sender.domain a FQHN: Fully Qualified Host Name ?
   If NO: then reject the mail.
3. If there is an A record, is the ip address listed in databases of black-holes, open-relays, or dial-ups?
   If YES: then reject the mail.

If you want to be able to validate access to your own mail server, then check out the links above. No matter what brand of mail server you use, you can implement Postfix, IMGate or similar solutions suited to your preferred operating system: Increasing the availability, speed, reliability, and overall quality of your mail infrastructure.

How to configure DNS for correct email validation

From the above, it follows that well configured mail servers will use DNS database records to validate email transfers. Correct DNS based validation reduces spam and has some important security benefits.

So, being a responsible and enthusiastic administrator, you’re asking How can I setup my DNS so that my own and my clients’ mail is reliably delivered to mail servers that use DNS validation techniques?

• Keep your server addresses out of relay databases:Assuming you are not a spammer, the most common foul-up is running your mail server as an open-relay. What’s that? Blocking databases such as Mail-Abuse.org and ORBS are designed to reduce spam.If you don’t know what anti-spam databases are about, then spend some time studying the pages at Mail-Abuse.org.To run your mail server through an an open relay test:
  From the server console of the machine you wish to test, telnet to relay-check.mail-abuse.org and watch the automated test messages roll by!

  RFC 2505: Anti-Spam Recommendations for SMTP MTAs

  RFC 1123: Requirements for Internet Hosts – Application and Support

  RFC 1912 Common DNS Operational and Configuration Errors

  RFC-Ignorant.Org registration centre

  Some more notes about standards here: Note 1 Note 2 Note 3

Make sure your DNS has been delegated with reverse authority
If your DNS is delegated with reverse zone authority, make sure your reverse zone is setup perfectly, at least for the ip addresses of your mail servers… but don’t stop there: It’s a good idea to populate your entire reverse zone with real hostnames and/generic placeholder hostnames even if they are not used.

Check your reverse zone: Is it working? Use the ip block and Scan rDNS tools at SamSpade.org. Using the rDNS tool, if you get no results, or if the results are not what you put in your db. reverse zone file, then your reverse zone is broken!

• For every domain in your DNS, make sure the zone files contain at least these records:

  $ORIGIN mydomain.com.
  @    A      ip.ad.re.ss
  @    MX     10  mailhost.domain.com.

• For every mail host (real and virtual) in your DNS, make sure the zone files contain at least these records:

  $ORIGIN somedomain.com.
  mailhost   A   ip.ad.re.ss
  @          MX  10   mailhost.somedomain.com.
  mailhost   MX  10   mailhost.somedomain.com.

• For every mail host (real and virtual) in your DNS, make sure you know how your mailserver(s) is announcing itself in the HELO/EHLO hostname field.Is your SMTP client sending mail by first announcing itself as:EHLO mail.mydomain.comorEHLO mydomain.comorEHLO smtp.mydomain.comorEHLO (nothing)orEHLO someotherdomain.com? ? ? ? ?Make sure the hostname appearing as EHLO/HELO hostname (see log example above) is entered correctly in the DNS database using:
  1. A FQHN, Fully Qualified Host Name: in the format: 111.222.123.234 IN A host.domain.com.
  2. The FQHN has a DNS A record (as per above example).
  3. The FQHN has a DNS MX record… for example:111.222.123.234 IM MX 1 host.domain.com.

For further information, check your DNS settings using dnsreport web based DNS report service

For a better understanding of any of the above terms/values, refer to the various links and log snippet in Figure 1. above. Even if you do not intend to use Postfix as your own MTA, it is worth browsing the Postfix documentation as a good reference source for many of the issues introduced here.

When your configure your DNS to meet the guidelines set out above, your DNS definitely will NOT be a mess.

Consequently, you will be able to congratulate yourself on a job well done, and your clients and mail servers will have the best chance of avoiding rejection or black-listing by other mail servers.