Setting Up DMARC Records: A Comprehensive Guide

Email spoofing impacts businesses significantly, causing million-dollar losses annually. Your "from" address can be vulnerable without DMARC despite strict security. This post will clarify what DMARC is and guide you through its implementation.

🚧

Important Update: Mandatory DMARC Record Setup for Emailing

What is DMARC

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a safeguard established in 2012 to prevent email impersonation. Today, it's an industry standard and your frontline defense against malicious emails in your sender program. You may already use DMARC - if you're uncertain, this tool provides a quick check.

What makes DMARC special are its policy settings. You can use these to handle any action that comes from somewhere pretending to be your domain name. This gives you an extra safety layer and lets you control your email sending better.

Why DMARC Matters

While email has been around as long as the internet, refining its authentication continues to be an ongoing process. Before DMARC, providers like Google used rigorous filters and user reports to pinpoint spammers, sometimes inadvertently blocking valid senders and domains.

With DMARC, senders can analyze feedback reports to develop authentication protocols, guiding receiving mail servers about the authentic IPs on your domain. A DMARC policy instructs ISPs to reject emails from fraudulent IPs attempting to use your domain.

Why bother if your emails reach the inbox without issue? The reason lies in security. With 90% of network attacks executed through email infrastructure, email attacks are evolving. Phishing attacks can severely compromise your ISP reputation, deliverability rates, and brand reputation.

How Does it Work

DMARC is a code line you insert into your DNS TXT record. But it's not just about coding— it's a constant process that works before and after you implement it, ensuring your email system keeps working smoothly. Let's break down DMARC's three main parts to understand this standard better.

1.Before DMARC: Understanding SPF and DKIM

To comprehend DMARC, familiarize yourself with its older cousins, Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM).

SPF is an authentication technique allowing senders to list the trusted SMTP servers' IPs authorized to send from a domain. The receiving server verifies the email against this record before letting it into the inbox. Conversely, DKIM authentication is a signature in your public DNS records, confirmed with a private key in your email header.

This matters to DMARC because DMARC relies on these two to decide if a message should pass or fail based on the SPF and DKIM alignment.

2.During DMARC: Understanding the Record

A DMARC record consists of simple tags and values. Only two fields are mandatory, while others are optional. We will focus on the essential requirements, although Google provides a complete list of advanced tags.

Consider this simple DMARC record as an example: v=DMARC1; p=reject; rua=mailto:[email protected];

The initial tag, v=, must always be 'DMARC1' since no other versions are available.

The second tag, p=, instructs the recipient's email server for emails failing authentication. You have three options:

1. None: Logs the entry but takes no action.
2. Quarantine: Marks the email as spam.
3. Reject: Bounces the email message.

For BIMI users, the p= tag must be set to 'quarantine' or 'reject', as 'none' is not supported.

The third tag, rua=, or Report Email Address, specifies the mailbox where DMARC reports land.
Dmarcian offers a free DMARC record generator tool if you prefer not to compile the record.

3. After DMARC: Analyzing DMARC Reports

With DMARC implemented, reports start entering your designated inbox, providing details on the following:

1. The servers or third parties sending mail from your domain and their pass or fail status.
2. The reactions of each receiving mail server to unauthenticated messages.
3. The total DMARC pass rate percentage.

There's an optional reporting tag, ruf=, directing ISPs where to send fail or forensic reports. Despite not being universally supported due to data reasons (Gmail stands out), it offers more profound insight into the content of failed emails than a standard aggregate report.

These reports help you refine your DMARC policy. If most messages pass through the email receiver's servers successfully, you may want a stricter policy to detect spoofers. Everyday report analysis and troubleshooting are essential.

DMARC Setup

1. Get Your Domain Ready For DMARC Setup

Activating SPF & DKIM for your domain, DMARC requires activated SPF and DKIM. For SPF, add a DNS TXT record from your ESP settings to your DNS provider. For DKIM signatures, copy the DKIM record from your ESP and paste it into your DNS provider's TXT DNS file.

📘

All Bloomreach clients have SPF and DKIM values.

Create a dedicated mailbox for reports. You'll receive XML reports tracking emails across locations and ISPs. These can accumulate quickly, so create an independent mailbox. Depending on your organization's size, consider a third-party service to manage and decipher these reports.

Audit Your Sending Domains As your DMARC reports arrive, having your list of sending domains ready can help identify legitimate from fake ones. It's helpful to audit your domains beforehand, which will save you time, especially for larger teams.

2. Select a Policy

With DMARC, email senders dictate their authentication policy, defining actions for non-matching domain name messages, much like a traffic light system. You aim to transition your policy from 'none' (green) to 'quarantine' (orange) and, finally, to 'reject' (red).

a. None: The p=none tag doesn't alter your current setup; the inbox provider continues as usual. This is an excellent starting point to monitor initial DMARC reports safely. Note that BIMI doesn't support p=none.

b. Quarantine: The quarantine policy sends unqualified mail to the spam folder until you verify the origins—a handy initial approach.

c. Reject: p=reject is DMARC's ultimate goal. However, choosing it too soon may cause legitimate emails to bounce. Implement a reject policy after a thorough report analysis.

Volume Regulate your authentication rollout by applying your policy to a small message percentage at first, e.g., pct=5. Adjust this value based on your time, resources, and risk tolerance. A gradual increase is a safe approach; otherwise, the default volume is 100%

3. Post Your TXT Record

After defining your DMARC policy, it's time to publish.
Visit your domain host's DNS settings in the management console. Enter the record name (_dmarc.yourdomain.com) under the DNS hostname. Input your DMARC record under the DNS record value (refer to the "Understanding the Record" section). Save your changes.

4. Examine Your Reports

With a DMARC record installed, reports arrive in your mailbox, indicating which messages pass or fail SPF and DKIM authentication. A typical raw XML DMARC report looks like this:

XML files are primarily for machine-reading and can be challenging for human interpretation. To make these reports clearer, you can:

1. Transform the records into a tabular format using a relational database.
2. Change XML to HTML using an XSL style sheet.
3. Employ a third-party SaaS provider to handle and analyze your reports.

With the record clear, you should recognize the IP addresses as your own. Yet, remembering all the IPs from your third-party apps might be challenging. In dealing with these email streams, follow a three-step process:

1. Asses: Audit your sender IPs and correlate with the IPs on your reports.
2. Remediate: Apply DMARC records to all confirmed sending sources.
3. Maintain: Confirm a successful rollout and troubleshoot if necessary.

5. Gradually Implement Your Strategy

Your DMARC policy should evolve progressively from p=none to p=quarantine and, finally, to p=reject. It allows for data collection and careful report analysis. A safe rollout could look like this:

1. v=DMARC1; p=none; pct=100; rua=mailto:[email protected]; Here, messages are delivered as usual, and reports are generated, helping identify trusted senders. Collect data for about six weeks before progressing.
2. v=DMARC1; p=quarantine; pct=5; rua=mailto:[email protected]; Gradually increase the pct= value as you gather data until you reach 100%. Once satisfied with message quarantining, move to the next step.
3. v=DMARC1; p=reject; pct=5; rua=mailto:[email protected]; Keep increasing the pct= value gradually, ensuring all legitimate emails make it to the inbox. Once you reach 100%, you successfully and securely execute your DMARC implementation.