What is DMARC?
Take a deep breath – this acronym is a long one.
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is an authentication method designed to stop bad actors from impersonating you.
Developed in 2012, DMARC has become an industry-standard practice and is your first line of defense against malicious emails on your sender program. Not sure if you already have DMARC set up? Use this tool to perform a quick DMARC check.
Why is DMARC so important?
While email is as old as the internet itself, email authentication is an unfolding process. Before DMARC, inbox providers like Google relied on strict filters and user feedback to identify spammers. So strict, in fact, it could block out legitimate senders.
Using DMARC, a sender can analyze feedback loop reports to develop a strict authentication protocol that tells receiving mail servers which IPs on your domain are yours. A DMARC policy will instruct ISPs to reject emails from fraudulent IPs that are attempting to use your domain.
That all sounds great, but why bother if your emails are currently getting through to the inbox just fine? The answer is security. 90% of network attacks are carried out through email infrastructure and are becoming increasingly sophisticated. Your ISP reputation, deliverability rates, and brand reputation are all severely damaged in the case of a phishing attack.
Sounds scary, right? But before you rush to set up DMARC, let’s first understand how it works.
How does DMARC work?
Simply put, DMARC is a line of code that goes into your DNS TXT record. Yet DMARC is so much more than code – it’s a process that takes place before, during, and after implementation to ensure your email system continues to run smoothly. Let’s run through three key components of DMARC to understand this authentication standard better.
Before DMARC: Utilizing SPF and DKIM
To understand DMARC, we first need to understand its predecessors, Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM).
SPF is an authentication method for senders to publish the IPs of trusted SMTP servers that are allowed to send from a domain. The receiving server then cross-checks this record to validate the email and send it to the inbox.
DKIM authentication, on the other hand, is a signature that goes into your public DNS records, verified with a private key in your email header.
Why are these so important to DMARC? Because DMARC passes or fails a message based on the alignment of SPF and DKIM.
During DMARC: Breaking down the record
A DMARC record is compiled of relatively straightforward tags and values. Only two fields are required, and the rest are optional. In this post, we will cover the minimum requirements. However, Google has a list with all the advanced tags.
Here is an example of a simple DMARC record:
v=DMARC1; p=reject; rua=mailto:postmaster@mailgun.com;
The first tag v= is easy. It must always be DMARC1. There are no other versions at the moment, so always use 1.
The second tag p= is an instruction to the recipient's email server for emails that do not pass authentication. Here are your options:
-
None: Log the entry but take no action.
-
Quarantine: Mark as spam.
-
Reject: Bounce the email message.
If you are using BIMI, the p= tag must be set to quarantine or reject as BIMI does not support none.
The third tag is rua= or Report Email Address. This is the dedicated mailbox where your DMARC reports are sent.
If you don’t want to compile the record yourself, Dmarcian has a free DMARC record generator wizard.
After DMARC: Reviewing DMARC reports
Finally, we have the reporting stage of DMARC. Once DMARC has been safely implemented, reports will begin flying into your assigned inbox. These reports will tell you:
-
Which servers or third parties are sending mail from your domain, and if they pass or fail.
-
How each receiving mail server reacts to unauthenticated messages.
-
The total DMARC pass rate percentage.
An optional reporting tag, ruf=, tells ISPs where to return fail or forensic reports. While this tag is not supported by all mailbox providers for data reasons (Gmail, we’re looking at you…), it can give you more insights into the email content that failed compared to a standard aggregate report.
The results of these reports will help you pivot your DMARC policy. For example, if most messages are passing through the email receiver’s mail servers, you will need a stricter policy to catch spoofers. Each day, you will need to analyze your reports and troubleshoot any issues that you come across, like legitimate emails being sent to the spam folder. Now that we have a better understanding of DMARC, let’s go over a checklist of steps to implement it.