Indented!

One of the most common problems with outbound mail is configuration of the SMTP service name and DNS records. This post briefly covers the requirements for running a public SMTP service, it does not matter if that server is Exchange, or Sendmail, or PostFix, the same set of rules apply.

The outbound rules do not apply when using a Smart Host to send mail. The inbound rules do not apply if receiving mail through a third-party (such as an anti-spam service).

Notes:

1. The server used to send mail does not have to be the same as the server used to receive mail.
2. Outbound SMTP servers do not have to appear in an MX record, those are for inbound mail only.
3. If the outbound server is not the same as the inbound server there is no way to dynamically find the outbound server outside of the network. The majority of sites that check SMTP configuration assume that the inbound and outbound servers are the same.

Host (A) record – inbound and outbound mail

If a server needs to accept inbound mail it must have a name created in a public DNS service. The record must point to the public IP address your mail server will use for receiving (and / or sending) mail, in most cases that IP address is set on a Firewall or Router.

For example:

mail.highorbit.co.uk.   IN A   1.2.3.4
smtp.highorbit.co.uk.   IN A   1.2.3.4

Mail Exchanger (MX) record – inbound mail

To accept inbound mail an MX Record should be created for the SMTP domain. The MX record must point to the record created above. MX Records must point to a Host (A) record to be RFC complaint, no Alias (CNAME) records and no IP addresses.

MX Records are written in the form:

email-domain  IN MX   priority   server

For example, this MX record will accept mail bound for anyrecipient@somedomain.example and pass it onto mail.somedomain.example.

somedomain.example.   IN MX   10   mail.somedomain.example.

Pointer (PTR) record – outbound mail

The reverse lookup zone maps IP Addresses back to names using Pointer (PTR) records. This forms the basis of a simple test to see if an SMTP server looks real rather than a virus / malware ridden machine sending spam.

If a server is sending out mail to hosts on the internet (that is, not relaying through a third-party service) it must have a PTR record configured. Failure to do so will cause mail to be rejected by many recipient systems.

The PTR record is generally be requested via an ISP; those responsible for providing the internet connection the mail server uses. The rare exception to this is where responsibility for the Reverse Lookup Zone has been delegated elsewhere.

The PTR record for mail.somedomain.example running on the public IP 1.2.3.4 would look like this:

4.3.2.1.in-addr.arpa.   IN PTR   mail.somedomain.example.

Many ISPs will understand a request for a Reverse Lookup Record for 1.2.3.4 to mail.somedomain.example. That is, it is not necessary to know the exact syntax above.

Responsibility for the Classful reverse lookup zone can be seen using NSLookup as follows:

nslookup -q=ns 3.2.1.in-addr.arpa.

Or using Dig it is possible to trace responsibility for the record with:

dig 4.3.2.1.in-addr.arpa ptr +trace

SMTP service name – outbound mail

If the server is sending out mail it must use a public name in HELO / EHLO. Failure to correctly set the name will cause some mail to fail as the server name does not match the Host (A) record or the Pointer (PTR) record.

For Exchange 2007 the name is set in the Properties for the Send Connector. It is possible to set the name for the Receive Connector as well however this will have no impact on mail delivery. It may be considered good practice to set a public name on the Receive Connector for the sake of consistency.

For Exchange 2000 and 2003 the name is set in the Properties for the Virtual SMTP Server (Delivery, Advanced, Server FQDN).

Sender Policy Framework (SPF / TXT) record – outbound mail

This record is not required for a functional SMTP server. However, it can reduce abuse of a domain name and is worth considering for that.

The Sender Policy Framework allows you to state explicitly which servers can send mail as a domain name.

While this is not universally used it will help reduce abuse of a domain name by third-parties and also reduce the number of non-delivery reports returned to a system for mail with spoofed addresses.

Wizards to help create a record can be found here:

www.openspf.org
www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/

The record would be added as a TXT record to a public domain. It is only checked by systems receiving mail.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.