We’ve put together a short video on how DMARC works:
This video is part of a larger video series on all things DMARC.
The transcript follows:
This short video describes how DMARC works.
DMARC is a technical specification that describes how email senders can make their email easy to identify using existing free and open technologies. DMARC-compliant email is very easy to process, and email receivers have embraced DMARC as the common way to figure out the basic identity of an email.
DMARC builds upon two existing technologies that are used to associate a piece of email with a domain. SPF, which stands for Sender Policy Framework, and DKIM, which stands for DomainKeys Identified Mail, work in different but complementary ways to create a link between a piece of email and a domain.
SPF and DKIM are stand-alone technologies that have been around for many years and can be used independently from DMARC. By themselves, SPF and DKIM can associate a piece of email with a domain. In the language of DMARC, SPF and DKIM generate “Authenticated Identifiers”. DMARC attempts to tie the results of SPF and DKIM — the Authenticated Identifiers — to the content of email: specifically to domain found in the From: header of an email.
The domain found in the From: header of a piece of email is the entity that ties together all DMARC processing. The “D” in DMARC stands for “Domain-based”, and hopefully you can see now which domain DMARC is concerned with. Now, because anyone can buy a domain and put SPF and DKIM into place (including criminals!), the results of processing SPF and DKIM — that is, the Authenticated Identifiers — have to be related to the domain found in the From: header to be relevant to DMARC. This concept is referred to as “Identifier Alignment”. Getting identifiers to align ends up being a large part of the work of deploying DMARC.
To make it possible for someone that owns an email domain to accurately deploy SPF and DKIM, DMARC describes how feedback can be sent to the domain owner regarding how their email domain is being used across the Internet. This feedback can come in two forms: reports that provide a comprehensive view of all of a domain’s traffic (as seen by the organization that generates the report), and reports that are redacted copies of individual emails that are not 100% compliant with DMARC.
The comprehensive reports are XML-based and include information such as message counts, IP addresses, and the results of processing SPF and DKIM. Although some humans and most androids can read XML directly, dmarcian specializes in processing these reports and identifying what steps needs to be taken so that normal people can get DMARC into place without having to become experts in email authentication.
The reports that are redacted copies of individual emails are not generated by all email receivers that participate in DMARC. The reason why an email receiver might not generate this type of report spans three big areas:
- privacy concerns as the individual emails can include personally identifiable information,
- the reports can potentially be extremely high in volume,
- the reports are sometimes nice to have, but have proven to be not required to work through the process of deploying DMARC.
Lastly, quite a few organizations don’t even want to ask for these types of reports as they want to avoid any sort of potential liability in the area of privacy. Still, these reports can shed light on the specific types of abuse that a domain might be encountering. dmarcian processes both types of feedback to make deployment of DMARC far easier for most types people.
The visibility provided by the feedback reports… when processed by tools like dmarcian.. give the domain owner the ability to deploy SPF and DKIM with a very high degree of accuracy. Once an email domain owner is confident that they’ve deployed SPF and DKIM across all of their email streams, the domain owner can then tell the world to act against email that is not compliant with DMARC. The action that can be taken – or rather the policy that the domain owner can publish – is to either quarantine or reject email. Quarantine usually means to spam-folder email that fails the DMARC check, but if an operator doesn’t implement a traditional spam-folder, the operator might turn up the aggressiveness of spam filtering when processing the non-compliant email. Reject, however, means to block outright any email that fails the DMARC check.
Domain owners usually strive to get to the reject policy, as doing so disallows unauthorized use of the domain, which ends up being a pretty strong anti-phishing measure. More importantly for most, though, DMARC-compliant email is far easier to process which is quickly making DMARC a requirement for anyone that wants to get their email delivered reliably.
This is how DMARC works, and how DMARC uses domains to make email easy to identify.
To get started with DMARC, visit dmarcian.com.
Questions? contact email@example.com
Social? dmarcian is on Linked-in, G+, twitter, and maybe more.
Thank you for watching!