E-mail server configuration can be a pain. Spam was and still is a big problem, especially due to its volume, being almost half the size of all e-mail sent globally. Automated services, filters, reputation monitors and blacklists made it harder for spam to get across in people’s inboxes. It also made it harder for e-mail servers to be accepted as “legitimate” – which is good because it raises the quality level and hardens the requirements, but on the other side, it gives debugging issues.
As with DNS, e-mail is usually recommended to be handled externally, due to the issues associated with configuring and maintaining it. Due to the number of accounts and volume of e-mails that I’m handling, I’ve decided that it doesn’t make sense to pay for this and I could handle it on my own. I’ve split the setup process into 4 parts. The following is meant to give an idea of what should be taken into consideration when having your own mail server, not specifics on how to set up the specific software.
- Server configuration
- DNS configuration
- Other things to consider
E-mail server configuration and software consideration
Things to consider:
- mail transfer agent (MTA) – a software that will handle receiving and sending emails. There are multiple options to choose from, a popular one on Linux servers being Postfix.
- host settings – a physical/virtual server with good network connectivity, a valid hostname (e.g. mail.yourserver.com)
- server settings – most MTAs support necessary settings right “out of the box”, having them as either default configuration or optional. These settings include supporting encryption, disabling the the possibility of anybody sending emails (open relay), properly responding to SMTP commands and others. I prefer to check settings using online tools like MXtoolbox :
- content checking (spam filtering, virus checking) – you’re not really required to have it, but you will probably find yourself (or your users) being bombarded a lot spam that will simply fill your inboxes. A popular spam filer is SpamAssassin.
- extra support for DKIM/SPF/DMARC (abbreviations explained below) – again, you’re not really require to have it, but some providers will only accept emails that are have certain headers. Without these, your e-mail might end up in the spam folder of the receiver or they will not receive it at all.
DNS records and settings
- E-mail server
PTR record – the opposite of an A record. It resolves an IP address to a domain. It can only be set at an ISP level and not on in a normal DNS zone file editor. This means that you have to contact the actual owner of IP Netblock (most cases, your ISP).
Example in DigitalOcean – here you have the possibility of editing the PTR record associated with your VPS
It’s one of the methods used to verify if a server is legitimate, so make sure you have it.
2. Domain (client) using e-mail server
MX – or mail exchanger record specifies which mail server is responsible for receiving and sending emails for the domain. Multiple records can be specified (with a different priority – which is to be used first). It is required for an domain to have a designated MX record if it is to send/receive emails.
Ways to check the MX records for a domain on the cli :
dig domain.tld mx | grep MX
nslookup -type=mx domain.tld | grep “mail exchanger”
SPF – or sender policy framework, is a TXT record that specifies which hostnames or IPs are authorized to send mail on behalf of a certain domain name. In other words, SPF indicates that the mail server anotherserver.com is allowed to send an email for DOMAIN.COM. An example can be seen below, where both the servers defined in the MX records as well as anotherserver.com can send on behalf of DOMAIN.COM . More syntax info on the SPF dedicated website. SPF is optional but should be implemented as most major providers take it into consideration.
v=spf1 mx include:anotherserver.com ~all
DKIM – or DomainKeys identified mail, is a TXT record that authorizes a domain name associated with a email to send it, using cryptographic authentication. Its a way of providing assurance that an email is being sent by a certain organization (domain) and that the contents are actually theirs. As with SPF, DKIM is optional but should be implemented. DKIM records take the following form.
Record name :
Record value :
Where “k=rsa” specifies the cryptographic cypher and “p=” specifies the public key.
Both SPF and DKIM can be checked on the CLI using :
dig domain.tld txt | grep TXT
nslookup -type=txt domain.tld | grep text
DMARC – or Domain-based Message Authentication, Reporting & Conformance . SPF and DKIM work great together, but they do not specify what does the receiving party do when it receives an email that does not comply with what the records are telling. The way its being handled right now is either by the provider not doing anything or by discarding emails that do not comply with the SPF/DKIM records. DMARC can tell providers what to do with the emails, including sending an email back informing a designated address that somebody tried to send an email on behalf of their domain name. That’s pretty interesting but it is not (yet) widely used. Probably the most interesting record / feature and the one that is optional and not that necessary to add just for your emails to be sent and received.
3. Propagation time and domain age
After setting up an email server, one would normally jump on to test it, by sending emails. Keep in mind that DNS records need to propagate in name servers all around the world before providers from around the world are to receive emails from your server. Usually it takes around 1 hour before you’re good to go, but hosting providers often tell us that we should wait between 36-72 hours for full propagation.
Other factors worth considering
Neighbouring servers/IPs – some providers build a servers reputation by taking into consideration other servers on the same CIDR block / ASN. If your servers IP is 184.108.40.206 and the server with IP 220.127.116.11 is hosting porn, you will probably not score too good in ratings.
So far I’ve done a lot of manual testing (e.g. manual sending emails to test email accounts on various providers) but there are some tools that saved me some time.
- Check SMTP server settings and other DNS records
- Check DNS records world propagation
- Check the “spamminess” of your e-mails against spam filters – free options are many, one that is use is Mail-Tester. Payed alternatives have more filters that your emails are checked against and can save you some good time – some have free trials too.
This what I went through when doing my e-mail server configuration. It can be a pain to debug your setup and even a bigger pain to understand what is happening when e-mails are not being received. Major providers should be more open on their spam filters (at least to make developers / admins understand what must they specifically comply to). Initiatives that support easy and proper e-mail server configuration are very welcomed but a bit scarce. Some would include development projects like MailInABox. If you know of any other initiatives or projects post them below.