DMARC mail security protocol gets an update

A policy for receiving mail servers

Mail domain operators use DMARC to say what must be done with mail that doesn't pass SPF or DKIM validation, and to secure the 'From' headers of their messages. An operator does that by publishing a DMARC record in the DNS system, giving instructions – known as a 'policy' – for receiving mail servers to follow. A receiving MX gateway fetches the DMARC record before deciding whether to accept an inbound message.

As well as SPF and DKIM-specific instructions for receiving mail servers, the DMARC record can also include an e-mail address to which receiving mail servers can send reports about rejected messages. The reports have to follow a standardised format, so that they can be automatically processed to generate statistics and reports. The operator can then monitor the delivery of both genuine and falsified messages. The security provided by DMARC is vital in the fight against phishing, CEO fraud, ransomware [1, 2] and other malware attacks.

Authentication of the mail envelope and 'From' header

In order to understand how DMARC works, you first need to know a little about mail headers and the mail envelope. The headers and envelope are used by the sending mail server to tell the receiving server about the message's sending host (a system), sender (an e-mail address) and addressee (an e-mail address), using the SMTP protocol:

• In the 'EHLO'/'HELO' command: the host name of the sending mail server

• In the 'MAIL FROM' command: the sender/return address of the message (the bounce address)

• In the 'RCPT TO' command: the addressee(s) for whom the message is intended

• In the 'From' header: the sender name and address (display name) that the mail client will display to the receiving user

• Without DMARC, nothing would be done to authenticate the 'From' header, which plays no role in the transport and delivery of a mail message, meaning that falsification of the display name is a trivial matter.

SPF, DKIM and DMARC use the information mentioned above as follows to confirm the authenticity of the sending host and sender:

• SPF: validation of the 'EHLO'/'HELO' and 'MAIL FROM' information (the mail envelope)

  • (Optional) checks the 'EHLO'/'HELO' host name to verify that it points to the SMTP client's IP address, thus confirming that the identity of the client (the sending mail server) is as claimed.

  • (Mandatory) checks the sending domain in the 'MAIL FROM' address to verify that the SMTP client's IP address is authorised to send mail from the domain in question, thus confirming that the client (the sending mail server) has the authority to send/forward messages for the sender.

  • If no 'MAIL FROM' information is available (typically for bounce messages), SPF falls back on the 'EHLO'/'HELO' host name in preference to the sending domain. Note: this option is not used by SPF when SPF is part of DMARC.

  • The (positive) result is a validated mail envelope.

  • If validation of a message/envelope fails, the connection/message can be blocked immediately, or the message can be forwarded with the negative result in a 'Received-SPF' and/or 'Authentication-Results' header.

• DKIM: signing of outbound mail messages and their headers at the sending end, and validation of the signatures on inbound messages at the receiving end

  • Checks the validity of the digital signature accompanying the message (in the 'DKIM-Signature' header), using the public key published in the signing domain specified in the header.

  • Since the signing domain is not necessarily the sending domain specified in the 'MAIL FROM' command or 'From' header, DKIM itself merely confirms that the signing domain is responsible for initiating the message exchange.

  • DKIM does not block messages; the result of the validation process is added to the message in an 'Authentication-Results' header and, for example, reflected in a spam filtering score or in a DMARC evaluation, meaning that the signing domain's reputation is particularly important.

• DMARC: processing of the results of the SPF and/or DKIM validation on the basis of a policy published by the sending domain in the 'From' header

  • Checks whether the sending domain in the 'From' header matches both the sending domain in the envelope (for SPF) and the validated signing domain (for DKIM); this alignment check connects the SPF/DKIM-validated sending domains and the information in the 'From' header (the display name).

  • The policy published in the sending domain specified in the 'From' header is used to determine what to do with inbound mail messages that fail both SPF validation and DKIM validation (including alignment checks): allow, block or quarantine. With DMARC too, following the policy is not mandatory. However, as with DKIM, validation results can influence spam filter scores.

  • If requested in the policy, aggregate reports and failure reports are sent to the operator of the sending domain.

The DMARC policy

The easiest way to explain the DMARC policy is to provide an example and a diagram. A DMARC record will typically look something like this:

_dmarc.example.nl IN TXT "v=DMARC1; p=reject; sp=reject; aspf=s; adkim=s;
rua=mailto:dmarc-reports@example.nl; ruf=mailto:dmarc-reports@example.nl; fo=1;"

Where:

• 'v=DMARC1;' We are using DMARC version 1 (currently the only version available)

• 'p=reject;' The policy for the root domain

• 'sp=reject;' The policy for the subdomains (if they don't publish separate DMARC policies of their own)

• 'aspf=s;' The alignment between the 'From' domain and the SPF-validated 'MAIL FROM' domain

• 'adkim=s;' The alignment between the 'From' domain and the signing domain specified in the DKIM-validated digital signature

• 'rua=mailto:dmarc-reports@example.nl;' The e-mail address that we want aggregate reports sent to (once a day)

• 'ruf=mailto:dmarc-reports@example.nl;' The e-mail address that we want forensic (failure) reports (about individual rejected mail messages) sent to

• 'fo=1;' Request for receiving mail servers to generate a forensic report whenever mail fails either SPF validation and alignment or DKIM validation and alignment

Note that the 'p' and 'sp' tags identify the policies for messages that fail both SPF and DKIM validation. A configuration where either an SPF validation pass or a DKIM validation pass results in successful DMARC validation largely prevents problems caused by the use of mailing lists and message forwarding. We will return to this topic later.

It's also good to be aware that DMARC is not necessarily dependent on SPF and DKIM. The protocol is defined so that other supporting authentication protocols can be added in the future. As long as a message passes validation by any one of those 'authenticated identifiers' (including the alignment check), the DMARC validation result is also a pass.

Alignment

The tags 'aspf=s;' and 'adkim=s;' specify how strict the receiving mail server must be about alignment between the 'From' domain of an inbound message and the domain names validated by, respectively, SPF and DKIM.

If the 'adkim' tag value is 's' (strict), the 'From' domain must exactly match the signing domain in the 'd' tag of the DKIM header. So, for example, you will not be able to send messages from a subdomain (e.g. alerts@news.example.nl) signed using the digital signature of your root domain (example.nl). You can do that, however, if you use the tag 'adkim=r;' (where 'r' is 'relaxed', the default value). Note that the use of DKIM plus DMARC implies that the signing domain and your root domain are the same. Also, take care not to confuse this tag with the canonicalisation tag ('c=relaxed/simple;') in the DKIM header.

With the 'aspf' tag too, you have a choice between 'strict' and 'relaxed'. However, this tag relates to alignment between the message's 'From' domain and the 'MAIL FROM' domain in the envelope.

Security of the display name

In other words, while SPF and DKIM enable you to secure your 'MAIL FROM' domain and the sending mail servers, DMARC additionally enforces a link with the 'From' header. After all, the sender information (display name) in that header is what the end user ultimately sees. The 'aspf' and 'adkim' tags are there for fine-tuning the DMARC validation alignment requirements for subdomains.

The diagram below illustrates the relationships between the 3 security protocols and where alignment is required.

New policy tags

With that picture of how the various mail security protocols work in mind, we can now consider the proposed changes. First of all, the new RFC is entirely self-contained. In other words, it completely replaces the existing RFC 7489 (DMARC for ordinary domain names) and RFC 9091 (DMARC for registries). The status of DMARC is additionally elevated from 'Informational' to 'Proposed Standard'.

In parallel, RFC 6591, which defines the format for error reports, is being updated [1, 2].

The update will introduce various new tags:

• np: the policy for non-existent subdomains psd: a tag to indicate that the domain is a 'public suffix domain' (PSD), i.e. a domain operated by a registry (e.g. 'psd=y') Note that a PSD isn't necessarily a top-level domain; domains such as .co.uk are also PSDs. The tag will be used to define the root domain of the 'From' domain.

• t: a tag to indicate that the current 'p' policy is merely a test policy (e.g. 't=y') Receiving mail servers are therefore asked to be one level less strict with inbound messages than the policy indicates ('quarantine' -> 'none', 'reject' -> 'quarantine'). The 't' tag therefore replaces the old 'pct=0' and 'pct=100' tags.

In addition, various existing tags are to be withdrawn:

• pct: used to indicate that only a certain percentage of inbound mail traffic is to be handled in accordance with the current DMARC policy; recipients must be one level less strict with the rest

• rf: the format for the aggregate reports

• ri: the interval between aggregate reports

Following the update, the version number will remain DMARC1 because the meanings of the existing tags are not changing, and the new tags will be ignored by old software.

DNS tree walk

Another important feature of the updated protocol is that the algorithm used for discovery of the DMARC policy (correct DMARC record) applicable to the 'From' domain is changing. The 'DNS tree walk' method will use the new 'psd' tag to determine the organisational domain name. If a policy that includes 'psd=y' (or 'psd=n') is discovered, you don't need to go any further, because the organisational domain can then be deduced. Otherwise, the policy for the organisational domain is sought in the next domain up the hierarchy. That procedure is repeated until the policy is found, or until 8 hierarchical levels have been searched.

Although the approach requires more DNS queries, it makes it easier to delegate DMARC policy specification to subdomains.

The domain owner therefore publishes a DMARC record in all their author domains (display domain names) and in their root domain (an organisational domain name). The owner also has to ensure the positive alignment of the authenticated identifiers (SPF and DKIM) with the 'From' domain (directly or as a subdomain). Ideally, everything should be arranged so that all the alignment policies can be set to 'strict'.

A mailing department or service provider can themselves declare a subdomain as organisational by including 'psd=n' in the DMARC policy.

If a registry publishes a DMARC policy in its domain, it must include 'psd=y', so that validating mail servers know that the root domain (an organisational domain name) is beneath the domain in question.

SPF and DKIM

Although DMARC can in principle be used with SPF only or DKIM only, that is strongly discouraged by the RFC. Using only SPF or DKIM is inadvisable because of interoperability problems between DMARC and 'indirect e-mail flows', which are considered in detail in RFC 7960. More specifically, the issues are:

• Complications where third parties, such as external service providers, send mail on your domain's behalf. An SPF validation pass would require all such parties' sending mail servers to be included in your SPF record, and a DKIM validation pass would require each such party to be given a private DKIM key, whose corresponding public key is published by you. For a large organisation, it may then be easier to authorise a DKIM key in each partner's DNS system by means of a CNAME reference, since an e-mail message can include multiple DKIM signatures, of which only one needs to be valid. The alternative is the delegation of an entire subdomain.

• The biggest problems arise with messages sent using mailing lists, because the servers sending or forwarding such messages do so on behalf of 'random' senders. Consequently, they can't usually be included in sending domains' SPF records (only the largest mail handlers can maintain up-to-date whitelists of the most frequently used forwarders). Furthermore, mailing list forwarders are apt to modify the Subject header (e.g. by adding a name tag) or the message content (e.g. by adding a footer), with the result that the original DKIM signature can't be validated. To nevertheless achieve alignment, there is little alternative but to modify the 'From' address. For example; the 'From' address can be changed to one that belongs to the service provider (the address of the forwarder or mailing list, after use of the Sender Rewrite Scheme), with the original 'From' address placed in the 'Reply-To' and 'Original-From' headers instead. However, it is then up to the receiving mail client whether the latter header is displayed to the end user.

The proposed update to DMARC will not resolve the problems with forwarding and aliases. The RFC therefore explicitly advises against setting the DMARC policy to 'reject' wherever users receive mailing list messages.

SPF in combination with DMARC and DKIM

SPF validation takes place as early as possible in the SMTP exchange [Postfix, Exim]. Therefore, if the SPF policy is '-all', non-validating messages are immediately discarded. In that scenario, it's impossible for a message to pass DKIM validation as part of the DMARC validation process (although the sending server will receive an SMTP response saying that the message has been rejected, and why). Hence, when used in combination with DMARC and DKIM, the SPF policy is usually '~all' (soft fail).

DKIM validation and DMARC validation take place further down the chain. However, those procedures should occur during the SMTP exchange if possible, because an SMTP response is preferable to a failure report or bounce message, due to all the backscatter to the return address associated with non-validating mail.

We recommend this tool for testing your DMARC configuration:

https://www.dmarctester.com/

Use of DNSSEC recommended

Finally, a few words about DNSSEC. The new RFC continues to recommend the use of DNSSEC to assure the integrity of the various DNS records. However, DNSSEC (remains) non-mandatory.

For an overview of all the modern internet security standards and the interdependencies, see our maturity model.