(No Ratings Yet)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

August 14, 2018 1

Email Security – Part 5: DMARC, Reporting and Email

in Hashing Out Cyber Security

With email security protocols DKIM and SPF in place, understanding and implementing DMARC will take email security and reporting to the next level.

Since the start of this email security series, 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.

Now that we’ve covered everything else, we’ll 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 and SPF (which are previous article topics) to report on how the email domain is doing: compliance, alignment, failures, etc.

It is best to use an aggregator, such as (free ad placement) DMARC Analyzer or DMARCian, 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.

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.

Setting up our company’s 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.

Before we start, here’s a quick graphic that illustrates how DMARC works, courtesy of Agari:

So, What’s Required for 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.

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.

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’s 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.

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.

Love Me Some Options, So Let’s Talk That

Whoa. Calm down there, sport. There are some options but let’s make sure we’re walking before we’re running. There are some obvious options for DMARC 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.

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.

The policy, or p, 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=none – No action will be taken. There will only be record of a failure.
• P=quarantine – The email is flagged as spam and the mail exchanges/inboxes will proceed with spam as they have defined.
• P=reject – The email is flagged as malicious and should be dropped by any exchanger, domain or inbox client listening.

Typically, when starting off, it would make complete sense to set the policy as p=none so the lay of the land can be surveyed and any potential issues/bumps (on either SPF or DKIM) can be ironed out.

There are also options for the reporting aspect of DMARC:

• rua – Indicates where the aggregated email reports should go. This is for the count (volume) of messages and how they did with SPF and DKIM. The destination is typically in the form of an email address. The DMARC services will often provide an email address to load in so that they can parse and arrange the data to something readable.
• ruf – Indicates where the forensic email reports should go. This has some more information for the SPF and DKIM failures used to investigate what went wrong. The destination is typically in the form of an email address. The DMARC services will often provide an email address to load in so that they can parse and arrange the data to something readable.

As the confidence level of the proper DKIM and SPF settings are valid, then the user can ramp up what they want to do with failures. Among DKIM, SPF and DMARC, it is best to do the research, follow the logic and then check the results. If all is well, you can be confident that your emails are trusted and any spoofer would be identified and, ideally, slain in their parents’ CheesyPoof-dusted basement.

More Options! Whoooooa!

Whoooooa! Indeed, there are a few more options that have defaults associated to them. If they are not explicitly called, then the defaults will be assumed. Here are a some of them:

• sp – This is for the subdomain policy. Like Policy (p), it has the option values for none, quarantine and reject. This is for any subdomain of the contextual appropriate email, so, you can have a different policy.
• pct – This indicates the percentage of DMARC failures to be reported. Values can be any whole number from 0-100. This is typically used for testing but I suppose there are other options for using this. Default is set to 100 and implied if not specified.
• adkim – This option specifies the alignment type for DKIM. The options include ‘s’ for strict and ‘r’ for relaxed (default value). If relaxed is desired, there is no need to add that option into the DNS record. Relaxed setting allows for subdomains to be used. Strict needs an exact match.
• aspf – This option specifies the alignment type for SPF. The options include ‘s’ for strict and ‘r’ for relaxed (default value). If relaxed is desired, there is no need to add that option into the DNS record. Relaxed setting allows for subdomain to be used. Strict needs an exact match. As mentioned in previous blog posts, SPF calls for domain name or IP address, so this would not affect IP address listing.
• fo – This stands for ‘Forensic Options’ and basically indicates the conditions in which a forensic report would be sent off. The values include ‘0’, ‘1’, ‘d’ and ‘s’.
  • 0 – Indicates if DKIM and SPF fail. This is a pretty lax setting but certainly not unreasonable to use, especially if you think your DKIM and SPF records are up to date and high and tight.
  • 1 – Indicates if DKIM or SPF fail. This is a stricter setting and one that is recommended. If you think your DKIM and SPF records are up to date (and high and tight heh), then a failure in either would be a flag.
  • s – Indicates if SPF fails. If DKIM is not setup, this would be an option. If DKIM is not a problem, for whatever reason, this would an option.
  • d – Indicates if DKIM fails. If SPF is not setup, this would be an option. If SPF is not a problem (maybe dynamic IP or coming from something with many IPs that are not specified), this would be an option.

 

How do we get this Frankenstein’s Monster to “It’s ALIIIIIVE!”?

We made it this far. Noice. As with SPF and DKIM, all of this stuff is indicated in the appropriate DNS record. There are online services that will help you generate the DMARC record and the DMARC aggregators, also mentioned earlier, have generators that will give you the exact record including the emails (that they own) that parses this information and makes it nice and neat. Let’s take a look at a sample record and dissect:

v=DMARC1; p=quarantine; rua=mailto:ae799710f9ad889@rep.dmarcaggreagatorservice.com; ruf=mailto:ae799710f9ad889@for.dmarcaggreagatorservice.com; pct=100; sp=quarantine; adkim=s; aspf=s; fo=1

• v=DMARC1 – DMARC version. This must be in the record. Don’t argue. Just Do it Swoosh.
• p=quarantine – Policy is set to quarantine for failures. Recall that this setting flags the email as spam(mish) and exchangers/inbox clients will do what they will do with it.
• rua=mailto:ae799710f9ad889@rep.dmarcaggreagatorservice.com – This is the email, provided by a theoretical DMARC service, that all email will copy to for reporting/monitoring. Don’t bother doing anything with that email – I made it up.
• ruf=mailto:ae799710f9ad889@for.dmarcaggreagatorservice.com – This is the email, provided by a theoretical DMARC service, that all information regarding DMARC failures will be sent. The service will then aggregate and report on those failures. Again, don’t bother doing anything with that email – Also made up.
• pct=100 – This is the percentage of failures to capture – Like Freddie Mercury or Warren G, I want it all, hence, value = 100. This is the implied value so the same thing would happen if this wasn’t even listed.
• sp=quarantine – Policy for sub-domains is set to quarantine for failures. Recall that this setting flags the email as spam(mish) and exchangers/inbox clients will do what they will do with it.
• adkim=s – Strict DKIM policy – must match the domain exactly. No sub-domains.
• aspf=s – Strict SPF Policy – must match the domains exactly. No sub-domains. IP addresses need not apply.
• fo=1 – This setting indicates that if DKIM or SPF fails, send a ruf to the email specified (see above).

So, adding a TXT entry in the DNS record with name = _dmarc.YOURDOMAIN.com and a similar value listed above will get the DMARC active and working. Seemingly, one could build their own aggregator/forensic system where it receives the information from email and then parses it appropriately, but these DMARC services are affordable and already setup and makes it easy.

I keep an eye on a site called SenderScore.org to see our reputation. This site will show you some information of the bad people and the score will reflect it.

Honestly, I am fairly new to DMARC. So, this information is fresh in my mind and new to me. I check DMARC everyday, watching my success percentages go up and up along with our reputation. It is easy to setup, easy to understand, pretty satisfying and, I would say, a must for companies similar to our email volume. Plus, it helps with scrutinizing.

I will likely be switching topics for next post and I hope you enjoyed this series.  So, yeah, stay safe and happy scrutinizing!

Check out the rest of the Email Security Series

• Email Security – Part 1: Certificate Signed Emails
• Email Security – Part 2: Phishing and Other Falseness
• Email Security – Part 3: Sender Policy Framework (SPF)
• Email Security – Part 4: DKIM (DomainKeys Identified Mail)

• #Email Security