You may have heard of an email initiative called DMARC, which is supported by many of the major email providers. What is DMARC and how does it benefit Exchange server administrators.?
What is DMARC?
DMARC - Domain-based Message, Authentication, Reporting and Conformance is basically a standardisation of how is email is handled by a number of email authentication mechanisms such as SPF.
As an email server admin the interesting part it introduces is the reporting aspect.
History
Little bit of history to begin with.
Spam has been an on-going problem for over 20 years and it was identified that one of the most common issues with spam is spoofing - where an email is sent with the From address being inaccurate.
One of the initial ways to try and deal with that issue was SPF - Sender Policy Framework, also known as Sender-ID. This uses DNS records to indicate what IP address and hosts can send email for a domain - the idea being that by putting additional records in your own DNS, you can tell the world where your email should be coming from.
As an email server admin, SPF had a number of drawbacks.
The first one was that it had zero effect on the amount of spam that you received yourself. For most email server administrators, that is all they are worried about.
The other major drawback is that if you did implement the SPF DNS records, you had no way of knowing if it was effective or not. The lack of feedback means that most SPF records are very conservative in configuration, so that people don't block legitimate email.
DMARC Features
There are two key features of DMARC.
First, it tells the major providers what to do with email messages that are protected by SPF records in a standard way. It takes the guesswork out of the process.
Secondly, is to provide the administrator of the email domain with reports (in a standard XML format) of whether email has been blocked or not. Reports come from a number of major email providers, including Google, Hotmail, Yahoo and AOL. It also tells the major providers what to do with email if they fail the SPF records checks.
DMARC also supports Domain Keys, but their implementation is limited so not covered in this article.
DMARC protects over 60% of consumer mailboxes, so if you are emailing a lot of home users then you will get results from deploying it.
Setting up DMARC to get the reports
The reports are probably the most interesting aspect and this is what this blog is mainly about.
There are three steps to the process.
1. Setup your SPF records correctly.
2. Setup an email address for receiving the reports.
3. Setting up the DNS records.
SPF Record Setup
For DMARC to work correctly, you need to have SPF records setup in the correct way. A lot of SPF records have been configured with ~all parameter, which basically means that any server can send email for that domain. That needs to be replaced with specifics.
The easiest way to get the SPF records setup correctly is to use a tool: http://spfwizard.com/
You need to list everything that could send email as your domain. If you are hosting your own server, then using the MX record method might be enough. However if you send email via a smart host, then the smart host will need to be listed. Don't forget to include any web servers that might be sending email based on scripts.
You can then setup the records to effectively report only, so take no action. That will allow you to build up a picture of what is happening before you implement blocking procedures. That DMARC standard was written to allow this exact scenario, so that you can build up confidence in the results.
Email address for the reports
The email address that receives the reports goes in to DNS entries so could be queried and then used to send spam (oh the irony). Therefore I would suggest that you setup a specific alias or group (dmarc@example.com) which can be changed if it starts to be abused.
There are actually two types of messages that you can receive - reports and status messages. You can use the same email address for both.
DNS records
The final step is to configure the DNS record. Again an online wizard is the easiest way to do this, which will generate the record in the correct format.
http://www.unlocktheinbox.com/dmarcwizard.aspx
With the record text created, you just need to create a new TXT record in your domain and paste the text. Watch that some DNS providers do not want the record enclosed in "".
After about 48 hours, you will start to get report emails. These will be zipped up and attached to the email.
Reading the Reports
The reports are XML, so might not make a huge amount of sense. Fortunately web sites which can interpret these reports have been created.
The way that these web sites are designed to work is to put an email address they provide in to your DMARC record. What I prefer to do is take that email address and put it in to a mail enabled contact in Exchange, then add it to the group I created in the second step above. This group can then include an internal recipient as well so I can see the reports are coming in.
DMARC Analysis
http://dmartian.com/
http://www.dmarcanalyzer.com/
What to do with the results
After you have had DMARC running for a little while you will be able to see if email is coming from other places and needs to be included in the SPF records. As you refine the PSF records and your message delivery you will be able to move to DMARC settings that say to reject the messages.
However the results can also give you a good idea of how your domain is being used.
I implemented DMARC with a client in late 2012. After a few weeks we noticed that a Dutch server was coming up as a source. The client identified that an ex member of staff was sending out email using addresses on their domain. They were able to stop this, plus using DMARC able to ensure the messages were blocked.
More Information
The dmarc project web site is at http://www.dmarc.org/
The FAQ explains in more depth what the project does: http://www.dmarc.org/faq.html
