The Importance of the DMARC Record - Protecting Your Domain Against Spoofing Attacks These days, it has never been easier to establish an online presence, and having your own domain is a key component of that. However, with great domain ownership comes great responsibility, as do the problems that can follow your presence. As such, when managing individual DNS records, all users should stay up to date on the latest trends with regards to safeguarding their domain’s reputation, as well as all the persistent problems that come with online communication. Spoofing is one of those age-old issues when using e-mail as a contact protocol, and when it comes to spoofing protection, Sender Policy Framework (SPF) and Domain Keys Identified Mail (DKIM) are usually identified as a consistent “best practice” standard. However, they themselves are not enough to prevent modern spoofing techniques, even if both of these DNS records are both useful in their own way.
In fact, SPF and DKIM are email authentication methods in the form of DNS TXT records, designed to help prevent spoofing and ensure the integrity of the message content respectively. SPF dictates which mail servers are authorized to send mail upon behalf of a domain, while DKIM signs the message with an encrypted key to prevent tampering in transit.
Moreover, SPF reviews the “Return-Path” message header—otherwise known as the bounce-back e-mail address, or the address that receives an e-mail regarding message failures due to various errors such as when a recipient’s e-mail account no longer exists, a given mailbox is full, or the content triggered an internal spam filter. Additionally, DKIM validates that the message was not altered after it was sent. However, SPF does nothing to confirm that the e-mail address in the “From” header is legitimate, nor does DKIM do anything to validate the origin of the actual sender—this is a problem, because the “From” header is actually the most critical header to check when spoofing is a concern, as this is where an e-mail client identifies where and who from the message was sent. So while in some scenarios, SPF and DKIM might be enough to prevent spoofing attempts, further security is highly recommended.
To drive the point home, let’s look at a real-world example of the shortcomings of this basic implementation of SPF and DKIM. In our testing, we utilized one of our own internal domains used within our lab and configured it to use Google as the mail provider with a valid DKIM record and an SPF record that, in theory, should not allow anyone to send mail on behalf of the testing domain ("v=spf1 -all"):
This SPF record did not have any source IP addresses and was configured with the “-all” hard fail flag, which instructs the system that any SPF failures should result in the message being rejected.
In this scenario, our test user (Anthony) received an e-mail message from the “admin” account within the same domain. The test phony message was sent using a third-party mail API service and was successfully delivered to Anthony’s inbox.
As seen above, we were able to get a “PASS” under SPF and DKIM and the email was delivered, regardless of our restrictive DNS records. So, what exactly happened here? The “Return-Path” header mapped back to an entirely different domain than what was used in the “From” header. This is typical when using third-party mail API tools, as this allows them to collect information on messages that failed for one reason or another and display said information within their respective portals.
But insofar as security is concerned, both SPF and DKIM checks are being performed on the “.net” domain as a result, rather than on the domain used by the e-mail account being spoofed—in other words, any real protection that these records provide is essentially being bypassed, which means these third-party e-mail services remain open to becoming tools used to spoof the “From” header from any domain name that solely relies on SPF and DKIM.
So, what’s the solution? Domain-based Message Authentication, Reporting & Conformance, or DMARC for short. This is an additional DNS TXT record that offers something SPF and DKIM do not, which is that decidedly critical validation of the “From” header. It builds off checks that SPF and DKIM perform by comparing the domain inspected through these records and ensures that they align with the domain used in the “From” header. If they don't match up, that's when the DMARC policy is triggered.
Furthermore, all DMARC records have an attached policy flag that instructs the recipients mail server on what to do with the message should it fail these checks. There are three options: none (report only), quarantine, and reject. With DMARC enabled and the policy set to "none," no action is taken on mail delivery attempts that fail DMARC checks. This is a popular configuration when first implementing a DMARC record, primarily so administrators can see how it might potentially impact the delivery of valid messages without actually causing disruptions. With that being said, setting the policy to “quarantine” would instruct the mail server to mark the spoofed message as junk / spam, and using the “reject” policy would cause the message to fail delivery altogether—both more popular options during live implementation.
In essence, yes, SPF protects the “Return-Path” header, and yes, DKIM does confirm that the content of the message did not change in transit. But between these two, nothing is done to validate that the message is from who it says it is from, and domain security and consistency cannot be guaranteed, which is why DMARC must enter the picture. With the additional use of DMARC, a domain alignment check is performed and therefore, all email headers are protected 100% of the time, making it a must-have when adding protection against spoofing.
Using our same demonstration message, we can take a look at how exactly DMARC helps when it comes into play:
When looking at the “header.from” section, notice that the domain that the DMARC check identified is completely different than the domain that the initial SPF and DKIM checks analyzed, and such a difference would prompt the message to fail the DMARC alignment checks. Had we further configured the DMARC policy to quarantine, the message would have been moved to our user’s spam folder, rather than directly into his inbox. With the policy set to reject, it never would have been delivered and would have instead resulted in a bounce-back error stating that the message failed DMARC checks.
Evidently, proper DMARC implementation is considerably important as these types of attacks remain constant as they continue to advance and become more mainstream. Unfortunately, native filtering offered by a lot of the big-name mail providers offer little to no protection against this type of attack without a proper DMARC implementation—make sure to check all domains to safeguard your content and respective domains. If considering an upgrade in protection, Schellman’s specific recommended implementation is to have a DMARC record with either the quarantine or reject policy enabled.