Gain visibility with DMARC
In the current digital era, email has become a crucial component of both our personal and professional lives. However, with the sophistication of cyber threats rising, it is more important than ever to ensure the security and legitimacy of email communications.
This is where Domain-based Message Authentication, Reporting, and Conformance (DMARC) comes into play. The Mailservers of Recipients that support DMARC, provide feedback to domain owners about the use of their domains; this feedback can provide valuable insights about the use and abuse of your domains.
What is DMARC?
DMARC has been around since 2015 and was Invented by Yahoo. It is defined in rfc7489. It combines two existing email authentication protocols, SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail), to provide a comprehensive framework for validating email senders. Check your SPF, DKIM, DMARC Record here https://dmarcadvisor.com/domain-check/
Sender Policy Framework (SPF)
Rcf4408, later replaced by rfc7208, allows domain owners to define the authorized mail servers that are permitted to send emails on their behalf. When an email is received, the recipient’s server can verify the SPF record of the sending domain to ensure it aligns with the authorized servers. SPF checks will be against Domain in the “Mail From” (Envelope). An SPF Record is a TXT Record and looks somewhat like this:
v=spf1 ip4:18.104.22.168/29 include:spf.protection.outlook.com -all
Best Practices for SPF Records
- Your Domain has an SPF Record
- Includes and A Records in SPF Record don’t exceed 10 DNS Lookups
- SPF Record have “-all” (hardfail) at the end
- Use “v=spf1 -all” for Domain that are not used for Email
DomainKeys Identified Mail (DKIM)
DKIM uses cryptographic signatures to verify the integrity of email messages. The sender’s domain generates a unique digital signature for each outgoing email, and the recipient’s server can validate this signature to confirm that the email has not been tampered with during transit. In the Picture below, you can see a DKIM Header in a mail.
To understand the different Tags, below is a Table that explains it in more detail.
|algorithm used to generate the signature
|Header/Body Message canonicalization
|Selector used for this Mail
|Signed header fields
|The hash of the canonicalized body part
|The signature data (Base64)
|Table 1 DKIM Header Explanation
DKIM solves the Forwarding Problem from SPF, as the Signature stays in the Header. It will be still valid, as long the Fields specified with the “h=” Tag are not changed. Domain-based Message Authentication, Reporting, and Conformance (DMARC) DMARC builds upon SPF and DKIM by providing an additional layer of policy enforcement and reporting. This will create a feedback loop so you know who is using your Domains and you can adopt and fix your DNS Records. More Infos about DMARC Record and DMARC Policy can be found in the Article of Damian Scoles “Microsoft Brings Improvements to DMARC” To check SPF,DKIM and DMARC on Inbound Emails you can use the Messaging Header Analyzer and check the “Authentication-Results”, “Received-SPF” and “DKIM-Signature” Headers as in the Picture below (Figure 3).
DMARC Aggregate Report
The DMARC Aggregate Report will be sent to the Recipient (multiple recipients possible) defined in the “ruf” Tag. The Aggregate Report is a Mail with a *.zip or *.gz File Attached that contains an XML File. Below you can see how a DMARC Aggregate Report from Exchange Online.
Here is an Example of such an XML File (figure 7) Exchange Online will report as “Enterprise Outlook”
The XML File by itself won’t help you much, you will need a Software or a Service that will aggregate these XML Files. Most of such 3rd Party Services will cost based on domains and email volume.
The Aggregate Reports from Exchange Online will be reported as Enterprise Outlook.
There are many such services out there like:
DMARC Aggregate Reports In Office 365
Microsoft has announced to send DMARC aggregate reports for Exchange Online back in March.
Office 365 will send out DMARC aggregate reports to all sender domain owners that has a valid RUA address defined in their DMARC record. But there is a limitation: If contoso.com MX record is pointed to a different email security solution in front of Office 365, Office 365 will not send DMARC aggregate reports to any sender domains RUA address configured in their DMARC record.
DMARC Data Providers
You can find an example of DMARC Data Reporters
The Reports are slightly different for each Region. For Example, in America Exchange Online (Enterprise Outlook) is at the 5th Place. If you combine Exchange Online and Outlook.com Microsoft is Number 3 for delivering DMARC Aggregate Reports.
According to DMARCAdvisor the Aggregate Reports have been doubled overnight, when Microsoft started to send out DMARC Aggregate Reports. Regarding theyr numbers, in the second week of April, they processed almost 33 million reports from Enterprise Outlook. For Example you can see the DMARC Aggregate reports from a Company in Netherlands - there is a massive Change in April 2023.
Conclusion / Summary
By sending DMARC RUA Reports from Exchange Online, Microsoft has become one of the Providers for DMARC Aggregate Reports. The chances that you get back a DMARC Aggregate Report from a Receiving Infrastructure for your Domain have significantly increased and therefore made the DMARC Policy even more useful.
The Feedback loop that DMARC provides, enables the Domain Owner to fix and strengthen the Records and set the DMARC Policy from p=none to p=reject.
DMARC, with its integration of SPF and DKIM, provides a powerful tool to combat email spoofing, phishing attacks, and brand impersonation. By adopting DMARC, organizations can strengthen their email security, improve deliverability rates, and establish trust with their recipients, ultimately safeguarding their brand and maintaining a secure communication channel.