Video: DMARC – Technical Overview
We’ve put together a short technical overview of DMARC:
This video is part of a larger video series on all things DMARC.
The transcript follows:
This short video is a technical overview of DMARC – Domain-based Message Authentication, Reporting, and Conformance.
DMARC attempts to create a link between the content of an email and a domain using either SPF or DKIM. For the curious viewer, SPF and DKIM are covered in separate videos.
The email content that DMARC is concerned with is the domain found in the From: header. The From: header is pretty much the only chunk of information that indicates who or where an email comes from that is required to be in what is considered ”well-formed email”. Because of this, DMARC keys off of the domain found in the From: header.
DMARC does not key off of any other header, including the Sender: header. It turns out that allowing multiple policy keys causes a lot of confusion and may even undermine the usefulness of DMARC itself, and so DMARC keys off of only the domain found in the From: header.
SPF and DKIM are both technologies that produce stable, domain-level identifiers. SPF and DKIM are freely available technical specifications that have seen wide implementation across many different email vendors. Even though they go about their business in different ways, DMARC only cares about the results that they produce, and if those results have anything to do with the domain found in the From: header. The results that are produced by SPF and DKIM are referred to as “Authenticated Identifiers” in the world of DMARC.
A key concept of DMARC is “Identifier Alignment”. This is just a fancy way of saying that the results of SPF and DKIM need to be related to the DMARC domain to be useful. The main reason for this is because receivers need a simple way to understand if the results of SPF and DKIM are relevant to the domain that DMARC keys off of.
During the next few slides of this video, we’ll walk through different combinations of Authenticated Identifiers with the aim at illustrating why Identifier Alignment is important from the perspective of an email receiver.
In this first example, an email receiver got a piece of email where the DMARC domain (which is the domain found in the From: header) is “bank.com”. Additionally, the SPF check yielded a domain of “bank.com”. There wasn’t a DKIM signature on the piece of email, so our row is marked with “none”. The email receiver is looking for any positive signal that the email can be traced back to the “bank.com” domain, and the email receiver doesn’t care if that signal comes from SPF or DKIM — just so long as the signal is there. In this example, the Authenticated Identifier that came from SPF was “bank.com”, and that exactly matches the DMARC domain, and so the email is compliant with DMARC.
In this next example, everything is very much the same, except that the Authenticated Identifier that SPF yielded is a sub-domain of bank.com — mail.bank.com. To an in-the-flesh human being, the two domains are obviously related. However, it turns out that there is no standard way on the Internet to figure out if bank.com is a top-level domain like .com or .org or if its a second-level domain. There isn’t a standard way to figure this out. A different example is bank.co.uk. There isn’t a standand way for machines to be told that “co.uk” is the top level domain. In the world of DMARC, the thing that is a second-level domain is called the Organizational Domain. By pulling in some resources from the Internet — specifically the public suffix list maintained by the Mozilla Foundation — an email receiver can figure out that bank.com is the Organizational Domain, and that mail.bank.com is a sub-domain that shares the same Organizational Domain as bank.com. In this case, the email is compliant with DMARC.
This 3rd example shows something interesting. Instead of SPF yielding an Authenticated Identifier of bank.com or a sub-domain of bank.com, the Authenticated Identifier is banknewsletter.com. For all we know, banknewsletter.com is a real domain owned and operated by the same entity that owns bank.com. OR…. banknewsletter.com is owned and operated by criminals that want to trick people into thinking they’re legit. There simply isn’t a way to reliably maintain and communicate such associations between domains — either by senders themselves creating databases of associations or by receivers maintaining their own — both are tasks that would be fraught with inaccuracies and basically subvert the utility of DMARC. And so, this email is NOT compliant with DMARC and would be affected by a published DMARC policy.
To continue on with the 4th example, the email is the same except now we’re seeing a DKIM signature for the first time. In this example, DKIM yielded an Authenticated Identifier of bank.com, which makes the example compliant with DMARC. That is, the email receiver looks at the Authenticated Identifier that came from SPF and sees that banknewsletter.com has nothing to do with bank.com and simply ignores it. Since the receiver is looking for any positive signal that the message really did come from bank.com and DKIM provides such a signal, the email passes the DMARC check.
This 5th example shows an email that is DMARC all the way. Both SPF and DKIM yielded Authenticated Identifiers of bank.com. The receiver only cares about finding a positive signal, so having 2 positive signals is doubly good but doesn’t mean anything more than “positive signal”. The reason for sending email where both SPF and DKIM yield the right results is because having both technologies available makes it possible for email to continue to be DMARC compliant even if one or the other — for whatever reason — is unavailable or fails.
This 6th example shows the same thing with the difference that “news.bank.com” is the Authenticated Identifier for both SPF and DKIM. It’s fairly common practice for large organizations to delegate a sub-domain to an email service provider so that the service provider can send email on behalf of the organization. In this example, the owners of bank.com might have delegated the sub-domain of “news” to their marketing vendor so that the vendor can send DMARC compliant email using bank.com.
This contrived example shows that anyone can register domains and put SPF and DKIM into place. Wouldn’t it be nice if the bad guys used such obvious domains? Still, just because SPF and DKIM pass and yield an Authenticated Identifier doesn’t mean the email is good or wanted.
The last example here shows that SPF yielded an Authenticated Identifier of “bark.com”… as in the sound a dog makes. This is a well known attack that some fraudsters use to trick humans that are manually inspecting pieces email to determine legitimacy. A quick glance might trick the eye and make someone think that bark is really bank. Worse still, it’s possible to use some character encoding tricks so that the rendered glyphs look exactly like the intended domain. Machines aren’t fooled by this sort of tom-foolery, which is why machines should perform Identifier Alignment checks, and not people.
Before we get into what DMARC records look like and what they can do, we’ll touch briefly on how DMARC records are discovered.
When an email receiver processes a piece of email in the context of DMARC, the receiver will extract the domain found in the From: header. This domain forms the basis of where the receiver looks for any corresponding DMARC record. The receiver will slap an underbar-dmarc prefix to the domain and query the DNS for a TXT record.
In the example shown here, the extracted domain is EUROPE.ENG.EXAMPLE.ORG. The receiver would add underbar-dmarc to this domain and query the DNS to try to find a TXT record. But what if the query results in nothing or a TXT record whose content had nothing to do with DMARC. The receiver would then extract the Organizational Domain from the domain… in this case EXAMPLE.ORG, and try again to find a DMARC record by slapping under-dmarc in front of the domain and querying for a TXT record.
In this way, DMARC record discovery is limited to just 2 DNS lookups. There are also some nifty ramifications due to this. You can publish a single DMARC record at the Organizational Domain level and have it cover all and any sub-domains. It doesn’t matter if a spammer makes up their own sub-domains, you can still publish a DMARC record that covers them without have to publish explicit DMARC records for all imaginable sub-domains. The other nifty thing is that you can publish DMARC records for all of your real sub-domains and those DMARC records will override what is published at the Organizational Domain level.
Alright, onward now to what DMARC records look like and what they can do.
DMARC records are simple lists of tag/value pairs. In this example, the domain that published this DMARC record… we can tell its a DMARC record because it starts with “v=DMARC1;”… is publishing a “none” policy and asking for all XML-based aggregate reports to be sent to [email protected] for processing. DMARC was designed to allow domains to collect information without impacting email… and this is how its done — by publishing a p=none policy.
In terms of what DMARC records can do, the options are fairly simple. All DMARC records have to start with a protocol version tag. After that, the policy can be configured, you can configure a policy that will be applied to any sub-domains…. for example if you know that your domain never uses sub-domains, you can publish an sp=reject policy immediately while only collecting data on your Organizational Domain using p=none. The pct tag is like a slider that goes from 0 to 100 so that any published policy can be slowly rolled out… if you say pct=1, then only 1 out of every 100 emails that otherwise would have been affected by a DMARC policy will be impacted.
You can also configure whether or not the Authenticated Identifiers yielded by SPF and DKIM are required to exactly match the DMARC domain. The default of “relaxed” is preferred in almost all cases, but in “strict mode” you can disallow Identifier Alignment that is based on sub-domains, perhaps if you’re in an environment where you do not have control over the email sent using delegated sub-domains.
The next two tags, rua and ruf, are used to tell the world where to send reports for the domain. Because the reports are different, people send the reports to different email addresses for collection and analysis.
The last tags are concerned with configuring reporting formats, intervals, and when to send redacted copies of individual emails that fail DMARC. The first two tags have only 1 value and are therefore a bit useless, and the last option appears to disable the generation of reports by some report providers due to software bugs, so maybe leave them out if you care to collect these.
Alright, we’ll finish out this overview with the different policies that DMARC allows and with a brief look at the 2 different feedback reports that DMARC provides.
DMARC’s policy options are very simple. You can publish a “none” policy that just means “please send me reports without acting on email that fails the DMARC check”. You can publish a “quarantine” policy that directs receivers to spam-folder any email that fails the DMARC check. If a spam folder doesn’t exist, then the receiver might do whatever they can to treat the message with a higher degree of suspicion, like turning up the aggressiveness of anti-spam scanning.
The last policy that can be applied is the “reject” policy, which directs receivers to block — or refuse to accept — email that fails the DMARC check. One the screen you’ll see a bit more about the pct tag, and how if you use it with you’ve a got a reject policy in place, then whatever percentage of email that isn’t rejected due to the percentage tag will instead be quarantined.
Last thing, the 2 forms of feedback reports that DMARC can provide are very different. The XML-based aggregate reports are generated on a 24 hour cycle and include comprehensive statistics on how an email receiver sees your domain being used — including all email that fully passed DMARC. The 2nd kind of feedback consists of redacted copies of individual emails that failed SPF, DKIM or both. These reports are not always available due to privacy concerns, volume concerns, or the view that they’re not required to get DMARC deployed accurately.
dmarcian processes both types of feedback to make DMARC easy to deploy. Questions about DMARC or the dmarcian service will be happily answered.
To get started with DMARC, visit dmarcian.com.
Questions? contact [email protected]. Thank you for watching!
