Take control of your mail domains, start the implementation of SPF, DKIM and DMARC | What is SPF, DKIM and DMARC? These three components are used in combination to prevent someone outside your domain from sending emails as if they were sent from inside your organization, aka Spoofing.
What is this and why should we have it?
An email consists of multiple layers where each component manages different layers. With layers, I mean RFC 5321 (which handles envelope) and RFC 5322 (which handles “Mail From”). Implementing these three components (SPF, DKIM and DMARC) are strongly recommended and will help prevent people spoofing using your domain and also give your domain a better reputation. Many companies out there focus on implementing SPF records, which is good, but it will not stop people from spoofing your domain.
If you have your email in Office 365, Microsoft has a guide which explains how you implement this (If you’re not yet in Office 365 it is still worth reading). https://technet.microsoft.com/en-us/library/mt734386(v=exchg.150).aspx
Important: if you implement this, always start the DMARC rule with a policy set to “None”, which is like a reporting mode. Once you have a better picture of your environment you can change this policy to either “quarantine” or “reject”.
How can we read the xml files sent back to our dmarc mailbox?
For the DMARC record in DNS, you will provide an SMTP address. This mailbox will receive reports (attached as a Zipped file) from other domains with information, this example below shows what it may look like:
<?xml version=”1.0″ encoding=”UTF-8″?>
<source_ip>IP Address XXX.XXX.XXX.XXX</source_ip>
There are a lot of companies out there, like Dmarcian and Dmarc analyzer, which can help you analyze this information but they also come with a monthly cost. Instead what I have done is build a solution which uses some products that we already pay for and have in our cloud subscription (i.e. Exchange Online, SQL, Azure Automation and PowerBI).
For an example of what it can look like, see the picture below or click on the link for an interactive example.
* data above have been modified
Combining these products gives you reports in a more user-friendly way instead of buying an expensive 3rd party product, or trying to read and understand the xml files. With this solution, we can get a better understanding of which systems, 3rd party and/or internal, are sending emails using our SMTP domain.
If you would like to hear more about this and get help implementing this you are welcome to contact us.