DMARC

Since email is the central way of communicating nowadays, it is easy to forget that a domain name probably has many different technical services that are used to send outbound emails. These services are usually a combination of personal infrastructure managed by an organization, as well as services that are delivered externally. 

The more services that are used for sending email on behalf of a domain name, the more parts need to be ensured to be setup correctly. As well on the sending server as in the domain name setting. 

The latter is performed in DNS regarding SPF and DKIM. When working with DMARC deployment, the domain owner receives feedback through DMARC reports for all emails that have been sent from the domain. It is not always easy based on the reports to understand what is legitimate and the more systems used the greater the complexity.

Since one of the basic ideas with DMARC is that you as a domain name owner should get feedback on how your domain is used, results in that you will have many DMARC reports to analyse. These aggregated DMARC reports will be emailed to you daily from receiving systems that receive emails from your domain and sent in an aggregated XML file format.

You will have a large volume of data to analyse and the reports will include all emails that have been sent from your domain, both emails that have been sent from your organization but also emails that have been sent from parties that pretend to be you. 

Without a tool that manages these reports in a GUI that is user friendly, the possibilities of interpreting and analysing the large amount of daily data will be difficult.

When implementing DMARC, you are forced to have a good understanding of the email ecosystem; or the system that sends the email, the domain that is used and the recipient who receives the email. A company usually uses several different systems from different suppliers to send outgoing emails. 

The ability to influence how these providers send email technically is often limited. In addition to the system that sends the email, you need to configure the domain's records in DNS regarding SPF and DKIM to be compatible with each sending system that is used. In the end, there is the recipient who receives the email. 

Despite the fact that you during DMARC deployment receive DMARC reports sent to you with information about the email flows, it is not easy to understand if identified issues from the reports are related to the sending system, domain settings or something on the recipient's end. 

Given the high volume of data to analyse, there is a risk that it will be difficult to identify which actions need to be taken and where.

A common mistake is only associating DMARC with creating a record in the domain's DNS settings similar to what is done when adding a sending system in a SPF record or publishing a DKIM key. 

With DMARC, ongoing work with analysis of DMARC data and work with actions on issues that are identified is required before a policy that protects the domain name can be deployed. It is common that the complexity of interpreting DMARC reports and resolving identified issues can be a time-consuming process, which in many cases results in policies that increase the protection of the domain not occuring.

When working with DMARC, systematic monitoring of the reports you receive is required. Even if a strict DMARC policy for a domain name has been implemented, the reports are the only tool you have to be able to continuously monitor that all email systems over time continue to send email technically correct, that abuses such as spoofing, phishing and others attacks are actually stopped as well as for you to be able manage ongoing changes when setting up new email systems and services that will send mail on behalf of your domain.