Domain-based Message Authentication, Reporting & Conformance (DMARC) is a standard that allows the owner of an Internet domain name to specify a policy for treatment of unverified messages that appear to originate from him, and to request reporting for such incidents.
Standardized in 2015, DMARC builds on top of SPF and DKIM. It addresses a fundamental problem of those mechanisms: originating domains have no immediate way to monitor the actual effect of their SPF and DKIM policies, while recipients cannot know the degree of confidence and reliability of every sender’s implementation; thus many preferred to stay on the safe side and not to discard any messages, voiding most of the purpose of these systems.
Also, DMARC adds an additional check: while SPF verifies that the originating server really belongs to the domain name of the envelope sender, and DKIM verifies that the message really comes from the domain name that signed it, a successful DMARC verification also requires that at least one of these domain names matches the domain of the sender’s email address as shown in the From: field of the message. This addition is particularly important because the sender’s email address is displayed by clients and used by users to identify the message author: it is the true target of phishing attempts.
This further requirement is called message alignment: a message is aligned if the domain name in the sender’s email address matches the domain name used by the underlying authentication mechanism. The alignment is verified separately for each authentication mechanism, so a message can be “SPF-aligned”, “DKIM-aligned” or both. For DMARC verification to be successful, there needs to be at least one alignment on an authentication mechanism (SPF or DKIM) which was also successful on its own; a single failure in SPF or DKIM is not a problem as long as the other mechanism produces a successful and aligned verification.
By default, the alignment is checked in relaxed mode, which means that it is enough that the organizational domain – the one belonging to an entire organization, e.g. “example.com” or “example.co.uk” – is the same, even if the actual domain names are different due to the use of different hosts or subdomains inside it. However, the domain name owner can prescribe a strict mode alignment check, in which no difference is allowed at all, even if just in terms of subdomains of the same organizational domain.
The DMARC alignment check breaks several traditional legitimate email arrangements, such as mailing lists and automatic forwarding of messages, where the manipulation of headers or the re-sending of the message from a third party server, even if properly validated via SPF and DKIM, can easily break the alignment. This is why the deployment of DMARC has been cautious and based on trial and error. However, having to find technical workarounds for some specific email uses is considered a lesser evil, in the ongoing fight against email forgeries.
DMARC is implemented through a policy declaration published in a specific TXT record in the DNS for the name “_dmarc.<domain>”, where the domain name used for the query is that of the sender’s email address.
The declaration is made by a series of name-value pairs, of which “p” (policy) is the most important, as it tells the receiving server what to do with messages that fail DMARC verification: “p=reject” will tell the receiving server to reject the messages, while “p=quarantine” will tell it to accept them but mark them as dubious and possibly illegitimate. It is up to the receiving server whether and how to honour these indications.
This can be done by specifying “p=none” and adding some specific email addresses for reporting, as values for the “rua” and/or “ruf” properties. This declaration tells the receiving server to send to those addresses an aggregate report in XML format about all messages that failed verification (“rua”) and/or a copy of the actual messages (“ruf”). If these email addresses point towards a different domain name, a consent must be provided by that domain name via another specific DNS record. Also, to reduce throughput, a message reporting percentage lower than 100 (“pct”) can be specified.
This allows the originating domain to check whether the failures only include spam and forged messages, or whether they also include legitimate messages that due to SPF or DKIM configuration problems are failing the verification.
Further details can be found in the overview and FAQ on the DMARC website; RFC 7489 contains the full specification of the DMARC policy record fields.
