A few weeks ago I wrote about a way to reduce the likelihood of having your company’s email domain abused by phishers. Alec Peterson of Message Systems and Sam Masiello of Groupon provided good information and advice for deploying the Domain-based Messaging, Authentication, Reporting and Conformance (DMARC) standard for your organization.
Now we’re going to get specific about how to actually deploy DMARC for your company. Once again I must thank Alec Peterson for providing this step by step set of instructions for protecting your company’s good reputation. Deploying DMARC is the best way to ensure that scammers aren’t successful in hijacking your company’s email domain to send spam and phishing messages.
Here’s a little refresher course if you read my two previous posts on DMARC. (If you haven’t read them yet, they will help you comprehend the steps below). DMARC is a technical specification to help reduce the potential for email-based abuse, such as when someone sends a phishing email that appears to come from a legitimate company, but it’s really from a malicious source. DMARC rides on the back of two other email authentication standards, SPF and DKIM.
SPF, or Sender Policy Framework, is an IP-based path-based authentication mechanism. It’s the way you tell email receivers such as Comcast, Gmail and Yahoo!, “These are the IP addresses or the third parties that are allowed to send mail on my behalf and these are the IP addresses that they are sending from. If you see something that is not coming from any of these IP addresses, then it doesn’t pass SPF and the mail can be rejected.”
DKIM, or DomainKeys Identified Mail, is a signature-based authentication mechanism. When a message is sent out, certain parts of that message are signed so that when the ISP receives it, they can validate to ensure that the pieces of the message that were signed did not change during the transmission of that message. This means that the person who receives the message can be sure that the content of the email when it is received is exactly the same as when it was sent.
DMARC was developed for two reasons. One was to initiate that policy mechanism for rejecting email messages that don’t adhere to SPF and DKIM standards; i.e., faked email. The other is to allow the domain owner to get visibility through DMARC reporting as to everyone who is sending mail on their behalf. This includes corporate email sent from an internal server, legitimate email that may be sent through an email service provider, and email using a spoofed domain that is being sent by a scammer.
The instructions below assume that the email administrator has already deployed the SPF and DKIM authentication mechanisms. If you need help incorporating those standards into your messaging framework, go to http://www.openspf.org/Project_Overview and http://www.dkim.org/, or give Message Systems a call.
Before you deploy DMARC in your organization, you need to do some preliminary work. This article outlines that ground work, and the next article in this series covers deploying the actual DMARC standard.
The first thing to do is get executive-level approval to deploy DMARC because it is something that affects the whole company. Since the goal of DMARC is to tell ISPs to reject and discard messages that don’t conform to your policies, you want someone at the CIO or similar level to approve this company-wide directive.
The next thing to do is collect a list of all your company’s authorized email domains—or at least as many as you can discover. This includes external domains that are authorized to send mail on your behalf, such as marketing companies that send bulk promotional mail. This list is going to become the definitive list of acceptable addresses for sending your mail. 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, mind you, because you’ll have a grace period to make sure you’ve captured every legitimate source.) If you don’t know where to start to collect this list, see your billing department; someone has to pay for those email domain names.
Next, find out who is responsible for your DNS infrastructure, as you will eventually need to submit a change to your DNS record. Be aware that your company may outsource your DNS management.
And the last of the preliminary work is to set up an email address where you will receive your DMARC reports. You’ll be able to control how many reports you get, but generally expect to get one aggregate report daily.
These reports are going to be very useful to you. They’ll tell you the sources of your messages and what their DMARC alignment looks like. For example, you might get a message from Gmail that says a specific IP address sent 58 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.
Tune in to my next post to get step-by-step instructions on actually deploying DMARC for your organization.
- About Corero
- Investor Relations
- News Room
- Executive Management Team
- Corero Offices
- Contact Us