Skip to main content

6. Policy

DMARC policies are published by Domain Owners and applied by Mail Receivers.

A Domain Owner advertises DMARC participation of one or more of its domains by adding a DNS TXT record (described in Section 6.1) to those domains. In doing so, Domain Owners make specific requests of Mail Receivers regarding the disposition of messages purporting to be from one of the Domain Owner's domains and the provision of feedback about those messages.

A Domain Owner may choose not to participate in DMARC evaluation by Mail Receivers. In this case, the Domain Owner simply declines to advertise participation in those schemes. For example, if the results of path authorization checks ought not be considered as part of the overall DMARC result for a given Author Domain, then the Domain Owner does not publish an SPF policy record that can produce an SPF pass result.

A Mail Receiver implementing the DMARC mechanism SHOULD make a best-effort attempt to adhere to the Domain Owner's published DMARC policy when a message fails the DMARC test. Since email streams can be complicated (due to forwarding, existing RFC5322.From domain-spoofing services, etc.), Mail Receivers MAY deviate from a Domain Owner's published policy during message processing and 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 (see Section 7.2).

6.1. DMARC Policy Record​

Domain Owner DMARC preferences are stored as DNS TXT records in subdomains named "_dmarc". For example, the Domain Owner of "example.com" would post DMARC preferences in a TXT record at "_dmarc.example.com". Similarly, a Mail Receiver wishing to query for DMARC preferences regarding mail with an RFC5322.From domain of "example.com" would issue a TXT query to the DNS for the subdomain of "_dmarc.example.com". The DNS-located DMARC preference data will hereafter be called the "DMARC record".

DMARC's use of the Domain Name Service is driven by DMARC's use of domain names and the nature of the query it performs. The query requirement matches with the DNS, for obtaining simple parametric information. It uses an established method of storing the information, associated with the target domain name, namely an isolated TXT record that is restricted to the DMARC context. Use of the DNS as the query service has the benefit of reusing an extremely well-established operations, administration, and management infrastructure, rather than creating a new one.

Per [DNS], a TXT record can comprise several "character-string" objects. Where 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.

6.2. DMARC URIs​

[URI] defines a generic syntax for identifying a resource. The DMARC mechanism uses this as the format by which a Domain Owner specifies the destination for the two report types that are supported.

The place such URIs are specified (see Section 6.3) allows a list of these to be provided. A report is normally sent to each listed URI in the order provided by the Domain Owner. 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. The list of URIs is separated by commas (ASCII 0x2C).

Each URI can have associated with it a maximum report size that may be sent to it. This is accomplished by appending an exclamation point (ASCII 0x21), followed by a maximum-size indication, before a separating comma or terminating semicolon.

Thus, a DMARC URI is a URI within which any commas or exclamation points are percent-encoded per [URI], followed by an OPTIONAL exclamation point and a maximum-size specification, and, if there are additional reporting URIs in the list, a comma and the next URI.

For example, the URI "mailto:reports@example.com!50m" would request that a report be sent via email to "[email protected]" so long as the report payload does not exceed 50 megabytes.

A formal definition is provided in Section 6.4.

6.3. General Record Format​

DMARC records follow the extensible "tag-value" syntax for DNS-based key records defined in DKIM [DKIM].

Section 11 creates a registry for known DMARC tags and registers the initial set defined in this document. Only tags defined in this document or in later extensions, and thus added to that registry, are to be processed; unknown tags MUST be ignored.

The following tags are introduced as the initial valid DMARC tags:

adkim: (plain-text; OPTIONAL; default is "r".) Indicates whether strict or relaxed DKIM Identifier Alignment mode is required by the Domain Owner. See Section 3.1.1 for details. Valid values are as follows:

  • r: relaxed mode
  • s: strict mode

aspf: (plain-text; OPTIONAL; default is "r".) Indicates whether strict or relaxed SPF Identifier Alignment mode is required by the Domain Owner. See Section 3.1.2 for details. Valid values are as follows:

  • r: relaxed mode
  • s: strict mode

fo: Failure reporting options (plain-text; OPTIONAL; default is "0") Provides requested options for generation of failure reports. Report generators MAY choose to adhere to the requested options. This tag's content MUST be ignored if a "ruf" tag (below) is not also specified. The value of this tag is a colon-separated list of characters that indicate failure reporting options as follows:

  • 0: Generate a DMARC failure report if all underlying authentication mechanisms fail to produce an aligned "pass" result.
  • 1: Generate a DMARC failure report if any underlying authentication mechanism produced something other than an aligned "pass" result.
  • d: Generate a DKIM failure report if the message had a signature that failed evaluation, regardless of its alignment. DKIM-specific reporting is described in [AFRF-DKIM].
  • s: Generate an SPF failure report if the message failed SPF evaluation, regardless of its alignment. SPF-specific reporting is described in [AFRF-SPF].

p: Requested Mail Receiver policy (plain-text; REQUIRED for policy records). Indicates the policy to be enacted by the Receiver at the request of the Domain Owner. Policy applies to the domain queried and to subdomains, unless subdomain policy is explicitly described using the "sp" tag. This tag is mandatory for policy records only, but not for third-party reporting records (see Section 7.1). Possible values are as follows:

  • none: The Domain Owner requests no specific action be taken regarding delivery of messages.
  • quarantine: The Domain Owner wishes to have email that fails the DMARC mechanism check be treated by Mail Receivers as suspicious. Depending on the capabilities of the Mail Receiver, this can mean "place into spam folder", "scrutinize with additional intensity", and/or "flag as suspicious".
  • reject: The Domain Owner wishes for Mail Receivers to reject email that fails the DMARC mechanism check. Rejection SHOULD occur during the SMTP transaction. See Section 10.3 for some discussion of SMTP rejection methods and their implications.

pct: (plain-text integer between 0 and 100, inclusive; OPTIONAL; default is 100). Percentage of messages from the Domain Owner's mail stream to which the DMARC policy is to be applied. However, this MUST NOT be applied to the DMARC-generated reports, all of which must be sent and received unhindered. The purpose of the "pct" tag is to allow Domain Owners to enact a slow rollout enforcement of the DMARC mechanism.

rf: Format to be used for message-specific failure reports (colon-separated plain-text list of values; OPTIONAL; default is "afrf"). The value of this tag is a list of one or more report formats as requested by the Domain Owner to be used when a message fails both SPF and DKIM tests to report details of the individual failure. Only "afrf" (the auth-failure report type defined in [AFRF]) is currently defined.

ri: Interval requested between aggregate reports (plain-text 32-bit unsigned integer; OPTIONAL; default is 86400). Indicates a request to Receivers to generate aggregate reports separated by no less than the requested number of seconds. DMARC implementations MUST be able to provide daily reports and SHOULD be able to provide hourly reports when requested. However, anything other than a daily report is understood to be accommodated on a best-effort basis.

rua: Addresses to which aggregate feedback is to be sent (comma-separated plain-text list of DMARC URIs; OPTIONAL). A comma-separated list of DMARC URIs to which aggregate feedback should be sent (see Section 6.2 for the specification of DMARC URIs). Any valid URI can be specified. A Mail Receiver MUST implement support for a "mailto:" URI, i.e., the ability to send a DMARC report via electronic mail. If not provided, Mail Receivers MUST NOT generate aggregate feedback reports. URIs not supported by Mail Receivers MUST be ignored. The aggregate feedback reports SHOULD use the format described in Section 7.2.

ruf: Addresses to which message-specific failure information is to be reported (comma-separated plain-text list of DMARC URIs; OPTIONAL). A comma-separated list of DMARC URIs to which message-specific failure reports should be sent (see Section 6.2 for the specification of DMARC URIs). If not provided, Mail Receivers MUST NOT generate failure reports. Mail Receivers MAY choose to send failure reports in a format other than [AFRF].

sp: Requested Mail Receiver policy for all subdomains (plain-text; OPTIONAL). Indicates the policy to be enacted by the Receiver at the request of the Domain Owner. It applies only to subdomains of the domain queried, and not to the domain itself. Its syntax is identical to that of the "p" tag defined above. If absent, the policy specified by the "p" tag MUST be applied for subdomains.

v: Version (plain-text; REQUIRED). Identifies the record retrieved as a DMARC record. It MUST have the value of "DMARC1". The value of this tag MUST appear first in the DMARC record. Example: "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

6.4. Formal Definition​

(Refer to RFC 7489 for complete ABNF syntax)

6.5. Domain Owner Actions​

To participate in DMARC, a Domain Owner needs to:

  1. Deploy SPF and/or DKIM for the domain.

  2. Ensure that the RFC5322.From domain aligns with the domains authenticated by SPF and/or DKIM.

  3. Publish a DMARC policy in the DNS.

  4. Monitor the feedback reports and adjust policy as needed.

6.6. Mail Receiver Actions​

Mail Receivers implement DMARC by querying the DNS for DMARC policy records and applying the requested policy to messages that fail DMARC evaluation.

6.6.1. Extract Author Domain​

The Mail Receiver needs to extract the domain from the RFC5322.From header field. The domain to be evaluated is the domain portion of the RFC5322.From field.

6.6.2. Determine Handling Policy​

The Mail Receiver determines the appropriate handling policy for the message by:

  1. Checking for a policy at "_dmarc.{RFC5322.From domain}".
  2. If none is found, applying the algorithm in Section 3.2 to determine the Organizational Domain and checking for a policy at "_dmarc.{Organizational Domain}".
  3. If still none is found, the Mail Receiver applies its own local policy.

6.6.3. Policy Discovery​

A Domain Owner can publish DMARC policy records at any point in its domain hierarchy. The Mail Receiver queries DNS for a DMARC TXT record at "_dmarc.{domain}". If none is found, the Organizational Domain is determined and the query is repeated for the Organizational Domain.

6.6.4. Message Sampling​

The "pct" tag allows Domain Owners to gradually deploy DMARC by specifying that only a percentage of messages should have the policy applied. Messages not selected by the "pct" mechanism are treated as if the "p" tag were set to "none".

6.7. Policy Enforcement Considerations​

Mail Receivers should consider the following when enforcing DMARC policies:

  1. Mailing Lists: Many mailing lists modify messages in ways that break DKIM signatures and cause SPF checks to fail.

  2. Forwarding: Simple forwarding does not break DKIM signatures but will cause SPF checks to fail.

  3. Local Policy: Mail Receivers may choose to override published DMARC policy based on local knowledge or policy.

  4. Reporting: When overriding policy, Mail Receivers should report this via the PolicyOverride feature in aggregate reports.

Last updated on