If you send a lot of emails as part of your work or if you own a website domain, you need to know about DMARC. It protects outbound emails that an organization sends or has others send on its behalf with the help of DMARC software.

Think about the following questions: What insight or control do you have on the email that has a ‘from’ address claiming to be from your domain? Where are these messages being delivered? Are they destined for your customers, business partners, and perhaps even your employees’ personal email addresses trying to dupe them? Add to that, are you confident your emails are reaching inboxes without getting flagged as spam?

The reality is that it’s very simple (and cheap) for scammers to send an email posing as you, and this email spoofing can wreak havoc on your inbox deliverability and reputation.

DMARC ensures this doesn’t happen to your business. We’ll outline the technology and how simple it is to deploy and phase into an organization.

How does DMARC prevent spoofing?

Imagine getting an email from soundaryaspoof@g2.com that looks just like an email I would send when this email ID doesn’t even exist on our domain.

If you don’t read the ID fully, you might see an email similar to one that I would sent, click on a link there, and lose data or money. If you do read the email ID fully, you might not get phished and you might mark the ID as spam. No harm done. But a surge of spoofed emails marked spam can damage the reputation of our domain g2.com, making even legitimate emails from my G2 ID end up in spam folders.

DMARC helps avoid this. It specifies what an email service provider like Gmail or Yahoo should do in case of email spoofs or phishing attempts. It also helps the organization, here G2, to know that someone’s sent a phishing mail using our domain name.

Here’s the technical breakdown of how this works: 

1. The domain owner creates a DMARC record and publishes it in their DNS records. This record specifies:

• Whether SPF and/or DKIM authentication is used for your domain.
• DMARC alignment: How closely the domain identified in the “From:” header of the email needs to match the domain used in the SPF or DKIM authentication. 
• DMARC policy: What action should receive servers take for emails that fail the SPF/DKIM checks?
• Where to send DMARC reports for analysis (often to a DMARC reporting service).

When an email is sent from the domain, SPF and/or DKIM verification happens behind the scenes.

• The receiving mail server checks the DKIM signature to confirm the email content hasn’t been tampered with.
•  They check the SPF record to verify that the email is sent from an authorized IP address for the domain.

4. If the email passes both SPF and DKIM checks or one of the checks aligns with the DMARC policy, the email is delivered normally.

5. If the email fails the checks, the receiving server refers to the DMARC policy to determine what to do with it – to reject it completely and not deliver it, to mark it as spam, or to send it normally but share a report with the mail administrator. 

6. The receiving mail server sends aggregate reports to the address specified in the DMARC policy. These reports contain information about the emails that were received, whether they passed or failed the authentication checks, and how they were handled.

Depending on the stage of your implementation of DMARC, you can start by simply observing the email that is sent by your domain and then advance to take certain actions on the email based on whether the sender meets certain criteria.

Let’s examine in detail the important component of DMARC: the DMARC record.

What is a DMARC record? 

A DMARC record is a DNS TXT record and consists of several variables. In its most basic form, a DMARC record contains two tags: version (v) and policy (p).

1. Version (v): indicates the DMARC protocol version. The value is always “DMARC1”. This tag is compulsory.
2. Policy (p): defines the DMARC policy for handling emails that fail DMARC checks. 

   Possible values of DMARC policy

   • p=none: No specific action is taken; the email is delivered as usual, but it’s logged in the daily DMARC report sent to the address mentioned in the rua tag. The tag is used primarily for monitoring purposes.
   • p=quarantine: The email is treated as suspicious and may be marked as spam or placed in a quarantine folder.
   • p=reject: The email is rejected and not delivered to the recipient.

Here’s an example of the most basic DMARC record:

This record indicates that the DMARC protocol version is DMARC1, and the policy is set to “none,” meaning no specific action is taken on emails that fail DMARC checks. 

While the version value and policy are the bare minimum, a DMARC policy supports seven additional tag values. 

• Aggregate report (rua): designates the email address to which XML documents on email messages claiming to originate from a specific domain are sent to. They contain machine-readable data such as authentication results and message disposition. 
• Forensic report (ruf): specifies the email address to submit detailed failure or forensic reports on email traffic
• Percentage (pct): specifies the number of emails to be filtered, indicated as a value between one and 99. No percentage value indicated assumes 100%, meaning DMARC policy applies to all messages sent from your domain. 
• Subdomain policy (sp): Subdomain policy represents the requested handling policy for subdomains. As an example, v=DMARC1;p=reject;sp=none puts the parent domain at p=reject but p=none will apply for any subdomain. Without this value, it is assumed that all subdomains inherit their parent domain policy.
• DKIM identifier alignment (adkim):  It can take the value Relaxed “r”, or Strict “s”. In relaxed mode, if the DKIM record being verified belongs to the domain and the message is sent from email@news.example.com, the verification will pass. In strict mode, the check will be passed only if the sending comes from an address on the domain specified. Subdomains will not pass DKIM validation.
• SPF identifier alignment (aspf): It can take the value Relaxed “r”, or Strict “s”. In relaxed mode, if the SPF record being verified belongs to the domain and the message is sent from email@news.example.com, the verification will pass. In strict mode, the check will be passed only if the sending comes from an address on the domain specified. Subdomains will not pass validation.
• Failure reporting options (fo):  ‘fo=0’ sends reports if DKIM and SPF don’t pass or align. ‘fo=1’ sends reports if DKIM or SPF don’t pass or align. ‘fo=d’ sends reports only if DKIM doesn’t pass or align. ‘fo=s’ sends reports only if SPF doesn’t pass or align.

Example of DMARC record

Here’s another example of a basic DMARC record:

This record specifies:

• The DMARC version (v=DMARC1)
• The main policy to quarantine emails that fail authentication (p=quarantine)
• The subdomain policy to take no specific action (sp=none)
• Aggregate reports should be sent to dmarc-reports@example.com.
• Forensic reports should be sent to dmarc-forensic@example.com 
• Both SPF and DKIM alignment modes are strict (aspf=s and adkim=s).
• The policy is applied to 100% of the emails (pct=100).

You might now doubt what exactly is the aggregate report or DMARC report we are referring to here. Let’s look at it.

What is a DMARC report? 

DMARC report is the detailed document generated by the receiving email server and sent to the email ID mentioned in your rua tag. The report reveals:

• how many emails passed or failed SPF and DKIM authentication
• the sources of these emails (sender IP addresses and domains)
• what actions did the receiving servers take for unauthenticated emails based on your DMARC policy

DMARC reports are typically sent in XML format and contain technical details. However, DMARC reporting services often provide user-friendly interfaces to interpret the data.

Comparing DKIM, SPF, and DMARC

DKIM, SPF, and DMARC are three email authentication methods. Comparing them helps us understand how each works, its purposes, and how they complement each other to provide comprehensive email security. 

DKIM

DKIM, as mentioned earlier, focuses on verifying the integrity of the email content. It employs public key cryptography to ensure that an email message was sent from an authorized mail server, detect forgeries, and prevent sending harmful spam emails. Here’s how it works.

The domain owner configures their mail server to sign outgoing emails with a private key and publishes a public key in the DNS. The receiving mail server uses the public key to verify the email’s DKIM signature, ensuring the email has not been tampered with and was sent by an authorized server.

SPF

SPF focuses on verifying the sender’s identity. A domain administrator publishes an SPF record as part of the domain’s overall DNS records, listing the IP addresses of mail servers that can send email from that domain. 

When an email is received, the receiving mail server checks the SPF record of the sender’s domain to verify if the email is sent from an authorized IP address.

Limitations of DKIM and SPF

DKIM and SPF were introduced over a decade ago and provided a way for domain owners to allow other organizations to send emails on their behalf, otherwise known as “sources.”

However, these security protocols fell short on a couple of things. First, an organization is blind to how often and where DKIM and SPF are (or are not) working. This is where the reporting aspect of DMARC came into play and established a standard format for mail handlers to compile information about this activity and where to send the reports. 

The second shortcoming specifically addresses DKIM and SPF failed authentication. Before DMARC, an organization was entirely dependent on the recipient’s inbound mail gateway to take the necessary action against an email that fails a DKIM or SPF check. With DMARC, the domain owner gets the first say in instructing the mail handler on a specific course of action. 

The DMARC authors saw that an organization was blind to DKIM and SPF’s effectiveness. They also recognized that an organization was doubly blind to legitimate mail that was failing authentication or possibly sketchy emails that failed authentication still weaseling their way through to the unsuspecting victim. 

In the spring of 2011, top organizations such as PayPal, Google, and Yahoo! Mail came together to collaborate on a strategy for combating fraudulent email. To this day, these same prevalent forces support and recommend DMARC to avoid harmful email practices like phishing and Business Email Compromise (BEC).

The DMARC protocol was initially created as an email security system and was primarily used by security specialists in the finance industry. Since then, DMARC adoption has increased and become more widespread across the internet. DMARC is now pending approval by the Internet Engineering Task Force to become an open standard (IETF). 

How does DMARC work with DKIM and SPF?

DMARC oversees the entire email authentication process and provides reporting. It allows domain administrators to define a policy for how receiving email servers should handle emails that fail SPF and/or DKIM checks and provides a reporting mechanism. 

While SPF and DKIM can function independently without relying on a DMARC policy, it’s not recommended to have a DMARC policy without SPF or DKIM. 

3 core benefits of DMARC 

When DMARC is implemented, domain owners gain visibility into how their domains are being used on the Internet, delivery is improved, and phishing is eliminated. Let’s discuss these benefits in more detail. 

1. Visibility

At the policy value of “p=none,” DMARC is in an observation stage. It gives you insight into how, when, and where your domain is being used for email across the globe. Having DMARC implemented in this stage will disclose insightful information, including:

• Who is sending from your domains? (both legal and illegal sources)
• How many emails does each source send?
• From what IP address and PTR record are the sending from?
• Which sources are sending emails that aren’t authenticated?
• Which authentication method is broken (SPF, DKIM, DMARC)?

At this stage, you’re not taking any action against email deliverability. You are simply enabling an in-depth overview of who is using your domains and where you need to authenticate sources that are sending on your behalf. Only when the reports are validating that your sources are authenticated, should you proceed to the next phase of DMARC, which secures your domains.

2. Security

Once you have confidence you have established a means of SPF and DKIM authentication for your sources, a DMARC policy can move from an observation state of ‘p=none’ to ‘p=quarantine’. This policy state instructs receiving email systems to flag messages that don’t pass authentication as junk. 

While this does not technically protect your domain from phishing, by flagging the message as junk, the recipient either never sees the message or is warned of its diminished authenticity.

After a period of time being in the ‘p=quarantine’ state and at the same time ensuring that you are not impacting any valid email, you may take advantage of the ‘p=reject’ policy. In this stage, you are instructing mail handlers to reject the receipt and delivery of this message outright. The recipient never receives the email, as it is not delivered per your instruction. 

3. Deliverability

There is an inherent benefit in establishing SPF and DKIM authentication and advancing your DMARC policy to either ‘p=quarantine’ or ‘p=reject’. Aside from the obvious protection of your domain, you have made every mail handler’s job across the globe a little easier.

If there are around 300 billion emails sent every day, of which 75 to 85 percent are junk or threat emails, you have made the email handler’s job much easier by allowing them to discard the junk. Thus, between the authentication and the mail handler promoting your sending capability, an advanced DMARC policy state will improve your organization’s email deliverability rates. 

Why is DMARC necessary? 

Hackers are always seeking new ways to penetrate networks through phishing, spoofing, whaling, and other social engineering techniques. When you combine the fact that spoofed email is cheap and easy to send with the fact that users struggle to spot fake emails, you have a hacker’s favorite tool to penetrate an organization. 

It’s no coincidence that the FBI’s Internet Crime Report found that phishing topped its list of 2023 cybercrimes. Further, the business email compromises alone cost companies nearly $3 billion. 

DMARC is an important step in protecting your domain and your brand by preventing malicious actors from impersonating your domain in emails. It may also improve your sender reputation scores, which can positively impact deliverability rates. DMARC adds confidence that the sender’s domain is accurately represented in the “header from.”

Adopting DMARC promotes an industry standard for dealing with unauthenticated emails, thereby protecting all email users from spoofed malicious emails.

Moreover, industry heavyweights like Google and Yahoo! have made DAMRC compulsory for all bulk email senders since February 2024. So, it is absolutely essential to have a DMARC policy in place for security and compliance.

Beyond DMARC: BIMI 

Any article discussing email security standards like DMARC is incomplete without mentioning Brand indicators for message identification or BIMI.

BIMI is the latest email security protocol developed by AuthIndicators Working Group that includes Google, Yahoo!, Twilio SendGrid, Valimail and more. takes email authentication a step further and complements DMARC. It essentially allows the sender to place their trademarked and certified logo next to the ‘from’ address in the recipient’s mail client. The intent is to instill confidence in the recipient to feel that the message is authentic. It’s important to note that BIMI is an emerging technology with its RFC specification in draft mode.

There have been several techniques for validating senders and employing logos for years, with the first formalized BIMI spec published in February 2019. The AuthIndicators Working Group was created to formalize and promote BIMI throughout the industry. Participants from Google, Fastmail, LinkedIn, Validity, Mailchimp, Verizon Media, and SendGrid are part of the group. With that said, Yahoo!, Google, Verizon, and Fastmail all publicly announced their support of the technology in 2021, and its adoption rate is growing.

With BIMI, you have complete control over the logo that is displayed, allowing you to maintain control over your brand and subscriber experience, all while building trust. There are several factors that must be implemented and aligned for BIMI to work: 

• The sender’s DMARC record must be in a state of quarantine or reject
• The recipient’s email client must support this functionality
• The sender must publish a DNS record, including a URL to their logo in SVG format
• The mailbox provider must be able to validate the BIMI record in the “From” domain’s DNS TXT record. That record is a URL for your brand’s logo and Verified Mark Certificates (VMC). If the records are identical, the logo is displayed.

How do BIMI and DMARC work together?

Mail providers that support BIMI will look up the BIMI file for the incoming message by querying the domain. The BIMI file refers the receiving email server to the brand logo and shows it in the inbox once the email passes DMARC verification.

Signed, sealed, delivered

Email security protocols continue to evolve. First came DKIM as an “internet standard,” followed by SPF, DMARC, and, most recently, BIMI. Perhaps the only consistent thing they have in common is their enemy, the inherent security flaws in emails. 

There was a time when the question may have been “Do I need DMARC to protect my domain?” That’s now replaced with a more relevant question: “What provider will allow me to implement and monitor these crucial email security protocols and have the skills to adapt their platform to the ever-changing email security landscape?

If you are asking this question, select a partner from the list above that prioritizes staying ahead of emerging standards to ensure your email remains secure and compliant. 

Need more protection? Explore different email security software to find the right solution that fits your business needs. 

This article was originally written in 2021. It has been updated with new information.