Best practices for SMTP servers

This page provides details on setting up DNS for users who run their own SMTP servers, and is meant for more technical users.

Users who run their own outgoing (SMTP) email server need to have certain things set up correctly to ensure successful sending of email. If a sending server is not set up properly, we may bounce mail that's sent from it.

Below are some guidelines to avoid common misconfigurations that may cause us to bounce mail. These recommendations are either specified by RFCs or as general best practice.

Forward and reverse DNS must 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, and it also helps to avoid spoofing by spammers.

HELO string must match reverse DNS

When an SMTP server sends email, it has to announce its name in the HELO or EHLO command. If DNS is set up correctly with fully-qualified domain name (the reverse DNS name), the sender can follow RFC 2821) and use it as their 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 their server is who it says it is.

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, as spammers can 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 the sending server ends up looking like it's attempting to attack other systems. For instance, say a spammer sends 1000 emails with forged and invalid @fastmail.fm MAIL FROM addresses. To check them, the server contacts us 1000 times seeing if they can deliver to each address. That's exactly the pattern that anyone trying to do a dictionary harvest attack would be doing! Without special precautions, the machine will now be treated as extremely suspicious because it just tried to send to lots of invalid addresses at our server.

Was this article helpful?
3 out of 6 found this helpful