Things that are more note worthy than SMTPBestPractices have been moved to SMTPNotes - AdrianKitto
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 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.
Remember that not having a secondary MX doesn't mean you'll instantly lose mail if your primary is down! The sending MTA will queue the mail for some period (typically 4 hours the first time), then try again. It'll keep doing this for quite some time before finally giving up. The only downside here is that mail will be delayed.
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.
One suggested trick is to list your primary MX again as the highest number MX, so that spammers hit that one first. There is some evidence that spammers aren't actually grabbing the highest MX possible, but either blindly picking the second one, or sorting the MX list and removing dupes. Perhaps setting your primary as the first two MXs and then your secondary as the third might work. Your mileage may vary.
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.
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.
Pipelining is often used to improve SMTP performance. It allows remote MTAs to keep sending data without waiting for your server response. Spammers can make use of this by sending their entire spam in just a handful of packets then disconnecting, rather than having to wait for the entire protocol negotiation. If you disable pipelining, and your MTA checks for protocol compliance, you may find your spam load drops significantly.
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.
One page links to SMTPBestPractices:
