An email marketer’s top-level guide to DMARC, your best anti-phishing tool
How secure is your email program? Columnist Scott Heimes believes DMARC is a vital tool in the war against fraudsters and outlines easy ways to implement it in your own organization.
In the world of email marketing, there are two types of professionals: those who concern themselves with what makes up a good email and those who concern themselves with what makes an email. Both are important and deserve study by anyone who considers themselves to be an expert email marketer.
One of the many things every email marketer ought to know are the major players in email protocols — the underpinning technologies making emails possible today. Protocols come and go, but there are a few standards that can help emailers deliver better, safer emails for both senders and receivers. One of these powerful standards is Domain-based Message Authentication, Reporting and Conformance, or DMARC.
What does DMARC do?
DMARC is designed to do several things, but it’s mainly deployed as a method of authenticating senders and receivers. Its goal is to help detect fraudulent email, like those found in phishing and spam campaigns, and to do so in an easily scalable manner.
Over time, DMARC will make it harder for fraudsters to successfully deliver contaminated messages and easier for authenticated businesses and users to interact, but its adoption has been slow. Two-thirds of Fortune 500 companies have yet to implement a DMARC policy, according to recent research (PDF) by cybsersecurity company Agari.
There are three major reasons implementing DMARC is a smart decision for any organization.
- First, it blocks fraudsters from sending emails from an organization’s domain, which can help protect online reputations.
- Second, it enables an organization to have better visibility into its email program by tracking who can send emails from their domain.
- And third, it betters the entire email community by standardizing — and consistently implementing — a policy for messages that have failed to authenticate.
Getting to DMARC
DMARC is relatively easy to do, provided you have the right parts in place. Two other protocols, Sender Policy Framework and DomainKeys Identified Mail, or SPF and DKIM, respectively, will need to be implemented before any DMARC deployment. These two protocols are powerful anti-spoofing standards in and of themselves, and they work in tandem with DMARC to authenticate, verify and execute policy.
Other than setting up SPF and DKIM, all an organization needs to do to ensure their mailers match their identifiers is to update their DNS (Domain Name System) with a DMARC record that looks a lot like this:
v=DMARC1; p=none; rua=mailto:XXXX@COMPANY.com; ruf=mailto:XXXX@COMPANY.com; rf=afrf; pct=100
That’s really it. This record instructs a receiving server to look for a DMARC check for DMARC and to follow through a policy if the DMARC check fails. In this case, the policy is set to “none,” though DMARC will still send alerts to domain admins if a DMARC check fails.
Keeping the policy at “none” is a wise decision for those who are just beginning to implement DMARC, as it gives the admin insight into who is sending what on behalf of an organization.
There are a variety of modifiers available to DMARC records. These, like “sp,” “adkim” and “ri,” can fine-tune DMARC implementation, allowing domain admins to apply the protocol to subdomains and adjust DKIM alignment and how often DMARC will flag failed checks.
As always, it’s best to get a baseline understanding of what sort of emails are being sent by whom before significantly modifying DMARC or outright rejecting certain servers and senders.
DMARC is a powerful weapon in the war on spam and phishing, and it ought to be implemented (though, of course, to what degree depends on your environment). While it’s by no means perfect — it can, for example, be confused by high-volume senders — it’s an important tool that companies can use to defend their brands, and their customers, from phishing attacks and other cybercriminal maladies.
Opinions expressed in this article are those of the guest author and not necessarily MarTech. Staff authors are listed here.