This is all about email this week, and identifying where your emails are originating from. With all the talk about DMARC recently and how Yahoo! broke the internet (they didn’t, just a very small portions of it) it seems like a fitting week to discuss how you can track your email campaigns.

A good portion of CASL compliance will come down to understanding your email patterns and being able to track the approved messages your organization has sent. One handy tools to do this is DMARC, which stands for “Domain-based Message Authentication, Reporting & Conformance”. DMARC allows organizations to publish a policy request for recipient ISPs and businesses to take an enforcement action on emails that arrive and fail SPF or DKIM authentication and take one of the following types of actions;

  • None – apply no policy or state your in testing mode, but send reports
  • quarantine – messages that fail should be delivered to the spam folder, and send reports
  • reject – Block mail that fails Authentication and send reports (use this with caution and understanding of what might break when implementing this level of policy).

DMARC also allows you to request two different types of reports; an aggregate report detailing the number of messages seen from a particular domain/IP and how it validated (pass/fail) by the receiving ISP. The second set of reports (less commonly used at the moment)is a forensic report of the failed messages that may include headers and all of the URLs of emails that failed to pass your published policies. A full explanation can be found on the official site: http://dmarc.org/.

How do I get these reports?

    Start with configuring proper SPF and DKIM authentication for your email infrastructures and your outsourced vendors (if you use them), then look at implementing something like DMARC (although this is not dependent on the other authentication records it much more useful when one or both are present). Once you are ready to publish your DMARC record use one tools listed below to build your domain policy. DMARC is another DNS text record that your IT team would implement on your behalf, but be aware you need a place to send these reports first… your record should end up looking something like this for each domain you want to protect:

      _dmarc.example.net. IN TXT “v=DMARC1; p=none; pct=100; rf=afrf; rua=mailto:Aggregate@example.net”

Processing these reports?

    Now that you are getting these reports what do you do with them… If you’re technical enough, or have a technical team at your disposal, to build a solution to read XML files and process these on your own then look to have an internal address setup, otherwise you can look at a third party tool that is already setup to process and report on these files. There are a number of vendors you can look at including; Return Path, Agari, Dmarcian, or DMARC Analyzer to name a few. All of these tools offer their own strengths and weaknesses, so I recommend you evaluate them and find the right fit for your organization. Starting with a “None” policy is a great way to understand the scope of your email infrastructure (corporate, development, vendor and other) and build internal policies to fix any issues that you may see, it would not be a recommended step to move into ‘quarantine’ or ‘reject’ without first understanding all of the potential issues this could introduce in to your email channels.

    Note: Some of these tool are quite expensive, typical pricing is based on volume of legitimate emails reported and the number of domains you are tying to get reporting/protection on. Be sure you properly consider your options before signing up with any of these solutions (ex: integration with take down services, account management full/self service, use technical skill/understanding). To properly test these you many need to modify your DNS several times over a period of several months.

But how does this help me with my CASL compliance?

    DMARC’s aggregate reporting will share with you they source of emails reportedly sent by your organizations you will quickly be able to tell if there are potentially message streams that your company is sending that you did not know about and can target for compliance or servers sending without approvals (i.e. internal developers testing, affiliates), 3rd parties sending on your behalf (ESPs, partners), or are potentially phishing your brand. This reporting can help you track down the sources of these unapproved emails and migrate them to the official channels, or potentially shutdown/report fraudulent activities. Being able to track and manage the approved networks maybe important should a consumer accuse your organization for sending them Unsolicited Commercial Electronic Messages (CEMs) in the future. This could be a very valuable tool in reviewing complaints under CASL in the future should you need to quickly determine the authenticity of the messages you are reviewing. In the long term for marketing and transactional email, and in some cases corporate emails, will be able to have a very strict policy applied to help enforce brand protection from Phishing and other fraudulent related activities.

Protecting your brand from fraudulent or unauthorized use may not directly be part of CASL but being able to easily know what is legitimate email and what is not will be a big step in ensuring your compliance with the legislation. This type of solution should also please your security, privacy, compliance/legal and brand protection teams. After publishing DMARC Reports for my own domains for several months I’m amazed to find that phishing and forgery targets even my small corner of the internet. Once you start to see the data presented for your domains you might just be amazed by what you find.

* HEY! Why no week 13? It’s an unlucky number so we are skipping it and there are only 77 days to go until July 1st, so I’m taking the chance to reset expectations on the proper number of weeks left until enforcement.