Setting up DKIM and DMARC records Part 3
DMARC
Adding the DMARC record
DMARC (Domain-based Message Authentication, Reporting & Conformance) records are rather more interesting as they are additional to SPF and DKIM – as in you need SPF and DKIM records before DMARC is of any use at all – and provide a feedback mechanism so that you can check just how effective all the other steps were. As always, none of these records guarantees that your email will actually be delivered but, at the very least, you will have a mechanism to diagnose the delivery problem. Whilst many of the large email providers such as Office 365 and Gmail support DKIM/DMARC, there are still a lot of corporate email servers out there that, even today, do no such checks. So, the DMARC record – again a TXT record added to the DNS zone for somecompany.com - looked like this:
v=DMARC1; p=none; rua=mailto:dmarc@somecompany.com; sp=none
In this case, all DMARC reports for the somecompany.com and web.somecompany.com DNS zones were to be sent back to a corporate email account so the DMARC record was added to the somecompany.com DNS zone. Therefore, there was no need to add a record to the web.somecompany.com DNS zone as it, by the default behaviour when the DMARC record is checked, will inherit its settings from the somecompany.com parent DNS zone (the sp=none parameter shown above has been added for clarity but represents the default behaviour).
Of special note, is the p=none parameter which represents the policy that you wish to apply when the receiving mail server processes emails from your organisation. When you first add a DMARC record, it is advisable to use p=none (monitor only but take no action) and then monitor any returning emails to determine if you have actually configured your SPF/DKIM/DMARC records correctly as each receiving mail server may interpret your records differently. Once that has been verified - allow a month or so – then the p=none can be changed to p=quarantine as this will allow any email that fail a DMARC check to be marked as spam but (probably) still delivered. Monitor things further and, if the percentage if your legitimate mail getting marked as spam is small, then the highest setting of p=reject can be used. Considering how much a modern organisation relies on email, it is worth investing in some sort of reporting tool to monitor progress. Those DMARC reports are in XML format and can take some effort to interpret in their raw form. Remember to verify that your DMARC record as well.
Conclusion
Getting your legitimate mail through spam filters is always going to be a challenge but the proper implementation of DMARC, DKIM and SPF will help and, with the adoption by governmental institutions, may well become obligatory in the very near future.