Introduction
One of the most common issues we find on penetration testing and process review engagements is misconfigured, or completely missing, Domain-based Message Authentication Reporting & Conformance records, or DMARC for short. These simple DNS records prevent malicious threat actors and spammers from sending spoofed emails pretending to be from your domain. In skilled hands, spoofed emails can present a serious threat to organizational security as it makes the success likelihood of Social Engineering attacks significantly greater. In this article, we’ll be covering what DMARC is, how it works, and how to configure it properly with major DNS providers such as Cloudflare and Google Domains.
The Basics of DMARC
Simply put, the purpose of DMARC is to protect your domain from being used in spoofed emails. Without proper protections, spammers and other malicious actors can send fake emails that appear to come from your legitimate domain. As you can imagine, this could have serious security implications in the form of email phishing and can also damage the reputation of your domain. With a properly configured DMARC entry in your DNS records, you can stop email spoofing in its tracks either by quarantining spoofed emails or having them rejected entirely. While DMARC itself isn’t an authentication mechanism, the records rely on two other records called SPF and DKIM. Consult the documentation for your hosting provider to see how to add these records to your DNS. These all work in tandem when a mail server receives an email to authenticate the sender and verify that it did indeed come from the domain it claims to.
Configuring DMARC Records
Every DMARC record is composed of a specific key-value pairs that provide instructions for how mail servers should handle emails coming from the associated domain. Let’s break down each part to better understand how this works. First, let’s take a look at a completed record, which you can see below.
“v=DMARC1; p=quarantine; rua=mailto:postmaster@example.com, mailto:dmarc@example.com”
V: This value selects the version of DMARC to be used, which for now is “DMARC1”.
P: Here is the first important strategic decision to make when configuring the record. The “p” stands for policy and specifies the action that a receiving mail server should take when processing emails from the given domain. The three options for this setting are none, quarantine, and reject. The “none” option essentially disables the protections so should not be used. “Quarantine” will instruct the mail server to send the email to the recipient’s spam folder rather than normal inbox. “Reject”, as you may have guessed, causes emails that fail authentication to not be delivered at all. It’s generally recommended to start with a quarantine policy and eventually switch to reject after some time to ensure that legitimate emails are not being wrongly rejected.
RUA: This key specifies the address for aggregated reports, which come in the form of an XML document, to be sent to. These reports contain statistical data regarding attempts to use the associated domain as the email sender.
DMARC settings are stored as TXT records within DNS records for the given domain and should have the resource name “_dmarc”. The full policy, as discussed above, should be listed in the “data” section of the DMARC TXT record.
Conclusion
While it might all seem confusing or even overwhelming at first, setting up DMARC records for your domain is actually a relatively simple process with a potentially large payoff. The ability to protect your domain from illegitimate use should be a top concern for administrators in any organization, doubly so for those that rely extensively on email communication. To see if your organization is safe from this and other attacks, contact us to find out how our expert team of Security Engineers can help keep you safe from a wide variety of threats.