DMARC is a crucial part of an overall email security strategy – not just another cybersecurity acronym. 

DMARC protects outbound emails that an organization generates, or has others generate on their behalf. DMARC has multiple, compelling benefits. We’ll outline the technology and how simple it is to deploy and phase into an organization. 

This guide is not about securing your users from inbound email. Instead, it’s a guide to email security protocols that protect your outbound email and your domain. What insight or control do you have on the email that has a ‘from’ address claiming to be from your domain? Add to that, where are these messages being delivered? Are they destined for your customers, business partners, perhaps even your employees’ personal email addresses trying to dupe them? 

The reality is that it’s very simple (and cheap) to send an email posing as someone else, very well known as “phishing”. It’s no coincidence that the FBI found that email compromises topped its list of 2020 cybercrimes contained in its Internet Crime Report.

The Email Compromise category not only topped the list, it was greater than the combined loss of the six subsequent categories. Therefore, it’s vital that your organization’s Cybersecurity strategy include the ability to monitor and restrict the use of your domain name when it’s used for email. 

What is DMARC?

Domain-based Message Authentication, Reporting, and Conformance (DMARC), is a set of instructions in DNS that tell mail handlers across the globe on how you want to monitor and take action against email that claims to be from your domain. 

Depending on the stage of your implementation of DMARC, you can start by simply observing email that is sent by your domain, and then advance to take certain actions on the email based on whether the sender meets a certain criteria. This criteria is specific to SPF (Sender Policy Framework) and DKIM (DomainKeys identified mail) email security protocols. Simply put, DMARC separates good email sent from your authorized sources from bad email sent as a result of phishing attacks. 

To be clear, this is not a new concept. DKIM and SPF were introduced over a decade ago and provided a way for domain owners to allow other organizations to send email 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, Microsoft, and Yahoo! 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. Aside from the obvious protection of an organization’s customers, brand, and reputation, email marketers also recognize DMARC as a tool to increase email deliverability rates. DMARC is now pending approval by the Internet Engineering Task Force to become an open standard (IETF). 

What is a DMARC record? 

DMARC exists as a DNS TXT record and consists of several variables, only some of which are required, such as the stage of its implementation and where DMARC reports are to be sent. In its most basic form, a DMARC record contains three tags: value, implementation state (policy), and the email address to send reports:

RUA, or “aggregate reports” are XML documents that contain statistical information on email messages claiming to originate from a specific domain. They contain machine-readable data such as authentication results and message disposition. 

While the value, Policy and RUA address are the bare minimum, a DMARC policy supports eight additional tag values. 

Optional tags:

• rua: Additional Report Email Address. DMARC supports up to three targets 
• ruf: Addresses to submit Failure reports 
• pct: Percentage specifies the number of emails to be filtered, indicated as a value between one and 99. No percentage value indicated assumes 100%. 
• 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 any subdomains inherit its parent domain policy.
• adkim=_: DKIM identifier alignment. 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.
• aspf=_: SPF identifier alignment. 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.
• ruf@12345.easydmarc.us: Failure reporting ‘send to’. From the same mail handler you are requesting RUA Aggregate reports, you are requesting that mail handlers send an immediate notification of senders that fail DKIM and/or SPF checks. It is important to note that these reports are immediate (versus every 24 hours) and contain private data: Subject line, from address and the recipient address. Because of the private data, very few mail handlers comply with this request. 
• fo=_: Failure reporting options. ‘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

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. More detail on these core benefits:

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)?

In 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.

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 it’s 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. 

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 is Junk or Threat email, 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, sometimes combined with 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 email, you have a hacker’s favorite tool to penetrate an organization. 

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.

DKIM (Domainkeys Identified Mail) 

DomainKeys Identified Mail (DKIM) is a technical standard that helps email senders and recipients avoid spam, spoofing, and phishing. It’s a type of email authentication that lets an organization claim ownership of a message in a way that the recipient can verify. It employs a technique known as “public key cryptography” to ensure that an email message was sent from an authorized mail server, detecting forgeries and preventing the sending of harmful email such as spam.

This email security standard ensures that messages aren’t altered in transit  between sending and receiving servers. As an email leaves a sending server, it employs public-key cryptography to sign it with a private key. Recipient servers then verify the message’s source and that the message’s body hasn’t changed during transit using a public key issued to a domain’s DNS. The message passes DKIM and is regarded as valid if the receiver server verifies the signature with the public key. It operates by adding a digital signature to an email message’s headers.In general, the procedure is as follows:

In the domain’s overall DNS records, a domain owner publishes a cryptographic public key as a specially-formatted TXT record.When an outbound mail server sends a message, it generates and attaches a unique DKIM signature header to the message.  Two cryptographic hashes, one of specified headers, and one of the message body are included in this header (or part of it). The signature’s header offers information about how it was created.

When an inbound mail server gets an email, it consults DNS to find the sender’s public DKIM key. This key is used by the inbound server to decrypt the signature and compare it to a newly computed version. The message can be proven to be valid and unchanged in transit if the two values match.

How do DKIM and DMARC work together?

DMARC provides domain owners with a way to decide how they want unauthenticated messages to be treated. It employs DKIM and SPF to assess whether a message is valid and whether it should be sent or blocked to the recipient.

SPF (Sender Policy Framework)

Sender Policy Framework (SPF) is an email authentication system that detects forged sender addresses (Return-Path headers) during email delivery. SPF enables the recipient mail server to verify that an email claiming to be from a given domain was sent from an IP address authorized by the domain’s owner during delivery.

Receiving mail servers use SPF to verify that incoming email from a domain was sent from a host approved by the domain’s administrators. It is based on the well-known Domain Name System (DNS). In general, the procedure is as follows:

A domain administrator publishes a policy that defines mail servers that are allowed to send email from that domain. An SPF record is a policy that is listed as part of the domain’s overall DNS records. When an inbound mail server receives an email, it looks up DNS to find the bounce (Return-Path) domain’s rules. The inbound server then compares the mail sender’s IP address to the list of approved IP addresses in the SPF record. 

The receiving mail server then decides whether to accept, deny, or otherwise flag the email message based on the rules given in the transmitting domain’s SPF record.

How do SPF and DMARC work together?

SPF can associate a piece of email with a domain. DMARC relates the results of SPF to the content of email, specifically to the domain found in the return path or From: header of an email, once DNS records are in place. For SPF to work appropriately in the context of DMARC, the return-path address must be relevant to the domain of the From: header, which is the item that binds together DMARC alignment.

Brand Indicators for Message Identification

Brand Indicators for Message Identification (BIMI) 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 for 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 of 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 align in order 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.

Conclusion 

Email security protocols continue to be introduced. First came DKIM as an “internet standard” in 2011. Shortly after, SPF in 2014. Then, in 2015, DMARC with IETF backing. Most recently, BIMI, also with IETF backing. Perhaps the only consistent thing they have in common is their enemy, email, more specifically its inherent security flaws. 

One thing that is comforting is that they all depend on each other. They aren’t independent protocols requiring separate tools to manage each. They are, in fact, deployed in succession and managed together. There was a time where 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?”