DMARC: What It Is + How It Helps Protect Your Brand Against Email Fraud0
In the world of email, it’s surprisingly easy to pretend to be someone you’re not. Almost anyone with a basic understanding of how email works can make a message look like it’s coming from whatever sender they might choose—and of course, scammers take advantage of this.
There’s an infinite number of examples where criminals impersonate a brand, and then use the brand’s trusted reputation to steal personal information or credit card details from email recipients. It’s a marketer’s nightmare.
Thankfully, mechanisms exist that help brands to avoid this type of email fraud: Email authentication protocols.
Domain-based Message Authentication, Reporting & Conformance—or DMARC—is the most recent addition to the list of email authentication protocols. It builds on two existing and widely deployed frameworks, the Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) protocols.
Don’t know your DKIM from your SPF?
We know this can be confusing! Brush up on the email delivery basics before jumping into the nitty-gritty details of DMARC.
What sets DMARC apart from other email authentication protocols—and makes it particularly valuable for each marketer—is its reporting function. With DMARC, you can see who is sending email on behalf of your domain—your brand—and prevent spammers from using it to send fraudulent email.
Understanding email authentication isn’t easy, and in most cases, it isn’t something email marketers can handle all by themselves. Still, as the voice of your brand, every email marketer should have a basic understanding of email authentication and DMARC, and how to use the tools available to help protect your brand from email fraud.
To bring a little more clarity into the confusing world of email authentication, we sat down with Steven Jones, Executive Director of DMARC.org, and asked him everything we ever wanted to know about email authentication and DMARC:
- What is authentication and why should email marketers care about it?
- What is DMARC, how does it work, and what makes it different from other authentication protocols (DKIM and SPF)? How do they work together?
- What are the benefits of setting up DMARC? How does it help protect my brand?
- What can happen if I don’t set it up?
- What do DMARC reports look like? What kind of information do they include?
- Why is DMARC important for Inbox Providers (ISPs), too?
- How many brands and ISPs are already using DMARC?
- If an inbox provider checks incoming email for DMARC but my brand hasn’t set it up yet, can this hurt my delivery rate?
- Do inbox providers attach security warnings to emails from brands that aren’t authenticated? Are email recipients made aware of authentication failures?
- What about domains that don’t send email? Should they be authenticated, too?
- Who is usually responsible for setting up DMARC for a brand—someone in my company or my ESP? Who can help with the technical implementation?
- What does it cost to set up DMARC?
- In addition to DMARC, what other practices do you recommend for protecting against email fraud?
1. What is authentication and why should email marketers care about it?
Email authentication refers to mechanisms or protocols that allow you, or your mail server, to verify that a message using a particular internet domain in the from field really was authorized to use that domain. In other words, if you get a message with a from address of sales@BigBank.com, did BigBank.com really authorize that message?
Different email authentication protocols have been introduced over the past decade. The most popular protocols are:
- Sender Policy Framework, or SPF
- DomainKeys Identified Message, or DKIM
- Domain-based Message Authentication, Reporting and Conformance, or DMARC.
Many mailbox providers around the world use these protocols to filter incoming messages. Marketers need look no further than Google, Yahoo, and Microsoft to find that more than half of their average lists are being checked for all three protocols.
Many email marketers send messages on behalf of clients, using the client’s domains in the from address, but aren’t sending the messages from the client’s infrastructure. This is essentially what spammers and phishers are doing, so it requires more work from the mailbox providers to distinguish the bad actors from the legitimate marketers.
Email authentication protocols aim to make that task easier, and marketers should be highly motivated to ensure the messages they send can be verified as legitimate. This avoids delays, or being diverted to the spam folder accidentally.
2. What is DMARC, how does it work, and what makes it different from other authentication protocols (DKIM and SPF)? How do they work together?
DMARC is essentially a policy and reporting layer on top of DKIM and SPF.
The reporting side means that DMARC-enabled receivers will tell you:
- How many messages they’ve received using your internet domain in the From: address
- Where these messages came from
- Whether these messages passed DKIM and SPF checks.
This is incredibly useful to organizations introducing email authentication, and allows them to see if any criminals are impersonating them.
The policy side of DMARC lets the domain owner request particular handling of messages that use their domain in the from address, but don’t pass either DKIM or SPF. In other words: If somebody uses your domain but fails authentication, what action should the inbox provider take? You can ask that:
- No action be taken
- The failing messages be quarantined
- The failing messages be rejected.
This is obviously very powerful in combatting fraud, and a breakthrough because inbox providers were largely unwilling to do this when only SPF was used, and for DKIM there hasn’t been a widely accepted policy mechanism.
There’s one additional factor that DMARC introduces, and that is known as address alignment. DKIM and SPF authentication use particular domain names for each message. With SPF this is the domain within the “bounce address,” more precisely the RFC5321.MailFrom. With DKIM this is a domain that’s included in the cryptographic signature that DKIM attaches to the message.
Confused yet? This is exactly the problem. Both DKIM and SPF use domain identifiers that the end user never sees. So a bad actor can cause messages to pass simple DKIM or SPF checks using domains they control, while putting whatever they like in the from address. The user would see “service@BigBank.com” and happily trust the message, when they shouldn’t.
Under DMARC, these domains must match (or be “in alignment” with) the address in the from header. This is what we call address or domain alignment, and it helps prevent the easiest, most effective form of phishing.
3. What are the benefits of setting up DMARC? How does it help protect my brand?
Nobody wants to be associated with fraud against their customers, or their potential customers. But if you don’t protect your domain—your brand—with email authentication, you’re making it easy for criminals to capitalize on the good reputation you carefully built up by letting them impersonate your domain.
For the brand owner, the first benefit is that DMARC reporting gives you a snapshot of email activity using your domain. You can get this even if you haven’t deployed DKIM and SPF yet to see if spammers and phishers are impersonating you. In addition, you’ll get an idea of all internal entities that send email using your domain: For example, you may discover that marketing has hired two firms to send email to customers, HR has contracted a firm to tell employees about benefits, and Purchasing has a vendor handling orders.
However, you should still deploy both DKIM and SPF. Making it easier for receivers to verify your legitimate messages means less delay analyzing the content of every message you send, because they’re all potentially suspicious. It means your messages will be handled more consistently at each inbox provider, instead of having some portion sent to the spam folder, depending on each campaign’s unique properties.
4. What can happen if I don’t set it up?
If you don’t setup DMARC, it may be that nothing happens. Or it may be that somebody sends a million messages using your domain, attempting to get people to give up their bank account details. Without DMARC reporting, you may never hear about it. With DMARC and the other protocols in place, you have the opportunity to prevent such messages from reaching consumers—who, in case of fraud, will naturally have a bad association with the domain or brand that was used to victimize them.
While working for my former employer we deployed DMARC for a retired domain, and nothing happened for a month. Then one weekend, a fraudster sent almost two million messages using that domain. Fortunately almost all of them (99%) were blocked because of the DMARC policy we had published, but without DMARC we would have never known—unless it made the newspapers, which is not how anybody wants to learn of such things.
Is your DMARC record set up correctly?
Litmus Spam Testing helps you make sure that your email authentication—including DMARC, DKIM, and SPF—is set up for success
5. What do DMARC reports look like? What kind of information do they include?
There are two kinds of reports. The ones we usually talk about are called aggregate reports, where each inbox provider includes summary information about all the messages they saw using your domain. So that’s the number of messages, which IP addresses they came from, whether they authenticated with DKIM or SPF, whether there was a DMARC “pass,” what was done with the message, and so on. It’s like the rows of a database or spreadsheet, packed up as text using a format called XML. The reports can be tens or hundreds of kilobytes, it all depends on the size of the inbox provider and the amount of traffic sources, etc.
The other kind of reports are failure reports, which are not sent by all inbox providers. Microsoft’s Hotmail is probably the best known US mailbox provider that sends them. In this case, if the domain owners requested them through their DMARC policy, the inbox provider sends one failure report for every message they receive that uses your domain, but which fails to authenticate.
Keep in mind that requesting failure reports can generate a lot of messages. But those reports can contain details about the sending systems, and any URLs or links in the message, so they can be very useful both to people deploying email authentication and troubleshooting problems, or for security staff trying to understand what scammers are up to.
Both of these reports are very valuable, but reading them—particularly the aggregate reports—is not something most people enjoy. The domain owner or email sender will typically want to process the reports automatically. The formats are documented in the standards, so you have the option of writing your own tools. There are a few open source packages to get you started, but most organizations tend to use one of several services for help. Agari, dmarcian, and Return Path have been at it the longest, but more recently companies like 250ok, Easy Solutions, Fraudmarc and ValiMail offer these services and more.
6. We’ve talked about senders and why they have to adopt and act on DMARC. But why is DMARC important for Inbox Providers (ISPs), too?
Implementing DMARC as a inbox provider can be expensive. Imagine maintaining a database about all the individual domains sending email to your company. Now imagine you host a hundred companies. Still with me? Now imagine you host all the companies that use Google Apps, or Office 365. It’s a significant investment of time, staff, and resources.
But there’s a benefit to ISPs as well. Email authentication is very programmatic when compared to determining if something is spam, or a phish, based on the contents of the message. The former is a quick set of calculations, whereas the latter is very subjective, involves parsing natural languages, interpreting the use of images, analyzing where links in the message go, etc.
The more sophisticated the analysis you have to subject each message to, the more expensive it gets for the ISP to keep users’ inboxes clean. Email authentication, and the reputations senders build up more quickly when they use it, can make those initial determinations a lot faster and therefore cheaper. ISPs still have to scan for viruses and such, but knowing the message came from a reputable sender makes a big difference.
To help domain owners and senders make their messages easier to authenticate, ISPs and other DMARC receivers accept the overhead of compiling and sending those aggregate reports. The idea is that senders will use those reports to make sure their legitimate messages authenticate 100% of the time, which helps contain operational costs for the receivers. Everybody benefits—especially the end users who have fewer fraudulent messages in their inbox.
7. How many brands and ISPs are already using DMARC?
It would be very difficult to provide an accurate answer to that question. Not every organization that uses DMARC to filter incoming messages advertises that they use it, and some commercial email gateways now do the filtering but don’t yet support reporting. On the sender side, I can say that one dataset shows over 100,000 domains have published valid DMARC records, and that is a limited dataset—it doesn’t cover anything remotely close to the entire internet.
If readers are trying to understand if there’s enough use of DMARC that they should adopt sooner rather than later, then my answer is yes. In marketing terms, consider how many of your clients’ customers are covered by AOL, Comcast, GMail, Microsoft, and Yahoo. They all use DMARC, so you want to make sure you are too. And while that might all seem very specific to North America and maybe Europe, one of the largest Chinese mailbox providers, NetEase; LaPoste in France; Mail.ru and Yandex in Russia; and many other mailbox providers large and small around the world use DMARC.
8. If an inbox provider checks incoming email for DMARC but my brand hasn’t set it up yet, can this hurt my delivery rate?
The easier it is to determine that messages are not bad, the more likely they get delivered quickly and without mistakes. It isn’t so much that you hurt your delivery rate when you don’t have email authentication, as that you can avoid being treated incorrectly when you do have it.
For example, you send out a message and it includes a phrase or a link that resembles something in a recent large-scale spam campaign. If a mailbox provider has to rely on content filtering and pattern matching, and they have no proof that your message came from a known good actor, there’s a higher chance some or all of those messages might be sent to the spam folder. Best case the messages get subjected to more scans and checks, which delays the delivery of your messages.
Or—and this is getting more common—if you don’t pass authentication checks you might have the links in your messages removed or disabled, or the images might be blocked, all because the source of the message couldn’t be verified.
9. Do inbox providers attach security warnings to emails from brands that aren’t authenticated? Are email recipients made aware of authentication failures?
As a matter of fact, a couple of the top mailbox providers are experimenting with showing users different indicators when messages that did not authenticate appear in their inbox. Gmail in particular has been doing this, the same as they’ve been doing for messages not sent over an encrypted connection.
10. What about domains that don’t send email? Should they be authenticated, too?
This is a special case, and should be addressed with authentication. If you have a domain that isn’t sending mail now or in the near future—say it’s reserved or “parked”—you can easily set an SPF record so that nobody impersonating it can reach the inbox, and set a DMARC record to receive reports when anybody tries.
This is something that should be done for every parked domain, simply to preserve the potential brand equity of the domain. If the domain you reserved has been abused and has a lousy reputation by the time you want to use it, you’ve wasted your time and money. Better to protect it from the start.
11. Who is usually responsible for setting up DMARC for a brand—someone in my company or my ESP? Who can help with the technical implementation?
Every company seems to organize this responsibility differently. Sometimes the marketing team develops the names and registers them, working with an in-house team or a vendor for operations. Other times one department manages domains, a different group handles email, and marketing is an internal customer coordinating with several ESPs. Any of those groups may be tasked with preventing abuse, or it may come from an information security or risk management team.
The best suggestions I can offer are that:
- The company that owns the brand should be the registered domain owner, and
- They should determine who is responsible for domain management across the company, similar to how brand management is typically organized across the entire company.
Make sure your executives understand the risks of not protecting your domains, and set a clear policy and responsible party or department with the authority to get the job done. Then determine which teams need to be involved in developing a plan to protect those domains and executing it.
Where it comes down to questions of technology and operations, if a company doesn’t have the expertise in-house there are vendors that can help. We’ve listed some providers for implementation and analytics support on the DMARC website.
12. What does it cost to set up DMARC?
This doesn’t lend itself to an easy answer, because the scale of the project would vary greatly from company to company. For example:
- How many domains are involved?
- How many different internal departments send email?
- How many outside vendors?
- Will there be charges if those vendors have to change aspects of the messages they send?
- Who has responsibility for the project, and can they force other departments to make operational changes where necessary?
- Is the technical expertise needed available in-house, or does that need to be sourced?
Armed with those questions—which just scratch the surface—somebody who knows the target organization may begin to scope out the effort. At the same time, and to get an idea of what DMARC could do, publishing a DNS record for one domain and reviewing the reports is an easy way to start, and might demonstrate the need for a real project based on what those reports show.
13. In addition to DMARC, what other practices do you recommend for protecting against email fraud?
Do whatever you can to make it easy to identify your messages. Use your domains consistently over time, ideally using one domain or subdomain throughout the message for addresses, images, links, etc. It’s easy and tempting to pull assets from different domains—your vendors and partners, for example—but that can appear the same as when phishers pull in assets from domains unrelated to the from address. At least limit the set of other domains you’re working with, and keep it stable over time.
The easier it is to tell your messages come from you, the easier it is to tell when messages using your identity come from somewhere else, and shouldn’t be delivered to the inbox.
Make it to the inbox, not the spam folder
Identify issues that might keep you from the inbox and get actionable help for how to fix them with Litmus Spam Testing.