If you are not familiar with the terms Email Authentication or DMARC, please see Microsoft 365 - Email Authentication (DMARC) Introduction. DMARC, and establishing email authenticity, has become an important tool for preventing phishing, business email compromise (BEC) scams and other email attacks that are based on impersonating trusted senders.

This discussion assumes some knowledge of email mechanics and DNS (Domain Name System) and is a very simplified overview of email authentication mechanisms. Links to more information on each topic are included below.

What is DMARC?

DMARC is a complicated topic because it is built on the older email authentication tools, Sender Policy Framework (SPF) and Domain Keys Identified Mail (DKIM).

The goal of DMARC is to define not only who is allowed to send email using your domains but also what recipients should do with a message if it does not come from an approved source. DMARC also provides a framework for receiving feedback reports that can give you insight into what services are using your domain or forging mail as your domain.

We are going to define a few concepts before we talk about how DMARC works.

What is an Email Domain?

When we refer to an email domain, we are talking about the portion of an email address to the right of the @ symbol (e.g. bucky@wisc.edu). In the example wisc.edu is the email domain of the email address. wisc.edu is also referred to as the top level organization domain for UW-Madison. doit.wisc.edu is also an email domain but it is an example of what is referred to as a subdomain of wisc.edu.

Header From versus Envelope From

In order to understand email authentication, it is important to understand that there are two different From addresses associated with any email message.

The Envelope From is delivered in the MAIL FROM command in an SMTP transaction as described in RFC 5321. The technical term is RFC5321.MailFrom and is also known as the Return Path or Bounce Address. This is NOT the address that recipients normally see in their email client.

The Header From is delivered in the DATA portion of an email message as described in RFC 5322. The technical term is RFC5322.From and this is the From: address that is normally displayed in email clients and is what most people view as the email sender.

Sender Policy Framework (SPF)

SPF is an email authentication method that allows email domain owners to publish a list of IP addresses that are allowed to send mail on behalf of the domain that is delivered in the MAIL FROM command or Envelope From. Since SPF authenticates the Envelope From address and not the Header From, it is possible for malicious actors to impersonate trusted senders and also pass SPF authentication checks.

SPF records are DNS TXT records and are publicly visible to anyone on the internet. Below is an example of the wisc.edu SPF record:

You might notice that there are no IP addresses listed in the SPF record. Sometimes you need to perform a lookup of the records listed in the “include” mechanism in order to see the allowed IPs:

The SPF mechanism is fully defined in RFC 7204. SPF alone is not sufficient to authenticate mail.

DomainKeys Identified Mail (DKIM)

DKIM is a different email authentication method that allows email senders to include a digital signature on an email. The cryptographic signature is based on a public/private key pair where the public key is published as a DNS record by the domain owner. The DKIM signature includes the domain that is signed for (d=) and the elements of the message that are guaranteed by the signature (h=). Here is an example of a DKIM signature:

The corresponding DNS record for the DKIM public key is determined based on the selector key (s=) and domain (d=) shown in the DKIM-Signature. In our example the DNS record that defines the public key for the admin.wiscmail.wisc.edu domain is selector2._domainkey.admin.wiscmail.wisc.edu.

The recipient's email system can validate the signature by looking up the sender's public key in DNS. A valid signature ensures that the body and other elements of the email message have not been modified prior to delivery. The Header From address is always included in the signature.

A valid signature alone does not demonstrate that the email is legitimate. The domain used in the signature (d=) needs to match the domain of the Header From address in order to establish email authenticity.

The DKIM signing mechanism is fully defined in RFC 8463.

Domain-based Message Authentication, Reporting and Conformance (DMARC)

DMARC is an email authentication method that is built on SPF and DKIM but is completely centered around the Header From address. An email domain owner publishes a DMARC policy as a DNS TXT record. The DNS record is always of the form _dmarc.<domain>.

Example:

A domain's DMARC record tells recipient systems 3 basic things:

1. What to do if email authentication fails. Also known as the DMARC policy (p=).
2. The alignment mode for the SPF and DKIM checks (adkim= and aspf=).
3. Where to send feedback reports (rua=, ruf=) and what type of reports to send (fo=).

We recommend publishing a DMARC policy of "p=quarantine". This tells the recipient system to send the email to Spam or Junk if authentication checks do not pass. The goal is for all UW-Madison domains to have a quarantine policy. You can also set the policy to "p=none" or "p=reject".

A "none" policy is a temporary state and is only used during the initial phases of a DMARC rollout while you evaluate DMARC reports. If you see a DMARC policy with "p=quarantine; pct=0;", that is effectively the same as "p=none".

A "reject" policy means that the receiving system should reject the mail if it doesn’t pass authentication and is not recommended for general use domains.

The alignment mode determines whether or not the domain used in the SPF or DKIM check has to be an exact match (strict; aspf=s) with the domain of the Header From or if it can be a partial match (relaxed; aspf=r). A partial match means that the domains only need to share the same organizational domain. For example if the DKIM signature domain is relay.mail.wisc.edu and the Header From is doit.wisc.edu, that will satisfy a relaxed alignment requirement.

Finally, the domain owner can define whether or not they want to receive feedback reports related to DMARC successes and failures and where those reports should be sent. Not every mailbox provider returns DMARC feedback reports but most of the big providers do (e.g. Google, Yahoo, Microsoft).

The DMARC authentication and reporting mechanisms are fully defined in RFC 7489.

DMARC Brings it All Together

DMARC uses SPF or DKIM to establish the authenticity of the Header From address displayed in the recipient’s email client.

DMARC based on SPF: If an email message passes the Envelope From SPF check and the domain used in the Envelope From address matches the domain used in the Header From address, then the message passes DMARC. If the DMARC policy indicates that this can be a relaxed match (aspf=r) then the Envelope From and the Header From just need to share the same organizational domain. A relaxed match is the default.

DMARC based on DKIM: If the DKIM signature on an email is verified and the domain specified in the signature (d=) matches the domain used in the Header From address, then the message passes DMARC. If the DMARC policy indicates that this can be a relaxed match (adkim=r) then the domain used in the signature and the Header From just need to share the same organizational domain. A relaxed match is the default.

DMARC checks can be successful based on either SPF or DKIM and does not require that both checks succeed.

DMARC is explained more thoroughly on the dmarc.org website.

Looking for more information on these topics?

Email Authentication
What is email spoofing?
DMARC
DKIM
SPF
DNS Terms