What is DMARC?

DMARC uses Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) to evaluate the authenticity of email messages. Together, these tools prevent practices like phishing and domain spoofing. Phishing is a cybercrime in which someone poses as a credible entity—like a bank or a governmental agency or even your own employer—to try and gather sensitive information, like your credit card information or social security number. Domain spoofing is a form of phishing that entails using a fake email address or domain to appear legitimate.

DMARC allows domain owners to define how an email that appears to be sent from that domain gets handled if it doesn’t include the right information. For example, unauthenticated emails can be blocked or sent straight to a junk folder based on settings placed in the records for that email address’s domain.

Why is DMARC important?

Spammers and phishers have a lot to gain from compromising user accounts. By gaining access to passwords, credit card information, bank accounts, and other financial instruments, malicious actors can easily get access to their victims’ money before their victims are even aware they’ve been scammed.

Email is a particularly attractive and common target, especially for spoofing. Even something as simple as inserting the logo of a well-known brand into an email can trick some recipients into believing they’ve been sent a legitimate communication.

DMARC works to solve this problem at scale. Realistically, free email services like Google, Yahoo, or Hotmail can’t inspect every email that passes through their servers to determine which ones to allow and which ones may be fraudulent.

SPF and DKIM records can help, but these processes have limited scope on their own. When used with DMARC, these protocols help senders and receivers collaborate to better secure emails.

DMARC provides 3 major benefits: security, reputation, and visibility.

Security

Along with protecting customers, using DMARC benefits the email community as a whole. By establishing a framework for a consistent policy to deal with unauthenticated emails, DMARC helps the email ecosystem become more trustworthy and secure.

Reputation

DMARC protects brands by serving as a gatekeeper—it prevents bad actors from spoofing your domain and sending out emails that appear to come from your brand. Publishing your DMARC record can result in a boost to your reputation.

Visibility

DMARC gives you more insight into your email program at a high level, letting you know the identity of everyone who sends email from your domain.

SPF

SPF helps detect forgery by reviewing an email’s listed return-path address. This email address is also referred to as the Mail From or the bounce address.

When an email can’t be sent to its intended recipient after several attempts or a delay, a notification of that failure is usually sent to the return-path address.

Here’s how the return-path address is used to help authenticate email.

How SPF Works

Domain owners can decide which mail servers their domain is allowed to send from when they set up their SPF protocols.

1. SPF information is entered into a TXT record to define the mail servers authorized to send email for a domain.
2. An inbound mail server receives a new email and checks the written rules for the domain of the return-path email address. The inbound server compares the IP address of the mail sender with the domains and/or IP addresses defined in the SPF record.
3. The receiving server uses the rules specified in the sender’s SPF record and determines whether it should accept, reject, or otherwise flag the message.

DKIM

DKIM is an email authentication technique that ensures email content is kept safe from tampering, using an encrypted digital signature. DKIM signatures are added as headers to email messages and secured with public key cryptography.

When a receiving server determines that an email has a valid DKIM signature, it can confirm that the email and attachments have not been modified. This process is not typically visible to end users such as the intended recipient of the email message.

How DKIM works

Here’s how DKIM signatures are validated:

1. The domain owner publishes a unique cryptographic key, formatted as a TXT record within the domain’s DNS record.
2. When a message is sent by an outbound server, it generates and attaches a unique DKIM signature to the header.
3. Inbound servers receive an encrypted hash of the message body.
4. The receiving server first locates the DKIM public key that’s referenced in the DKIM signature and stored in the DNS records.
5. The key is used to decrypt the hash and then generate a new hash of the message body and compare it to the original included by the sender.
6. If the two hashes match, they can validate that the message wasn’t altered in transit.

A record

The type of DNS record that points domains to an IP address is called an address record. When using IPv4 addresses, this record is referred to as an A record.

If you were to visit mailchimp.com, your browser would ask a nearby DNS server if it has the IP address of mailchimp.com. If it does have the IP on record, it sends it to your browser. If not, it tells your browser where it can find another DNS server that has it, and so on until the IP is relayed to you along with the website.

CNAME record

A CNAME (Canonical Name) record is a type of DNS record that maps an alias name to a true (canonical) domain name. CNAME records usually map a subdomain like “www” or “mailto:” to the domain that hosts that subdomain’s content. For example, a CNAME record can map the web address www.mailchimp.com to the website for the domain mailchimp.com.

You can add a CNAME record to your DNS settings if you want to customize a web address, verify domain ownership, reset your admin password, and much more.

• Senders with multiple systems sending email faced a great deal of complexity trying to work with SPF and DKIM.
• When a mix of authenticated, unauthenticated, and unaligned emails are sent from the same domain, receiving servers have to discern which are legitimate and which may be fraudulent. This tends to trip up spam algorithms, leading to fraudulent messages winding up in inboxes.
• With SPF and DKIM, senders get little feedback on their email authentication deployments. Unless the email bounces back, senders have no way of knowing how many legitimate messages are sent unauthenticated or the scope of fraudulent emails being sent from their domain.
• Even when senders have secured their email authentication infrastructure, email receivers are programmed to accept some unauthenticated messages because it's possible that legitimate messages without signatures are passing through.

To solve these problems, senders and receivers must share information with one another. Ideally, receivers supply senders with reporting information, while senders tell receivers what to do when they receive unauthenticated messages.

DMARC is based on the idea of the sender and receiver collaborating to improve senders’ email authentication practices and to enable receivers to reject unauthenticated messages.

DMARC fits in existing inbound email authentication processes. It helps receivers determine if a message aligns with what it knows about a sender.

1. A user writes and sends an email.
2. The sending server inserts a DKIM header.
3. The sending server sends the email to the receiver.
4. The email passes through standard validation tests (IP blocklists, rate limits, reputation tests, and so on).
5. The receiving server retrieves verified DKIM domains based on the header, an “envelope from” via SPF, and applies DMARC policies, passing the email through, quarantining, or rejecting the email and sending a report to the sender’s server. Put another way, we can say that at this point, the receiving server is seeking a “yes” answer to 3 key questions:
   • Does the DKIM signature validate?
   • Did the message come from an accepted IP address according to the SPF record?
   • Do the message headers show the right domain alignment?
6. The email passes through anti-spam filters and undergoes other standard processes.

In this way, DMARC satisfies several requirements at a high level:

• Fewer false positives
• Robust authentication reporting
• Reduced phishing
• Working at high-capacity scale

While not all receiving servers perform a DMARC check before allowing a message to get through, major ISPs typically do. DMARC adoption is growing.

Checking a domain for a DMARC record can be done from the command line of a terminal window. For example:

dig txt dmarc.mailchimp.com

As an alternative, DMARC.org provides a list of other commercial companies offering DNS record lookup and parsing, including tools for reviewing DMARC.

Here is Mailchimp’s DMARC record:

v=DMARC1; p=reject; rua=mailto:19ezfriw@ag.dmarcian.com; ruf=mailto:19ezfriw@fr.dmarcian.com

The DMARC record is stored at the dmarc subdomain of mailchimp.com as a TXT record. It displays several pieces of information about the domain that will influence how an email sent from this domain will be treated by receiving email servers.

v=DMARC1

The receiving server looks for the v=DMARC1 identifier when it scans a DNS record for the domain sending the message. If the receiving server does not find this tag, it will not run a DMARC check.

p=reject, p=none, p=quarantine

The p here stands for “policy.” Domain holders can select from 3 policies to advise the receiving server on what to do with mail that doesn’t pass SPF and DKIM but claims to originate from your domain.

• p=none tells the receiver to perform no actions against unauthenticated mail, but instead to send email reports to the mailto: address listed in the DMARC record.
• p=quarantine tells the receiver to quarantine unqualified messages (for example, by sending it straight to a junk or spam filter instead of an inbox).
• p=reject tells the receiver to deny unqualified mail. Only verified email will make it through to an inbox. Mail that is rejected is simply denied entry.

rua=mailto:

This section tells the receiving server where it can send aggregate DMARC reports. Reports include high-level information about DMARC issues but are not very detailed.

ruf=mailto:

Similar to rua=mailto:, ruf=mailto: tells the receiving server where it can send forensic (detailed) reports about DMARC failures. These reports are sent in real time to the administrator of the domain and include details about each incident.

fo=

This section displays one of several values related to forensic reporting options:

• 0 generates reports when all authentication mechanisms fail to produce a DMARC pass result
• 1 generates reports when any mechanism fails
• d generates reports if DKIM signatures fail to verify
• s generates reports if SPF fails

sp=

When an optional sp= value is listed in the DMARC record, it tells the receiving server whether it should apply DMARC policies to subdomains.

adkim=

Also an optional value, adkim= sets the DKIM alignment to either s (strict) or r (relaxed). Strict means the DKIM portion will pass only when the d= field in the DKIM signature matches the from address exactly. The relaxed setting allows messages to pass the DKIM portion if the DKIM d= field matches the root domain of the sender’s address, and is implicit if adkim= is not specified in the record.

As an example, in relaxed mode, mail.mailchimp.com, mx1.mail.mailchimp.com and mailchimp.com would all align with each other, as they share the same organizational domain (mailchimp.com). In strict mode, each can only align with themselves ( mailchimp.com would only align with mailchimp.com).

ri=

You might also see the ri= value when examining a DMARC record. This value sets the interval for the preferred frequency of aggregate reports as listed in rua=mailto:.

aspf=

Another optional value, aspf= sets the strictness required for SPF alignment to either s (strict) or r (relaxed). Strict means that SPF will align only when the Mail From domain (also called the SPF from, envelope from, or bounce address) matches the header from (also known as the “friendly from”) exactly. The relaxed setting allows SPF to align if the Mail From domain and header from domain share the same organizational domain.

For example, when aspf is set to relaxed, mail.mailchimp.com, mx1.mail.mailchimp.com, and mailchimp.com would all align with each other, as they share the same organizational domain (mailchimp.com). Like adkim, aspf defaults to relaxed.

pct=

Using this optional value allows a domain owner to test the impact of their DMARC on sending by setting a percentage on how many emails are sent with a particular policy. This can be useful when first implementing DMARC to measure the difference in email delivery success for email sent from your domain. As an example, p=reject; pct=50 means that 50% of emails are subject to the strictest policy, while the remaining 50% are subject to the next strictest policy (quarantine, in this case.)

DMARC.org, a nonprofit initiative aimed at promoting the use of DMARC, recommends deploying DMARC by following these 5 steps:

1. Deploy SPF and DKIM.
2. Check to make sure your mailers are aligning with the appropriate identifiers.
3. Publish a DMARC record with the “none” flag to trigger data reports.
4. Analyze the data and make modifications as appropriate.
5. Modify DMARC policy flags to “quarantine” or “reject” as you gain experience. Use pct= to set a percentage on policy flags to test their impact on delivery.

DMARC.org stresses that deploying DMARC isn’t as easy as simply flipping a switch, but using this method can help everyone involved ease into a full deployment over time.

Once you’ve deployed DMARC, you can test it at the National Institute of Standards and Technology Email Authentication Tester page. This resource will also let you test SPF and DKIM, which can be helpful for troubleshooting.

DMARC limitations

DMARC is a robust technique for reducing the likelihood of email spoofing and phishing, but it does have a few limitations. One of the most significant is that it can’t combat spear phishing attacks using Display Name Imposters (DNI), which make up a large percentage of email fraud attempts.

Also, DMARC is unable to protect against look-alike domain spoofs. DMARC should be used in conjunction with other protocols for protection against email fraud.

DMARC is complex, as well. Companies with large IT talent pools have an advantage here. But there are many resources out there to teach anyone how to deploy DMARC. It may be a large time commitment, but domain owners who want to mitigate vulnerabilities in their email systems will find it worthwhile to put in the time.

It’s hard to say how many organizations will ultimately use DMARC, though the numbers are growing steadily. Considering that the vast majority of successful data breaches originate with email, though, it’s clear that we’ll all be better off when DMARC usage is widespread.