{"id":7059,"date":"2018-08-14T14:19:43","date_gmt":"2018-08-14T18:19:43","guid":{"rendered":"https:\/\/www.thesslstore.com\/blog\/?p=7059"},"modified":"2020-12-15T10:09:38","modified_gmt":"2020-12-15T15:09:38","slug":"dmarc-reporting-and-email","status":"publish","type":"post","link":"https:\/\/www.thesslstore.com\/blog\/dmarc-reporting-and-email\/","title":{"rendered":"Email Security – Part 5: DMARC, Reporting and Email"},"content":{"rendered":"

With email security protocols DKIM and SPF in place, understanding and implementing DMARC will take email security and reporting to the next level.<\/h2>\n

Since the start of this email security series<\/a>, we have looked into different components of the email process. Email has turned into a complex process and there are vulnerabilities with perceived patches at just about every turn. As mentioned in a previous post, much of this has to do with user processes and knowledge and, ultimately, it is up to the user to make sure that they are regulating their email traffic safely. All the tools help but they need to be properly implemented and maintained to stay safe.<\/span><\/p>\n

\"DMARC\"Now that we’ve covered everything else, we\u2019ll take a look into the master sword, the infinity gauntlet, the one ring of email security that binds some security pieces together to form DMARC (Domain-Based Message Authentication, Reporting and Conformance). DMARC utilizes DKIM<\/a> and SPF<\/a> (which are previous article topics) to report on how the email domain is doing: compliance, alignment, failures, etc.<\/p>\n

It is best to use an aggregator, such as (free ad placement) DMARC Analyzer<\/a> or DMARCian<\/a>, that does much of the heavy lifting and leaves a pretty report. Because the settings are handled in DNS, much like DKIM and SPF, the lookup is persistent to message transport, so you end up with DMARC reports of per message resulting in a volume count.<\/p>\n

Early in this series, I mentioned that this transition to The SSL Store, a marketing-heavy company, really forced me to think about email security, validity and such. This company generates a lot of email for not only marketing purposes, but also email verification for purchases, plus support throughout the certificate life cycle. There are also many sources of these email generations. So, when there were questions about our current risk, I knew that implementing all the tools and processes outlined in this series would help alleviate any doubt.<\/p>\n

Setting up our company\u2019s DMARC account with all our email domains has given me peace of mind and allows me to evaluate the overall status of our email flow.<\/p>\n

Before we start, here’s a quick graphic that illustrates how DMARC works, courtesy of Agari<\/a>:<\/p>\n

\"DMARC\"<\/p>\n

So, What\u2019s Required for DMARC?<\/h2>\n

\"DMARC\"Mentioned earlier, in this post and previous ones, SPF (Sender Policy Framework, AKA IP origination Validation) and DKIM (DomainKeys Identified Mail AKA Email Domain Validation) are the 2 main components that will make DMARC work correctly.<\/p>\n

As a quick recap, SPF identifies the IP addresses of the email origination (or known exchangers) in order to define what is valid. Email that originated from anything other than the SPF entry in the DNS record should be considered false and should not be trusted.<\/p>\n

DKIM uses a public key, created at the mail service (or server) level and stored in the DNS record, to sign certain parts of the email. Different stops in the email\u2019s transit can check the signature in the DNS record. If the key in the email matches what DNS reports back, then BAM! Everything is good.<\/p>\n

DMARC is recording the results of both other protocols per domain. It also allows for certain settings to determine how to handle failures of either or both. So, the other requirement is to consider how failures on either protocol are to be handled.<\/p>\n

Love Me Some Options, So Let\u2019s Talk That<\/h2>\n

Whoa. Calm down there, sport. There are some options but let\u2019s make sure we\u2019re walking before we\u2019re running. There are some obvious options for DMARC<\/a> Version 1 (which needs to be identified in the DMARC DNS record, e.g., v=DMARC1) and I imagine that future versions may offer an elevated number of options for administrators and postmasters worldwide.<\/p>\n

There are not a lot of options with the current versioning, yet, it’s required to be explicitly called in the DNS record so just go ahead and pencil that in.<\/p>\n

The policy, or p, <\/em>is where the real decisions are made. This is what determines what happens with the traffic that fails either DKIM, SPF or both. The options are fairly simple:<\/p>\n