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.
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.
DMARC enables email senders to specify how to handle emails authenticated using SPF or DKIM. These senders can then opt to send those emails to the junk folder or block them altogether.
In doing so, internet service providers (ISPs) can more effectively identify spammers and prevent malicious emails from landing in consumer inboxes. DMARC also allows ISPs to minimize false positives and provide better authentication reporting—vastly improving transparency in the marketplace.
Your DMARC record appears alongside your Domain Name System (DNS) records’:
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.
There are 4 main reasons you'd want your DNS server administrator to add your DMARC record and start monitoring your domain:
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.
To improve email program visibility: DMARC reports increase visibility into your email program by letting you know who sends email from your domain.
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.
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.
You can inspect what a DMARC record looks like by typing “< dig txt _dmarc.sendgrid.net >” into yourterminal. Then, checkValimail to view the DMARC record for any domain that has one published.
Here’s an example of Twilio SendGrid’s DMARC record:
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:
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.
p=quarantine: This command tells the receiver to isolate unqualified mail, typically to the spam folder.
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.
If you’ve ever had phishing problems in the past or own a financial business that processes sensitive information (or any business for that matter), enabling DMARC authentication can be a valuable tool. In fact, there’s no disadvantage to implementing a DMARC policy now as a way to preempt future email authentication issues due to cyberattackers.
You should also keep in mind that DMARC aggregate and forensic reports are machine-readable, so it can be difficult for humans to make sense of them. As such, you’ll need to use a DMARC report-monitoring service like Valimail—a SendGrid partner—that can collect the reports and access the information.
Once you’ve decided whether to implement DMARC and have selected the services you want enabled, there are 5 steps to follow to set up DMARC:
Start by completing the sender authentication process for your account. Doing so ensures that emails sent through your SendGrid account will be properly signed using DKIM and SPF for your unique domain.
Send yourself a handful of test emails to confirm everything works correctly. Then, verify that the DKIM and SPF signatures in your email headers match the domain you’re using to allowlist your SendGrid account.
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.
(Note: The listed SPF and DKIM auth_results are raw results, regardless of the “s=” alignment. The file name appears as “filename = receiver “!” policy-domain “!” begin-timestamp “!” end-timestamp “.” extension” (e.g., receiver.org!sender.com!1335571200!1335657599.zip).
Also, keep in mind that aggregate reports get sent as a .zip attachment, so be sure the address you define can accept attachments in this file type.
Now that you’ve tested and tweaked your mail streams to determine who sends email on behalf of your domain, it’s time to turn it up a notch.
Until now, you should have only used the “p=none” policy to get reports of any bad behavior to learn the email origination. Now, it’s time to adjust your DMARC record’s policy to begin controlling how receivers handle mail claiming to be from your domain.
DMARC records are crucial to the evolution of sophisticated email authentication. Plus, these serve as excellent case studies for the importance of email senders and ISPs working together to maximize the security of their email channel.
