Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
This document describes the Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol. DMARC permits the owner of an email's Author Domain to enable validation of the domain's use to indicate the Domain Owner's or Public Suffix Operator's message handling preference regarding failed validation and to request reports about the use of the domain name. Mail-receiving organizations can use this information when evaluating handling choices for incoming mail. This document obsoletes RFCs 7489 and 9
Replaces RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC), RFC 9091: Experimental Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Extension for Public Suffix Domains.
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 50 must, 16 should, 14 may.
4.4.3 Alignment and Extension Technologies
- MUSTIn the future, if DMARC is extended to include the use of other authentication mechanisms, the extensions MUST allow for the assignment of a domain as an Authenticated Identifier so that alignment with the Author Domain can be validated.
4.5 DMARC Policy Record Explained
- MUSTWhere this is the case, the module performing DMARC evaluation MUST concatenate these strings by joining together the objects in order and parsing the result as a single string.
- RECOMMENDEDHowever, it is RECOMMENDED that Domain Owners use both DKIM and SPF as underlying authentication mechanisms for DMARC.
4.6 DMARC Reporting URIs
- SHOULDA report SHOULD be sent to each listed URI provided in the DMARC Policy Record.
4.7 DMARC Policy Record Format
- MUSTOnly tags defined in that registry are to be processed; unknown tags MUST be ignored.
- OPTIONALadkim: (plain-text; OPTIONAL; default is "r".) Indicates whether the Domain Owner (Section 3.2.7) or PSO (Section 3.2.16) requires strict or relaxed DKIM Identifier Alignment mode.
- OPTIONALaspf: (plain-text; OPTIONAL; default is "r".) Indicates whether the Domain Owner or PSO requires strict or relaxed SPF Identifier Alignment mode.
- OPTIONALfo: Failure reporting options (plain-text; OPTIONAL; default is "0").
- MUSTThis tag's content MUST be ignored if a "ruf" tag (below) is not also specified.
- OPTIONALnp: Domain Owner Assessment Policy (Section 3.2.8) for non-existent subdomains of the given Organizational Domain (plain-text; OPTIONAL).
- MUSTIf the "np" tag is absent, the policy specified by the "sp" tag (if the "sp" tag is present) or the policy specified by the "p" tag (if the "sp" tag is not present) MUST be applied for non-existent subdomains.
- RECOMMENDEDp: Domain Owner Assessment Policy (Section 3.2.8) (plain-text; RECOMMENDED for DMARC Policy Records).
- OPTIONALpsd: A flag indicating whether the domain is a PSD (plain-text; OPTIONAL; default is "u").
- OPTIONALrua: Addresses to which aggregate feedback reports are to be sent (comma-separated plain-text list of DMARC Reporting URIs; OPTIONAL).
- MUSTA Mail Receiver that sends aggregate feedback reports MUST implement support for a "mailto:" URI, i.e., the ability to send a DMARC report via electronic mail.
- MUST NOTIf the tag is not provided, Mail Receivers MUST NOT generate aggregate feedback reports for the domain.
- MUSTURIs involving schemes not supported by Mail Receivers MUST be ignored.
- OPTIONALruf: Addresses to which message-specific failure information is to be reported (comma-separated plain-text list of DMARC URIs; OPTIONAL).
- MUSTA Mail Receiver sending failure reports MUST implement support for a "mailto:" URI, i.e., the ability to send message-specific failure information via electronic mail.
- MUST NOTIf the tag is not provided, Mail Receivers MUST NOT generate failure reports for the domain.
- OPTIONALsp: Domain Owner Assessment Policy for all subdomains of the given Organizational Domain (plain-text; OPTIONAL).
- MUSTIf both the "sp" tag is absent and the "np" tag is either absent or not applicable, the policy specified by the "p" tag MUST be applied for subdomains.
- OPTIONALt: DMARC policy test mode (plain-text; OPTIONAL; default is "n").
- REQUIREDv: Version (plain-text; REQUIRED).
- MUSTThis tag MUST be the first tag in the list.
- MUSTIf the tag is not the first in the list, the tag is absent, or the value is not "DMARC1", then the entire record MUST be ignored.
4.8 Formal Definition
- MUSTA DMARC Policy Record MUST comply with the formal definition found in this section.
- MUSTUnknown tags MUST be ignored.
- MUSTSyntax errors in the remainder of the record MUST be discarded in favor of default values (if any) or ignored outright.
- MUSTBecause unknown tags MUST be ignored, the addition of a new tag into the registered list of tags does not itself require a new version of DMARC to be generated (with a corresponding change to the "v" tag's value), but a change to any existing tags does require a new version of DMARC.
- MUSTdmarc-uri = URI ; "URI" is imported from [RFC3986]; ; commas (ASCII 0x2C) and exclamation ; points (ASCII 0x21) MUST be ; encoded
4.10.1 DMARC Policy Discovery
- MUST* If a "rua" tag is present and contains at least one syntactically valid reporting URI, the Mail Receiver MUST act as if a record containing "p=none" was retrieved and continue processing.
- MUST NOTIf the set produced by the DNS Tree Walk contains no DMARC Policy Record (i.e., any indication that there is no such record as opposed to a transient DNS error), Mail Receivers MUST NOT apply the DMARC mechanism to the message.
5.1.1 Publish an SPF Record for an Aligned Domain
- MUSTTo configure SPF for DMARC, the Domain Owner MUST send mail that has an RFC5321.MailFrom domain that will produce an SPF-Authenticated Identifier (Section 4.4.2) that has Identifier Alignment (Section 4.4) with the Author Domain.
5.1.2 Configure Sending System for DKIM Signing Using an Aligned
- MUSTTo configure DKIM for DMARC, the Domain Owner MUST send mail that has a DKIM Signing Domain (Section 3.2.3) that will produce a DKIM-Authenticated Identifier (Section 4.4.1) that has Identifier Alignment (Section 4.4) with the Author Domain.
5.1.6 Remediate Unaligned or Unauthenticated Mail Streams
- MUSTFor such legitimate uses, these shortcomings MUST be addressed prior to any attempt by the Domain Owner to publish a Domain Owner Assessment Policy (Section 3.2.8) of Enforcement (Section 3.2.9) for the Author Domain.
5.1.8 A Note on Large, Complex Organizations and Decentralized DNS
- MUSTTo avoid this circumstance, Domain Owners wishing to have a specific DMARC Policy Record applied to a given Author Domain (Section 3.2.2) longer than eight labels MUST publish a DMARC Policy Record at that domain's location in the DNS namespace, as such records are always queried by Mail Receivers that participate in DMARC before the Tree Walk begins.
5.2 PSO Actions
- MUSTIn addition to the DMARC Domain Owner actions, if a PSO (Section 3.2.16) publishes a DMARC Policy Record, it MUST include the "psd" tag (see Section 4.7) with a value of "y" ("psd=y").
5.3.1 Extract Author Domain
- MUSTIf the domain is a U-label, the domain MUST be converted to an A-label, as described in Section 2.3 of [RFC5890], for further processing.
- MAYIn the case where more than one domain is retrieved, the Mail Receiver MAY choose to go forward with DMARC validation anyway.
5.3.3 Determine If Authenticated Identifiers Exist
- MUST* For SPF, the preserved results MUST include "pass" or "fail".
- SHOULDIf the result is "fail", it SHOULD include information about the reasons for failure, if available.
- MUSTThe results MUST further include the domain name used to complete the SPF check.
- MUST* For DKIM signature validation checks, for each signature checked, the results MUST include "pass" or "fail".
- SHOULDIf the result is "fail", it SHOULD include information about the reasons for failure.
- MUSTThe results MUST further include the value of the "d" and "s" tags from each checked DKIM signature.
5.3.7 Store Results of DMARC Processing
- MUSTIf the Mail Receiver intends to send aggregate feedback reports and/ or failure reports, then results obtained from the application of the DMARC mechanism by the Mail Receiver MUST be preserved for eventual presentation back to the Domain Owner in the form of such reports.
5.3.8 Send Aggregate Reports
- SHOULDTo ensure maximum usefulness for DMARC across the email ecosystem, Mail Receivers SHOULD generate and send aggregate reports with a frequency of at least once every 24 hours.
5.3.9 Optionally Send Failure Reports
- MAYPer-message failure reports can be useful sources of information for a Domain Owner, either for debugging deployments or in analyzing attacks, and so Mail Receivers MAY choose to send them.
5.4 Policy Enforcement Considerations
- MAYSuch authorization does not carry an explicit or implicit value assertion about that message or the Domain Owner, and Mail Receivers MAY choose to reject or quarantine a message even if it passes the DMARC validation check.
- MAYMail Receivers MAY choose to accept email that fails the DMARC validation check even if the published Domain Owner Assessment Policy is "reject".
- SHOULD NOTIn particular, because of the considerations discussed in [RFC7960] and in Section 7.4 of this document, it is important that Mail Receivers SHOULD NOT reject messages solely because of a published policy of "reject" but that they apply other knowledge and analysis to avoid situations such as rejection of legitimate messages sent in ways that DMARC cannot describe, harm to the operation of mailing lists, and similar.
- SHOULDAt a minimum, Mail Receivers SHOULD add the Authentication-Results header field (see [RFC8601]), and it is RECOMMENDED when delivering messages that fail the DMARC validation check.
- SHOULDWhen Mail Receivers deviate from a published Domain Owner Assessment Policy during message processing, they SHOULD make available the fact of and reason for the deviation to the Domain Owner via feedback reporting, specifically using the "PolicyOverride" feature of the aggregate report defined in [RFC9990].
- MUST NOTTo enable Domain Owners to receive DMARC feedback without impacting existing mail processing, discovered policies of "p=none" MUST NOT modify existing mail handling processes.
7.4 Interoperability Considerations
- MUST NOTIt is therefore critical that domains that publish "p=reject" MUST NOT rely solely on SPF to secure a DMARC pass and MUST apply valid DKIM signatures to their messages.
- SHOULD NOTIt is therefore critical that domains that host users who might post messages to mailing lists SHOULD NOT publish Domain Owner Assessment Policies of "p=reject".
- SHOULDAny such domains wishing to publish "p=reject" SHOULD first take advantage of DMARC aggregate report data for their domain to determine the possible impact to their users, first by publishing "p=none" for at least a month, followed by publishing "p=quarantine" for an equally long period of time, and comparing the message disposition results.
- SHOULDDomains that choose to publish "p=reject" SHOULD implement policies that their users not post to Internet mailing lists and/or inform their users that their participation in mailing lists may be hindered.
- MUST NOTIt is therefore critical that Mail Receivers MUST NOT reject incoming messages solely on the basis of a "p=reject" policy by the sending domain.
- MUST"Other knowledge and analysis" here might refer to observed sending patterns for properly authenticated mail using the sending domain, content filtering, etc. In the absence of other knowledge and analysis, Mail Receivers MUST treat such failing mail as if the policy were "p=quarantine" rather than "p=reject".
8 Conformance Requirements for Full DMARC Participation
- MUST* MUST send mail so it produces an SPF-Authenticated Identifier that has Identifier Alignment with the Author Domain.
- MUST* MUST send mail that has a DKIM Signing Domain that will produce a DKIM-Authenticated Identifier that has Identifier Alignment with the Author Domain.
- MUST* MUST set up a mailbox to receive aggregate reports and collect and analyze those reports.
- MUST* MUST publish a DMARC Policy Record for the Author Domain and the Organizational Domain, if it differs from the Author Domain.
- MUST NOT* MUST NOT rely solely on SPF for a DMARC pass if the DMARC policy for the Author Domain is "p=reject".
- MUST* MUST check for the existence of a DMARC Policy Record for the Author Domain of an inbound mail message to determine if the DMARC mechanism applies to that message.
- MUST* MUST determine if Authenticated Identifiers exist for the message and preserve the results of those checks for future use in reporting if the DMARC mechanism applies to the message.
- MUST* MUST conduct necessary Identifier Alignment checks if the DMARC mechanism applies for the message and Authenticated Identifiers exist.
- MUST* MUST use the information from the checks for Authenticated Identifiers to determine if the DMARC validation result is "pass" or "fail" for the message.
- MUST* MUST support the "mailto:" URI for sending requested reports.
- SHOULD* SHOULD send aggregate reports on at least a daily basis.
- MUST NOT* MUST NOT reject messages solely on the basis of a "p=reject" policy for the Author Domain.
10.2 Failure Report Considerations
- MUST NOTDMARC Policy Records for multi-organizational PSDs MUST NOT include the "ruf" tag.
11.7 Secure Protocols
- SHOULDUnencrypted mechanisms SHOULD be avoided.
12.2 Informative References
- MUSTAgain, not all Mail Receivers will honor this request, but those that do MUST implement additional checks to validate that the third party authorizes reception of failure reports on behalf of this domain.
- MUSTBecause the address used in the "ruf" tag is outside the Organizational Domain in which this record is published, conforming Mail Receivers MUST implement additional checks as described in Section 3 of [RFC9990].
- SHOULD NOTIn particular, this document makes explicit that domains for general- purpose email SHOULD NOT deploy a DMARC policy of "p=reject".
- MAY| Receivers MAY impose a limit on the number of URIs to which they | will send reports but MUST support the ability to send to at least | two.
- SHOULD| A report SHOULD be sent to each listed URI provided in the DMARC | Policy Record.