Sending email servers best practice

Technical

If you run an outbound SMTP email server, then there's a number of things you should be doing to ensure smooth sending of your email. All of the things below are fairly straightforward recommendations that are either specified by RFCs or as general best practice.

  1. **Ensure your forward and reverse DNS match -  **

    Also called Forward Confirmed Reverse
    DNS
    ,
    having valid and matching forward and reverse DNS is one of the
    first recommendations in RFC
    1912
     ("Make sure
    your PTR and A records match"). It's a sign that the system
    administrator understands at least the basic
    RFCs. It also
    helps to avoid spoofing of your systems by spammers.

    You need to ensure that the IP address you are testing is the "edge"
    one that your email server connects to other servers with. In most
    cases this is obvious, but you might have a machine with multiple IP
    addresses, or you might be behind some sort of
    NAT
    system, in which case the apparent IP address will be the NAT router
    IP address, so make sure you are testing the right IP address.

    There's a tool to test that your forward and reverse DNS match
    here. Or you can do
    it easily via Linux command line tools. For instance, here's the
    forward & reverse DNS for one of our outgoing hosts.

    $ dig +short out1.smtp.messagingengine.com
    66.111.4.25
    $ dig +short -x 66.111.4.25
    out1.smtp.messagingengine.com.

    Note how out1.smtp.messagingengine.com -> 66.11.4.25 and
    66.111.4.25 -> out1.smtp.messagingengine.com, this shows that
    forward and reverse DNS match.

    If you're using an ADSL connection or similar, then make sure you
    get a static IP (most ADSL providers have this option, it may cost a
    little bit more) and make sure you can get the reverse DNS changed
    (also known as setting a PTR record - your ADSL provider will have
    to do this, and not all offer it, so check with your provider first
    before signing up)

  2. Ensure your HELO string matches your reverse DNS

    When your SMTP server sends email, it has to announce it's name in
    the HELO or EHLO command. Since you have your DNS setup correctly,
    you have a fully-qualified domain name (the reverse DNS name), so
    you can follow RFC
    2821
    and use it
    as your HELO/EHLO string:

    The argument field contains the fully-qualified domain name of the
    SMTP client if one is available

    Doing this provides another level of verification that your server
    is who it says it is.

  3. Don't use Sender Address Verification

    At first glance, Sender Address Verification (SAV) seems like a good
    idea. Because SMTP doesn't include include any intrinsic way to
    authenticate the MAIL FROM address, you just connect to the
    appropriate return host and check if the site will accept email for
    that address.

    Unfortunately SAV creates more problems than it solves. As noted by
    others
    , it's easy to work
    around SAV, spammers just send with a valid MAIL FROM address. Given
    they're already spamming lots of valid addresses, they have lots to
    choose from.

    For spammers that don't use valid MAIL FROM addresses, the result
    will be that your system ends up looking like it's attempting to
    attack other systems. For instance, say a spammer sends you 1000
    emails with forged and invalid @fastmail.fm MAIL FROM addresses. To
    check them, your server contacts us 1000 times seeing if you can
    deliver to each address. However that's exactly the pattern that
    anyone trying to do a dictionary harvest
    attack

    against us would be doing! Without special precautions, your machine
    will now be treated as extremely suspicious because it just tried to
    send to lots of invalid addresses at our server.

If you run an email server and have any more suggestions for this list, let me know at robm@fastmail.fm