A Critique: What is DMARC missing?

This piece is a follow up to our discussion on the DMARC Record, Policy, and Report. We thought it would be helpful to spearhead a discussion on shortcomings on DMARC.

DMARC: Reliant on SPF and DKIM

DMARC unquestionably helps when it comes to handling spoofed phishing messages, but it is not without its faults. Its reliance on SPF and DKIM brings along some of the old problems from SPF and DKIM.

SPF requires that the sending server IP be in the list of authorized senders in the “envelope from” domain. Consequently, messages that are relayed through proxy servers fail SPF validation. Similarly, server-based email forwarding has similar issues when plain message forwarding takes place.

Another case to consider is bounce messages. Bounce messages typically have empty “envelope from” headers, and SPF suggests that the HELO/EHLO identity be used in these cases. This is rarely implemented well by SPF validators, nor is the identity properly specified by MTAs. As companies grow, their SPF TXT records need to be maintained as different departments could send emails on behalf of other departments. The 10 DNS lookup limit within SPF should be respected but often isn’t. These types of errors can result in DMARC failures by stricter MTAs that force such limits.

DMARC and DKIM

DMARC accounts for these scenarios of SPF failure, by requiring that DKIM also be setup. A DKIM signature can be validated throughout the lifetime of the message as it hops from server to server. However, DKIM is notoriously fragile as it requires that MTAs do not alter the message headers and body that are used to create the DKIM signatures. Just recently, I encountered a firewall anti virus that would alter the message breaking DKIM. MTAs that add footers or alter links within the message are likely to break DKIM if the messages are only being relayed through them.

Finally, mailing lists and DMARC don’t get along. Mailing lists typically alter headers like subject lines or add footers to the body of the message. Good ones re-sign the message and create new DKIM signatures originating from the mailing lists domain. Unfortunately, this domain will never align with the “header from” domain. There have been several recommendations on how to address this problem but to date, whitelisting the mailing list server is probably the most practical.

DMARC, DKIM and SPF Alignment

DMARC currently expects SPF to explicitly pass if SPF alignment is to occur. SPF however has several return states that when encountered with only SPF, require that the message be allowed through. One common example is the TempError which is returned upon the occurrence of a transient error, e.g. a DNS timeout due to latency issues with an overwhelmed server. A TempError today is considered an SPF Fail, so should the DKIM part also fail, DMARC would fail for a potentially legitimate message.

Another common phishing technique these days revolves around simply spoofing the display name party in the “header from” field. A header from field can be specified in the following way: Odin Borson CEO <odin@asgard.com>. The first part, prior to the bracketed email address, is the display name. Mail clients like Outlook use this to provide a friendly name to show the end user.

While DMARC examines the domain in a “header from” email address, the display name is ignored. This is problematic, especially when one reads and responds to emails on a phone. More often than not, you only see the display name on the phone and not the email address. So consider the following message:

Note the key differences in lines 11 and 12. Instead of relying on the “Reply-To” field like in the previous example, in the example above, line 11 itself contains the address that Loki expects Njord to reply to. However, in this case, Loki has setup a valid DMARC record for midgard.com so the message passes DMARC. Loki is relying on the fact that Njord will answer to Loki thinking he is Odin based only on the display name part (Odin Borson CEO) in line 11. On mobile phones this is a big problem, as one typically needs to click on details to see the email address of the person they are communicating with. A simple display-name phish like the one here passes SPF, DKIM and DMARC as Loki owns midgard.com and accordingly set them up.

Best Practices

When setting up a DMARC record, start with p=none, then move on to p=quarantine when you are confident with your infrastructure.  Using p=reject when setting up a DMARC record is dangerous. Earlier in this critique, I explain how an SPF transient error (TempError) could result in a message not getting delivered. By having p=quarantine instead of p=reject, your message would at least get delivered to the recipients quarantine instead of getting rejected at the connection level.

Consistently maintaining your SPF records, especially when you have third party senders or use marketing companies, is also crucial to success with DMARC. Try to respect the 10 limit lookup in DNS when setting up your SPF record. While you may have DKIM setup properly, it is best to have both SPF and DKIM reliably working for DMARC to pass. DKIM is fragile as MTAs do alter the message sometimes. In such cases, only SPF remains and thus should be setup correctly. While this becomes a daunting task for larger companies, it is essential to do.

DMARC reports are amazing when you make changes to your infrastructure. The results of changes that require updating your SPF and DKIM records can be monitored in the DMARC reports you receive daily. But, after a while, most IT admins will ultimately ignore them and the messages will be lost in their thousands of email. Furthermore, the report sender must be reliable. After having setup a DMARC record recently, I realized that only the reports from the big players like gmail.com, hotmail.com, yahoo.com etc were of value to me as I trusted them more, especially as a larger quantity of messages with a “header from” using my domain, ended up on their domains.

Should all DMARC compliant servers necessarily have to generate reports? Note that report generation can potentially result in a lot of messages being generated, especially if the DMARC record contains a ruf (Reporting URI for Forensic Reports) address and that is an added load on an MTA. DMARC reports on loaded servers can potentially generate a lot of email, make sure your server can handle the new load. Don’t use ruf when setting up your DMARC record. If you need immediate feedback, test by sending messages to the big players like Gmail and examine the message details there. They typically have Authentication-Result headers where they outline the results of SPF, DKIM and DMARC checks.

Ultimately, the best choice is to have a service monitor your DMARC reports for changes that are atypical. Everyday, a report is sent to the email address in the rua (Reporting URI of Aggregate Reports) field. While an IT admin will examine the report for a few days, expecting them to examine them daily for longer periods is unrealistic. DMARC reports are written in a format that allows for easily automated readers and tracker. An automated system where changes in the report patterns raises alerts should not be complicated to implement and would allow IT admins to quickly react to changes in their setups that they might have missed.

modusGate uses DMARC to protect your email users from phishing and spoofing attacks, while Vircom offers a modusSecurity service to help implement and monitor your DMARC deployment – find out more here or by getting in touch with us. Subscribe to our blog for more on email security!