What Is DMARC in Email (Understanding DMARC Records)? (2024)

What Is DMARC? Understanding DMARC Records

Email marketing is full of obscure acronyms that can be confusing to understand—and DMARC is no exception.

Domain-based Message Authentication, Reporting & Conformance or DMARC is an email security measure that protects your domain against hacker attacks. We’ll explain DMARC here and how it’ll help you control email deliverability and protect your brand reputation. Still with us? Let’s dive in.

What is DMARC in email?

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It's an email authentication protocol that adds an extra layer of security to the email verification process to combat email spoofing.

DMARC is designed to give email domain owners the ability to protect their domain from unauthorized use, commonly known as email spoofing. Email spoofing is a tactic used in phishing attacks and other cyber threats, where the attacker disguises an email to make it appear as if it's coming from a legitimate source. This is done to deceive recipients into disclosing personal information, downloading malware, or engaging in other actions that can lead to security breaches.

DMARC uses other standard authentication protocols—like Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM)—to help administrators catch emails sent by cyberattackers that impersonate a legitimate organization. This practice is spoofing and is possible because the attacking email’s "from" address appears identical to a legitimate domain.

• SPF (Sender Policy Framework) allows domain owners to specify which email servers are permitted to send email on behalf of their domain. When an email is received, the receiving email server checks the SPF record to verify that the email comes from an authorized server.

• DKIM (DomainKeys Identified Mail) involves adding a digital signature to outgoing emails. This signature is validated against a public key in the domain's DNS records, confirming that the email content hasn't been tampered with during transit.

• DMARC ties SPF and DKIM together by allowing domain owners to specify a policy in their DNS records that dictates how receiving email servers should handle emails that fail SPF and DKIM checks. DMARC also provides a mechanism for reporting back to the domain owner about emails that pass or fail these checks, giving insights into potential authentication issues or spoofing attempts.

How does DMARC work?

• SPF
• A record
• CNAME
• DKIM

It’s also crucial to note that not all receiving servers will perform a DMARC check before accepting a message, but all the major ISPs do—and implementation of DMARC checks continues to grow. Learn more about the ins and outs of DMARC.

What are the benefits of DMARC?

There are 4 main reasons you'd want your DNS server administrator to add your DMARC record and start monitoring your domain:

1. To protect your sending reputation: DMARC protects your brand by preventing unauthenticated parties from sending mail from your domain. In some cases, simply publishing a DMARC record can result in a positive reputation bump.
2. To improve email program visibility: DMARC reports increase visibility into your email program by letting you know who sends email from your domain.
3. To secure future email deliverability: DMARC helps the email community establish a consistent policy for dealing with messages that fail to authenticate. This helps the email ecosystem become more secure and trustworthy—and helps you stay off spam denylists.
4. To display your logo with BIMI: DMARC lets you send Brand Indicators for Message Identification (BIMI) specification messages containing your brand’s logo. In doing so, your emails can enhance your brand recognition and be more visually appealing to customers with supported email clients.

What does a DMARC record look like?

Breaking down how DMARC authentication works

Here’s an in-depth code breakdown of how DMARC works:

“v=DMARC1”

This sample indicates the version identifier that the receiving server looks for when scanning the DNS record for the domain that sent the message. If the domain doesn’t contain a text record beginning with “v=DMARC1,” the receiving server won’t run a DMARC check.

“p=none”

This is the policy the user selects in your DMARC record that tells the participating recipient email server what to do with mail that doesn’t meet SPF and DKIM standards yet claims to be from your domain. In this case, the policy will be “none.” There are 3 policy types:

1. p=none: This type instructs the receiver not to perform any actions against unqualified mail but to continue sending email reports to the “mailto:” in the DMARC record for any infractions.
2. p=quarantine: This command tells the receiver to isolate unqualified mail, typically to the spam folder.
3. p=reject: This policy has the receiver deny all unqualified mail intended for the domain when enabled. Instead, only mail verified as signed by your domain can attempt to reach the inbox. All other mail gets denied to mitigate any false positives.

“rua=mailto:dmarc@sendgrid.com”

This script segment containing a “mailto:” email address of your choosing shows the receiving server where to send aggregate reports of DMARC failures. These reports contain high-level, nongranular information on DMARC failures and get sent daily to the domain administrator holding the DMARC record.

“ruf=mailto:dmarc@sendgrid.com”

This sample tells the receiving server where to send forensic reports on DMARC failures. These forensic reports contain details concerning each failure and get sent in real time to the domain administrator that owns the DMARC record. Unlike with the “rua” sample, the “mailto:” email address must be from the domain the DMARC record that published it.

“rf=afrf”

This is the formatting that tells the receiving server the policyholder’s desired reporting approach. Here, “afrf” means “aggregate failure reporting format.”

“pct=100”

This segment tells the receiving server how much incoming mail must conform to the DMARC policy’s specifications as a percentage value from 1–100. In this case, if the “p=” is 100%, all mail that fails the DMARC check gets rejected. Conversely, when set to 1%, only 1% of failing mail gets rejected—and so on.

But that’s just the beginning. There are many other notable mechanisms to include in a DMARC record. Here are a few:

“sp=”

This command decides whether the receiving server should apply the DMARC policy to subdomains.

“adkim=”

This sets the DKIM portion of DMARC authentication to either “s” for strict or “r” for relaxed. The strict setting ensures DKIM will only pass if the “d=” field in the signature precisely matches the “from” domain. When set to relaxed, messages will pass DKIM only if the “d=” field matches the root domain of the “from” address.

“ri=”

Remember to set the interval for how often you want to receive aggregate reports about DMARC failures.

How do I implement DMARC with Twilio SendGrid?

2. Verify proper DKIM and SPF signing for your allowed domain

3. Publish a DMARC record with your DNS registrar and monitor the results

Create a TXT resource record that email receivers can use to determine your DMARC preferences within your DNS registrar. You can accomplish this task within the domain host’s DNS registrar, which is likely in the same location where you created the records for the sender authentication—at the domain’s root level, not the subdomain.

4. Analyze received feedback and adjust your mail streams as needed

Keep in mind that an unqualified email sent to and received from a DMARC-participating recipient result in their email client doing the following:

• Generating reports for the messages
• Returning them to the “mailto:” address specified in your DMARC record

5. Escalate your DMARC policy tags as you learn more

Implement DMARC with Twilio SendGrid to level up your email security