Penguin
Note: You are viewing an old revision of this page. View the current version.

Things that are more note worthy than SMTPBestPractices have been moved to SMTPNotes - AdrianKitto

DNS Issues

Try not to put your mail server in what people might consider a "dynamic IP" range. It is reasonably common to drop mail coming from IP blocks that are known to be allocated to dynamic sessions such as dialup and DSL connections. If you have an MTA operating in these ranges, be prepared for a fair chunk of the Internet to drop mail from you instantly.

Your MX ResourceRecord MUST point to a DNS name which has an A or AAAA record. Do NOT set an MX to point to an IP address! Do NOT set it to point to a DNS name which is a CNAME either. For example, mail to foo@fishbowl.example.com will not work if fishbowl.example.com is a CNAME to some other machine. MXes must point to a name with an A or AAAA ResourceRecord. Not a CNAME, not anything else.

Make sure that the reverse lookup of your outgoing mailserver exists, make sure has a matching forward record, and where possible, make sure that your HELO / EHLO name matches the reverse. Note, that this usually doesn't match the name of the domain you want to recieve mail for.

Don't use an underscore "_" in your domain name for mail, in your HELO / EHLO or 250 server greeting. Mail will get dropped.

Make sure you send mail from a domain that exists, and has at least an A or AAAA or an MX ResourceRecord. If you use an internal mail domain that doesn't actually exist, and mail from this internal domain somehow gets onto the InterNet, you will lose mail.

Use http://dnsreport.com/ to verify that your DNS is in good healthy working order.

Attempt to publish a SPF record for your domain.

Secondary MXs

Secondary MXs have fallen out of favour in recent years as the InterNet is more reliable and there are techniques for keeping your primary up (such as load balancing NATs). Having a secondary MX is good if your connectivity is unreliable but a pain otherwise.

Be aware that spammers regularly send to secondary MXs directly to avoid aggressive RBL checks on the primary MailServer. This can be exploited by having a secondary MX that always returns a 400 series code (temporary failure), or is stricter with its RBL checks. Another trick is to list your primary MX again as the highest number MX so that spammers hit that one first.

Regularly check that your backup MX still correctly relays. You won't notice a backup MX rejecting mail until the first time your primary goes down and all your mail is immediately bounced rather than retried later.

Administrative mail accounts

Make sure you have a postmaster@ and abuse@ Email addresses that have the least number of filters (Spam, Virus, etc) on them. People may try to send you mail to notify you that your machine is broken and explain how you can fix it, but if you treat all mail from their machine as invalid, you'll never hear about the problem.

Misc

Try to run an IDENT server on your mail server. Several mail servers still try to check IDENT by default. If you don't have IDENT enabled, then make sure you don't just drop packets to the IDENT port, or you will cause other MailServers to wait for a time out before they let you send any Email, slowing everything down.


CategoryBestPractices