SPF
Make sure your SPF records is valid. I have used:
- https://www.kitterman.com/spf/validate.html - mostly to validate records before publising them in DNS
-
- Lookup published SPF/TXT dns records.
- This also validates DKIM and DMARC records ... very helpful.
Publish SPF records for HELO names used by your mail servers
This is the one that actually surprised me the most. Some email hosts apparently some mail servers do a spf lookup on the hostname you are coming from.
But it's really simple to fix. Just add a TXT record for: mailserver.domain.tld with the the following v=spf1 a -all
Also, make sure your IP actually have a PTR record ... more and more mailservers(We do where I work) is actually denying communition with clients not having this setup.
Read more about the issue here from openspf.org
DKIM
No real comments here yet. Since we only trust SPF. We might however turn this on later as we use Baruwa to scan email. But we don't send emails out from this platform, so this is a job for the Microsoft Exchange experts.
DMARC
Monitor of RUA/RUF reports
Before even starting looking at this, be sure to have a system setup for receiving RUA and RUF messages. This will ease the implementation and debugging issues. Looking around the web there is many commercial solutions for this, like really alot ... but the price was actually quite high when having 50 domains. So I found an Open Source solution called parsedmarc by Sean Whalen. GitHub Source. I used Debian Stretch because that's what the developer used in his own setup, but this should probably work on most linux distributions. Mostly because I has issues with Python ...
This gives some amazing insights about traffic about your email domains. This is however a share that not more have setup RUA mails on there mail server. We only get mail from about 10 ... but I'm sure we mails alot more different mails server in the world. But is enough to get information about SPF/DKIM and if it's actually time to turn on DMARC.
Setup dmarc dns records
This cannot be stressed enough. Be sure to run test for at least a few days before just turning it on. This means, using p=none to being with, then change to either reject or quarantine later when you are confident that everything works as expected.
_dmarc.domain.tld with v=DMARC1; p=none; rua=mailto:rua-reports@domain.tld; ruf=mailto:ruf-reports@domain.tld
I have seen alot of people missing the mailto in the dmarc record for rua and ruf. Not really sure why or if they don't validate the record ... but ... it won't do nothing when it's not valid ...
p is the Policy for the domain - Can be one of the following:
- none - You just want to monitor the DMARC results and you do not want to take specific action on all the failing emails. You can use the “none” policy to start with DMARC and gather all DMARC reports and start analyzing this data.
- quarantine - You put the emails which fail the checks in quarantine. Most of these emails will end up in the junk folder of the receiver.
- reject - You can reject all emails that fail the DMARC check. The email receivers should do this ‘on SMTP level’. The emails will bounce directly in the sending process.
If you are setting this up for multiple domains and wanting reports to be send to the same domain, but sure to create a TXT record on the domain telling the sending you are willing to receive reports for that domain.
We created a wildcard record so everyone who want to send us reports is allowed. The records should be *._report._dmarc.domain.tld with the following value v=DMARC1
You can read more about dmarc external validation here. We found that some actually obey this record while others dont ... ofcause, google don't ...