4. Overview
This section provides a general overview of the design and operation of the DMARC environment.
4.1. Authentication Mechanisms
The following mechanisms for determining Authenticated Identifiers are supported in this version of DMARC:
-
[DKIM], which provides a domain-level identifier in the content of the "d=" tag of a validated DKIM-Signature header field.
-
[SPF], which can authenticate both the domain found in an [SMTP] HELO/EHLO command (the HELO identity) and the domain found in an SMTP MAIL command (the MAIL FROM identity). DMARC uses the result of SPF authentication of the MAIL FROM identity. Section 2.4 of [SPF] describes MAIL FROM processing for cases in which the MAIL command has a null path.
4.2. Key Concepts
DMARC policies are published by the Domain Owner, and retrieved by the Mail Receiver during the SMTP session, via the DNS.
DMARC's filtering function is based on whether the RFC5322.From field domain is aligned with (matches) an authenticated domain name from SPF or DKIM. When a DMARC policy is published for the domain name found in the RFC5322.From field, and that domain name is not validated through SPF or DKIM, the disposition of that message can be affected by that DMARC policy when delivered to a participating receiver.
It is important to note that the authentication mechanisms employed by DMARC authenticate only a DNS domain and do not authenticate the local-part of any email address identifier found in a message, nor do they validate the legitimacy of message content.
DMARC's feedback component involves the collection of information about received messages claiming to be from the Organizational Domain for periodic aggregate reports to the Domain Owner. The parameters and format for such reports are discussed in later sections of this document.
A DMARC-enabled Mail Receiver might also generate per-message reports that contain information related to individual messages that fail SPF and/or DKIM. Per-message failure reports are a useful source of information when debugging deployments (if messages can be determined to be legitimate even though failing authentication) or in analyzing attacks. The capability for such services is enabled by DMARC but defined in other referenced material such as [AFRF].
A message satisfies the DMARC checks if at least one of the supported authentication mechanisms:
-
produces a "pass" result, and
-
produces that result based on an identifier that is in alignment, as defined in Section 3.
4.3. Flow Diagram
+---------------+
| Author Domain |< . . . . . . . . . . . . . . . . . . . . . . .
+---------------+ . . .
| . . .
V V V .
+-----------+ +--------+ +----------+ +----------+ .
| MSA |<***>| DKIM | | DKIM | | SPF | .
| Service | | Signer | | Verifier | | Verifier | .
+-----------+ +--------+ +----------+ +----------+ .
| ^ ^ .
| ************** .
V * .
+------+ (~~~~~~~~~~~~) +------+ * .
| sMTA |------->( other MTAs )----->| rMTA | * .
+------+ (~~~~~~~~~~~~) +------+ * .
| * ........
| * .
V * .
+-----------+ V V
+---------+ | MDA | +----------+
| User |<--| Filtering |<***>| DMARC |
| Mailbox | | Engine | | Verifier |
+---------+ +-----------+ +----------+
MSA = Mail Submission Agent
MDA = Mail Delivery Agent
The above diagram shows a simple flow of messages through a DMARC-aware system. Solid lines denote the actual message flow, dotted lines involve DNS queries used to retrieve message policy related to the supported message authentication schemes, and asterisk lines indicate data exchange between message-handling modules and message authentication modules. "sMTA" is the sending MTA, and "rMTA" is the receiving MTA.
In essence, the steps are as follows:
-
Domain Owner constructs an SPF policy and publishes it in its DNS database as per [SPF]. Domain Owner also configures its system for DKIM signing as described in [DKIM]. Finally, Domain Owner publishes via the DNS a DMARC message-handling policy.
-
Author generates a message and hands the message to Domain Owner's designated mail submission service.
-
Submission service passes relevant details to the DKIM signing module in order to generate a DKIM signature to be applied to the message.
-
Submission service relays the now-signed message to its designated transport service for routing to its intended recipient(s).
-
Message may pass through other relays but eventually arrives at a recipient's transport service.
-
Recipient delivery service conducts SPF and DKIM authentication checks by passing the necessary data to their respective modules, each of which requires queries to the Author Domain's DNS data (when identifiers are aligned; see below).
-
The results of these are passed to the DMARC module along with the Author's domain. The DMARC module attempts to retrieve a policy from the DNS for that domain. If none is found, the DMARC module determines the Organizational Domain and repeats the attempt to retrieve a policy from the DNS. (This is described in further detail in Section 6.6.3.)
-
If a policy is found, it is combined with the Author's domain and the SPF and DKIM results to produce a DMARC policy result (a "pass" or "fail") and can optionally cause one of two kinds of reports to be generated (not shown).
-
Recipient transport service either delivers the message to the recipient inbox or takes other local policy action based on the DMARC result (not shown).
-
When requested, Recipient transport service collects data from the message delivery session to be used in providing feedback (see Section 7).