Do you want to stop phishing attempts that spoof your company’s domain name? You can do that using the Doman-based Messaging, Authentication, Reporting and Conformance (DMARC) standard. Read on to learn how to deploy DMARC for your organization.
A few weeks ago I wrote how the Doman-based Messaging, Authentication, Reporting and Conformance (DMARC) standard is helping companies protect their domains from phishing (see DMARC is having a positive impact on reducing spoofed email). Now I’ll share with you how to implement this standard.
This is something that can be done in-house if your company has technical people who understand DNS and your email system. If you don’t want to go it alone, there are companies that can implement DMARC for you and also provide the ongoing service of consolidating and analyzing all the email usage reports you’ll be getting.
The instructions below assume that the email administrator has already deployed the SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) authentication mechanisms. If you need help incorporating those standards into your messaging framework, go here.
The preliminary work
Before you deploy DMARC you need to do some preliminary work, including, of course, executive-level approval, because this is something that affects the whole company.
Next, collect a list of all your company’s authorized email domains, including external domains (such as marketing companies) that send mail on your behalf. This becomes the definitive list of acceptable addresses for sending your mail—a whitelist, if you will. Any IP address that sends mail in your company’s name and which does not appear on this list will ultimately have its messages discarded. (Not right away, though. You’ll have a chance to make sure you’ve captured every legitimate source.)
Notify the person or service provider responsible for your DNS infrastructure that you will eventually need to submit a change to your DNS record.
Set up an email address to receive your DMARC reports. You’ll be able to control how many reports you get, but generally expect to get one aggregate report daily.
Ready for deployment
With those first steps done, it’s time for deployment.
Get out the list of all the domain names that send email on your behalf. You need to deploy a DMARC DNS record for all of these domains.
The DMARC record is a text record attached to the parent domain. It takes the form "_dmarc.your_domain.com." where "your_domain.com" is replaced with your actual domain name. The format of that record is defined at theDMARC.org website in the standards. There’s a little wizard there that helps you create your first DMARC record. What you put in the record is the disposition of messages that are not DMARC aligned. Initially you want the ISPs to pass all of the messages through (i.e., deliver them to the intended recipients) and not discard any of them yet. Eventually you will want to say to discard records that don’t match your DMARC record.
When you set up the DMARC record, you’ll specify the email address where aggregate reports should be sent on a periodic basis, usually once a day.
The reports come to you in an easy-to-read XML format. They list the sources of your domains’ messages and what their DMARC alignment looks like. For example, a message from Gmail might reveal that a specific IP address sent 300 messages using your company’s domain name and none of them met your DMARC policy. That means these are most likely phishing emails and you know it’s OK for ISPs to discard rather than deliver them. Or, the messages could be from a legitimate domain that didn’t originally make it to your domain list. Perhaps it belongs to an outsourced email service provider you weren’t aware of. In this case, you need to contact that provider and have them apply your SPF and DKIM authentication. Once they do that, they shouldn’t show up on the DMARC reports again, and you can ensure that their emails won’t get discarded.
The DMARC reports are almost certain to contain notations of messages that you don’t recognize. The reason for that is those are phishing messages. If your domain is getting phished, that is how it is going to show up. The idea is that once you have DMARC fully enabled, those messages will be discarded and never actually get delivered. This is the crux of DMARC.
You need at least a week’s worth of reports to get good visibility into the email patterns. Once you have a good understanding of who is sending legitimate email on your behalf, it’s a matter of setting up your policy and setting up your SPF and DKIM authentication if you haven’t already done so.
The easiest one to set up is SPF because it is based on the sending domain and it maps it to a set of IP addresses. So you have your set of domains, and you have the IP addresses that are legitimately sending because you just figured that out with the DMARC reports. The next step is to create the appropriate SPF record and advertise your SPF record to the Internet (details here).
Setting up DKIM is a little more challenging because it actually requires changing the configuration of the system sending the emails. Usually that is an Exchange server or some sort of external third-party or a gateway in front of the Exchange server. That device will need to be modified to perform a DKIM signature and then that signature will need to be advertised to the DNS as per the DKIM standards (more here).
Once you have that authentication deployed, continue to look at the daily DMARC reports to make sure all of the sources of your messages that you expect to be authenticating are in fact authenticating. If you’re satisfied that they are, the next big step is to make the change of your DMARC policy to be a discard policy. This tells the ISPs that if they get messages from your domain that are not authenticated – which should only be messages that did not originate from your organization or are not authorized by your organization – those messages can be discarded.
After this last step, stay in close contact with your IT helpdesk in case somebody says their messages aren’t getting delivered. This could indicate that something slipped through the cracks in terms of authorized IP addresses that are allowed to send out emails.
For more information about deploying DMARC, read through this description from a LinkedIn engineering team. You’ll also find good resources on www.dmarc.org.
Linda Musthaler (LMusthaler@essential-iws.com) is a Principal Analyst with Essential Solutions Corp., which researches the practical value of information technology and how it can make individual workers and entire organizations more productive. Essential Solutions offers consulting services to computer industry and corporate clients to help define and fulfill the potential of IT.