As we formally started Enigma Bridge in June, we have created a website and setup a dedicated mail server during Summer. You do the “usual” security things – S/MIME, StartTLS. You integrate your emails with some other tools so that you don’t forget to follow-up your prospects.
What I/we didn’t realise was the importance of DNS – it really is quite scary what one has to do so that emails don’t end up in spam filters before being even delivered.
BTW, we used http://mxtoolbox.com/ tool to check that the setup was correct and it kind of looked that it was (see the picture above). Until I started digging a bit deeper into the issue.
I fixed the reverse DNS – that was relatively easy with our hosting company and I could do it through their control panel.
The next was the SMTP Banner – exim and postfix take this from the server’s hostname so one has to do “hostname” command, and update “/etc/hostname” and “/etc/hosts” as we use a Linux server.
All green now. However, as I was thinking about it I didn’t like the MXtoolbox any more – more precisely, I didn’t trust it. So I looked for more tools and found some email reflectors.
- … and some others.
Unlock The Inbox gave quite detailed results and we failed at:
- certificate chain for TLS;
- Banners (SMTP, IMAP);
- DKIM test – no DNS record;
- DKIM test – failed signature;
- SPF incorrect.
The overall score 21 failures and as I got that far I wanted to nail this down. I checked and fixed issues in our SPF record – and added IPv6 pointer there (it seems to be important these days and e.g., google tests IPv6).
Next, I generated a new key-pair for DKIM and updated the DNS record (btw, I changed the DNS more than dozen times to get it right and I would fail without testing tools). DKIM is an additional signature that your email SMTP server adds to headers of emails it sends out. The public key is in the DNS record that has the role of “the authority” confirming that this is the right key.
I added DMARC record to tell receiving SMTP servers what to do with email when DKIM verification fails. One should be careful with this one so I initially set it to do nothing. But it is there and it makes an impression of “we care”. BTW, I think that a lot of these things are there to make an impression that SMTP admins care.
The last step was to get a proper certificate for StartTLS and TLS – the first one is for securing connections to other SMTP servers, the second is for securing connections to your email client. (If you do this correctly, you don’t really have to use S/MIME for internal emails as everything is encrypted. As long as you trust your email server, that is.)
At the end, the number of critical errors reported by UnlockTheInbox went down from 21 to 3: a) not listed in ISIPP register (costs £100/months), and wrong banners for b) POP3 and c) IMAP – which we don’t mind as they are internal anyway.
We also started getting verification emails from google about our SPF and DKIM configurations (they all pass now).
What next? I suppose, we will re-send some emails from last few weeks where we definitely expected responses but never heard back.
And the bottomline – I hate spam as I point my finger directly at it as the cause of all these troubles! 🙂
PS: Do not forget to add AAAA record to your DNS for your email server’s IPv6 address.
PS: Update with example of our relevant DNS records:
- _domainkey: t=y;o=~;
- enigmabridge.com:v=spf1 mx a ptr ip4:126.96.36.199 ip6:2001:41c8:51:7eb:fcff:ff:fe00:4660 -all
- _dmarc: v=DMARC1;p=none;rua=mailto:[email protected]