Making SMTP work in 2020
Sending e-mail with SMTP is one earliest internet services available, and was easily for me the first bit of "internet" that I had access to in the late '80s/early 1990s. Back in the "good old days", standing up an SMTP server for sending e-mail was a trivial matter on pretty much every platform. TCP Port 25 open to the internet, and you could send e-mail with the "From:" as any account you wished and your e-mail would end up in the mailbox at the other end. Directly locally receiving e-mail was a more difficult task - but directly sending e-mail from any machine was easy and had advantages of not having to connect and authenticate to a remote server, which many times speed up the process for those in the know.
Of course SPAM ruined all of this, and is still the bane of our existence. Once Spam became a problem blacklists were initially used, SMTP servers that Spam came from or didn't use authentication found themselves unable to send mail that would actually get delivered. Of course in a world where money is still to be made from Spam that wasn't the end of it and it's a constant game of cat and mouse. Currently, there are 4 thresholds (with a 5th optional) that need to be met to successfully run your own SMTP server. In order of priority:
- Keeping off the good old IP blacklists.
- Reverse IP lookup (nslookup) matching the server EHLO hostname
- DNS entry (SPF) authorizing e-mail coming from that server
- Matching DKIM certificate in DNS and SMTP server
- DNS Record for DMARC
Of these, having a dynamic IP address makes #2 very difficult, and #3 a hassle. In our "always connected" ISP world, even Dynamic IP addresses can last a good long time, so it may be worth it. Since I changed ISPs, my IP has been fairly static, short router resets don't trigger a change. So let's go through these:
#1 mostly involves keeping your SMTP sever secure, and cleaning up the reputation of the IP address you have if it has become sullied. There are 94 different blacklists as of me writing this (plus major e-mail providers have their own internal blacklists), and you can use tools like this to find if you are blacklisted and beg to get taken off: Email Blacklist Check - IP Blacklist Check - See if your server is blacklisted (mxtoolbox.com) . If you are lucky you will get a 550 bounce rejection listing this is as the reason.
#2 This is another one that was one of the first anti-spam techniques, required by AOL to get e-mail though. It is usually easiest to implement, but may be hard to know is an issue (again, you might/should get a specific bounce rejection listing this as the reason). I know, you might want to have your smtp server be smtp.yourdomain.com or mail.yourdomain.com or some fun naming convention like darthvader.yourdomain.com, but unless you own the IP address and control the DNS A record for it, you have to roll with what you have got. Just do an nslookup at a command prompt for your IP address to see what your ISP assigned and then name your server that in the SMTP config for EHLO.
#3 SPF DNS records are easy to implement and go a long way. Basically, it's a simple TXT record that says where e-mail from your domain is allowed to originate from. If you use a 3rd party SMTP service, they will often ask you to add an SPF record to your DNS saying e-mail originating from their domain is legitimate for you. As an example the SPF record for KN6Q.org is:
v=spf1 a mx ip4:69.170.70.198 ~all
Which broken down is:
| Prefix | Type | Value | PrefixDesc | Description |
|---|---|---|---|---|
| v | spf1 | The SPF record version | ||
| + | a | Pass | Match if IP has a DNS 'A' record in given domain. | |
| + | mx | Pass | Match if IP is one of the MX hosts for given domain name. | |
| + | ip4 | 69.170.70.198 | Pass | Match if IP is in the given range. |
| ~ | all | SoftFail | Always matches. It goes at the end of your record. |
#4 The DKIM (DomainKeys Identified Mail) certificate pair is technically optional, but this could be the difference in your mail being delivered or not. Your SMTP server must support DKIM, which consists of a public certificate in a DNS entry, and a private key that your server signs a hash with. The downstream SMTP server decrypts the hash using your public key found in DNS. There are many websites such as this one that you can use to generate a DKIM certificate pair.
#5 The DMARC record is another very simple DNS record that basically says this - this domain is using SPF and DKIM, and if SPF and/or DKIM checks fail, you should do this with the e-mail. Once you are confident in SPF and DKIM setup use a DMARC generator to make a TXT DNS entry for the domain.
What I have found is the public e-mail providers (Gmail, Yahoo, Hotmail, etc.) are pretty loose with letting e-mail in and you can get by with #1 & #2, when you start knocking on the door of corporate e-mail systems (including cloud providers like Office365) you probably will not get in without #3 SPF and/or #4 DKIM. DMARC is still fairly optional at this point (and honestly kind of presumptuous that another ISP would honor your request of what to do with your e-mail that fails SPF or DKIM checks). However, anti-spam systems score every e-mail that comes in as potential junk - everything that you do on this list lowers your potential spam score, DMARC is simple way to knock down your spam score a point or so.