In my previous article I covered the preliminary tasks that need to be done when you want to implement the DMARC standard to protect your email domain(s). This article gets into the meat of what to do for actual deployment. I’d like to thank Alec Peterson, CTO of Message Systems, for these step-by-step instructions.
Remember that list of email domains that you collected as one of the preliminary tasks? Pull it out, because the first implementation step is to deploy a DMARC DNS record for all of these domains.
The DMARC record is a text record that is 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 the DMARC.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 them to be passed through (i.e., delivered) because you don’t know what your situation is yet. 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 are setting up the DMARC record, you can set up the ability to have aggregate reports emailed to a designated address on a periodic basis, usually once a day. These reports will tell you where your messages are coming from and what their DMARC alignment looks like. This is all done in a nonintrusive manner.
The reports come to you in an easy-to-read XML format. This information gives you a sense of where your email is coming from. Most people think they know where their email is coming from – from the IT server run by the corporate data center, of course – but there’s always this one-off location that surprises them. Any system can send mail that appears to come from your domain. The IT system may be where it is supposed to be from, and you may have a corporate policy that says that the IT system is where your mail is going to be from, but that doesn’t mean that somebody doesn’t have mail coming from some other source. This could be legitimate mail being sent on your company’s behalf (such as by a marketing firm) or it could be spoofed mail. 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 delivered. But for right now you get visibility into that.
You really need at least a week’s worth of reports to get some good data. You’ll probably find that there’s some marketing going on from an ESP somewhere using your domain. This would be legitimate because that’s the kind of thing that your marketing department would do. If you see an ESP sending mail on your behalf, get in touch with them to make sure that they are able to authenticate to prevent their mail from being discarded.
Once you have all that understood, 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 we just figured that out with the DMARC report. The next step there is to create the appropriate SPF record and advertise your SPF record to the Internet. (See http://www.openspf.org/Project_Overview for details.)
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. (See http://www.dkim.org/ for more information.)
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.
If these steps seem confusing or too much work for you, contact our expert Alec Peterson’s company Message Systems for help. Message Systems does everything from analyzing the message flows, to setting up the DMARC records to get the information, to creating and deploying the authenticating policy.
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.
- About Corero
- Investor Relations
- News Room
- Executive Management Team
- Corero Offices
- Contact Us