Email Security Hardening (Part 3): Domain-based Message Authentication, Reporting, and Conformance (DMARC)

Now that SPF and DKIM have been added to your DNS record we can now add the final portion to protecting your domain from being spoofed, the Domain-based Message Authentication, Reporting & Conformance (DMARC) entry to your DNS record. DMARC was created to address the shortfalls of SPF and develop a higher-level policy protocol that would be more broadly deployable.

DMARC leverages both the results of an SPF check and a DKIM checks results to determine if a mail is from an authorized source. It combines the SPF/DKIM results with an identity alignment test (which requires the Mail From domain for SPF and the signing domain for DKIM to be the same as the body From domain) to impose restrictions related to the From domain. If either SPF or DKIM pass/verify and are aligned, a message is DMARC authorized.

DMARC also adds both aggregated and per domain feedback reporting to enable admins to assess the effectiveness of their ongoing email authentication operations. In more simple terms if your users were to send emails to 42 different domains in the report time specified by the DMARC entry, the admin would receive 42 reports regarding messages sent between their domain and the recipient domains.

Setting up DMARC is a simple matter and requires another entry to be made to your DNS record. A DMARC entry requires ideally 1 additional item to be set up depending on the needs of the organization which is a new mailbox to receive the reports that will be sent by recipient domains of emails sent by your users.

Similar to when we added an SPF entry into the DNS Record, the settings for DMARC should look similar to below:

HOST – This should begin “_dmarc.” and should be followed with your own domain

VALUE – This contains a number of fields:

• v=DMARC1 this signifies the version of DMARC record that is implemented (currently only version 1 exists)
• p – This is the policy that should be enacted
  o None/quarantine/reject
• pct – This state the percentage of emails which the rule should be enforced
  • This should always be set to 100 (policy applies to all emails which fail)
  • I have seen no good arguments for why this should not be 100%
• rua – This specifies the address to which aggregated reports are sent to
• ruf – This specifies the address to which forensic reports are sent to
  o Should be the same as rua (can be different but require additional setup)
• sp – This states if the policy accepts the use of subdomains
• ri – This states how often reports should be sent by each domain (in seconds)
  • A general rule of thumb in 84600 (24 hours) so reports are received once per day

Once deployed (in conjunction with SPF/DKIM) “p=none” will allow you to monitor the potential impact of deploying a more aggressive policy. Once testing has been concluded and emails sent are found to not be impacted outside of expected results, the “p=none” should be updated to “p=quarantine” to request recipients of spoofing of your domain to hold in a safe destination until an admin can review if they should be released or to place it in the Junk/Spam folder.

With the completion of these 3 capabilities, your domain should be much more resilient to being used in a spoofing attack against third parties and offer a good level of protection to your own users who may receive spoofed messaged from the outside into the organization. There is more we can do to protect our own users however, now that we have set up policies which dictate recognized infrastructure. This can be achieved with Mail Flow rules.

Common Mistakes

Not accounting for all legitimate mail services

If a full investigation into all services utilized by the organization is not conducted, then you will find a number of false positives in relation to your “SPOOFING” Mail
Flow rule which will potentially affect the business due to the unrequired analysis of or deletion of falsely flagged legitimate emails. You may also find that other businesses do not receive your messages or are ignored as spam due to their own protection systems.

Subdomain misconfiguration

Potential abuse of subdomains (legitimate or falsified) is possible if specific DNS entries are not added for each subdomain in use by your organization. If no subdomains are expected to have the ability to send an email, then the inclusion of the “sp=reject” is recommended as this indicates you do not expect to use subdomains.

Incorrect syntax/content

The rules regarding SPF/DKIM/DMARC contents in your DNS record are relatively rigid, there are specific tags you must include and a series of optional tags for more granular control. However, outside this, any additions/notations/etc may cause the policy to fail due to errors in how it is interpreted. This also applies to the addition of unexpected information in fields such as an email address with the SPF record. Care should also be given when adding IP ranges as the omission of “2” in a “/32” address range could have a significant impact.

No tool to understand DMARC reports

DMARC aggregate and forensic reports are XML documents contain a list of every message from your organization to the recipient domain (as discussed previously you will receive an aggregate report for each unique domain your organization has sent emails to). These reports contain a large amount of information including; dates/IPs/SPF & DKIM results/dispositions/etc. Depending on the number of emails sent to a given domain, these reports can be very lengthy and difficult to understand. Therefore, a tool to assist in understanding these can be very beneficial. No lookup is required for ip4/ip6/all.

“Since starting in cyber security, I have had a keen interest in all aspects of blue team and working with new technologies to investigate potential threats on behalf of our customers. With such a diverse field of study, there is always something new to learn or defend against, and this challenge of continual progression makes every day feel new and exciting.”
— Darren Fotheringham, CSIRT Lead, Quorum Cyber