Effective email authentication requires an organization to have clear control of its messaging operations, and it can take a lot of work to get there if you don’t already have it. But many don’t realize that deploying DMARC – before or while you’re deploying DKIM and SPF – can offer a valuable external view of your messaging operations that helps you maintain a high level of service.
Additional Visibility from the Start
It takes very little to enable the aggregate reporting features of DMARC – a mailbox that can handle a few dozen messages each day, and a single DNS record. You don’t have to write or deploy code to process these reports, though if you want to there are packages and libraries available. Instead you could setup a free or trial account to have your reports processed for you (see Analytics and Implementation Support).
What you will see is a snapshot of every source sending email that uses your Internet domain in the From: header, as seen by the world’s biggest mailbox providers – AOL, Google, Hotmail, Mail.ru, NetEase, Office365/Outlook.com, Yahoo – and a growing number of other reporting organizations, from mid-tier mailbox providers to businesses to non-profits. You’ll see just how many of these messages any computer on the Internet sent to each of the reporting organizations – including messages coming from elsewhere within your company, or from contracted ESPs or other vendors, which other departments or past employees may not have documented or reported.
If you aren’t sure if you have a problem with fraudsters abusing your domain, this is how you can find out – and if they aren’t now, you’ll see it in the reports if they ever start.
Feedback During Deployment
As you introduce technologies like DKIM and SPF, or expand your existing deployments, you can use DMARC aggregate reports to track your progress. Each time a legitimate sending system is added to your DKIM or SPF coverage, you’ll start to see the results in the next set of reports – depending on when that system starts sending messages, and which receivers they’re sending to. It may take a full business day or two from when that receiver first sees messages from your upgraded source, depending on the exact timing and where they were in their reporting cycle. (See When can I expect to receive my first aggregate report?)
Aggregate reports provide a valuable post-deployment check. Like email itself, DKIM and SPF both depend on DNS and most organizations have multiple DNS servers. Often a failure to authenticate messages is traced back to a configuration issue, either on the sending system or the DNS server(s) at the sender or a receiver. It’s not uncommon that one secondary DNS server out of several might not get the updated records correctly, or a receiver’s server might cache the old DNS records longer than they should. Or perhaps a configuration error caused messages from one sending domain not to receive a DKIM signature, or to receive a signature from a different domain. The DMARC aggregate reports help identify where the problem is and get it solved quickly, where previously it might take days or weeks before a customer complaint or other anecdotal source would uncover the problem.
Monitoring Post-Deployment
Skipping ahead, let’s say your organization has deployed DKIM, DMARC and SPF successfully. The fraudulent activity using your domain has abated – now what? While your team focuses on other projects, the DMARC aggregate reports will continue to come in. And they can form the basis for operational and abuse alerts on an on-going basis.
In the case of abuse, consider a botnet that starts sending messages using your domain. Aggregate reports will show a spike in both the number of unauthenticated messages, and the number of sources sending those unauthenticated messages. This can be detected quickly by somebody reviewing the reports, or by simple analytics implemented in-house or by a report processor, and the fraud and abuse team can be alerted immediately.
Daily reports include the authentication rates of messages from your known or legitimate sending sources. This lets you establish a set of baselines for the number of messages seen by a given receiver/reporter, and whether there are typically any transient authentication failures – for instance, because of DNS server timeouts somewhere between the sender and receiver – and with that baseline you can establish a threshold for any increase in the failure rate that should generate an alert to the operations or business team responsible. For example, one ESP had an issue that caused roughly 10% of the messages they sent on behalf of a particular client to fail authentication. That was potentially 20,000 angry customers, lost sales, et cetera – each day. But aggregate reporting identified it and led to an investigation and speedy correction.
Sometimes Department A doesn’t tell Department B about their new email campaign, or new contract with a vendor or ESP – this new traffic will show up in the aggregate reports as they come online. It will be obvious how many messages are being sent and where they’re being sent from, and you’ll usually see the sending computer’s domain. Often this makes it immediately obvious if a new legitimate – if unexpected – sender is involved. Here too your report processor or custom code might be able to generate an alert, to provide faster response than manual review of the reports.
Execution Matters, and DMARC Can Help
Email has long been a critical business service, as well as a vital communications channel to reach your customers, members, vendors, or other parties. And in the age of metrics and data analysis, DMARC reporting provides useful and actionable information about your messaging operations – as well as fraud and abuse.
For more information on deploying DMARC please refer to our listing of articles, tutorials and videos.