HOWTO - Define a DMARC Record

The Domain-based Message Authentication, Reporting and Conformance (DMARC) DNS record allows an email sender (which is already using DKIM, SPF or both) to indicate to a mail receiver one or more of the following:

Indicate the mechanisms the sender uses to authenticate its email (DKIM, SPF or both). Some of this functionality is already provided for separately within DKIM (the ADSP capability) and SPF (the pre field) but DMARC enables a comprehensive definition covering both systems.
Indicate comprehensively for DKIM, SPF or both how to handle mail that fails validity checks.
Optionally requests the receiver to send a feedback report (defined by the Abuse Report Format - RFC 5965 or the Incident Object Description Exchange Format - RFC 5070) which allows the mail sender to monitor and change its policies based on receiver feedback. Both individual and aggregate report formats are allowed. This capability is uniquely triggered by the DMARC RR.

DMARC can be viewed as a meta RR that describes the sender's email policy, comprising DKIM or SPF or both, for any domain. While the draft RFC does not explicitly say anything about the ADSP feature of DKIM it does go out of its way to identify ADSP shortcomings. On balance it would probably be confusing, if not a serious mistake, to have both ADSP and DMARC RRs for any domain.

DMARC is defined by RFC 7489. The DMARC.org web site claims that more than 2 billion email accounts are covered by DMARC. RFC 7960 describes various methods by which, what it charmingly calls 'indirect email flows', can be prevented from wreaking untold havoc on email delivery to DMARC enabled recipients.

DMARC TXT RR

DMARC uses the universally supported TXT RR with a specially formatted text field containing the application specific data (or DMARC data). This approach removes the need for upgrades to DNS software and is used both by SPF and DKIM. While use of the TXT RR is a pragmatic approach many in the DNS community find such overloading of the TXT RR evil incarnate, however, equally many disapprove of RR proliferation. Sigh.

The generic format of the DMARC TXT RR is:

_dmarc     IN    TXT "dmarc specific text"
; alternatively
_dmarc.domain.name. IN  TXT "dmarc specific text"

The left-hand owner-name is always _dmarc (or in FQDN form _dmarc.domain.name.) which allows the receiving domain to discover the existence (or not) of DMARC data in a manner similar to that used by the SRV RR.

The value of domain.name is based on both what the specification calls an Organisational Name and a left-most name depth algorithm. The organizational name is derived by the Receiving Mail Transfer Agent (MTA) from a table called a public suffix list which essentialy defines, for any tld, how many labels would be present in a registered (or organizational) domain name, for instance, for .com this would be the first label to the left of .com and for .uk this would be next two labels to the left of .uk. The draft RFC does not define a central authority for this public suffix list but does point to a list maintained by Mozilla and used by a number of different applications.

Note: The public suffix list is not used by the email sender or the DNS only by the receiving MTA.

The DMARC TXT RR is placed at the domain.name to which it or any names to its left, or in DNS jargon to any deeper names, applies. The following examples illustrate this coverage:

$ORIGIN example.com.
...
_dmarc   IN  TXT "dmarc specific text"
; above DMARC RR applies to (has scope over) any email of the form
; user@example.com or user@s1.example.com 
; or user@s2.s1.example.com etc.
; However if the following DMARC RR is added
_dmarc.sx  IN TXT "dmarc specific text" 
; then it will NOT apply to (does not have scope over) 
; user@example.com, user@s1.example.com or user@s2.s1.example.com
; but will apply to (has scope over) any email of the form
; user@sx.example.com or user@sy.sx.example.com etc.

Thus, any number of DMARC RRs may be added - each covering a unique name or a name space - to define variable mail policies based on the domain.name used.

DMARC Specific Data

The DMARC specific data is organized as one or more tag=value pairs each separated by a ';' (semi-colon) as shown below:

_dmarc IN TXT "tag=value[;tag=value ...]
; TXT RRs may use the standard DNS multi-line format to make clearer
_dmarc  IN TXT ("tag=value;"
                  "tag=value")

The following section describes the currently supported tags=value pairs and the examples section show a number of possible and common implementations.

Tag=Value Parameters

Tag=

Value

Notes

DMARC1

Mandatory. This must be the first supplied tag=value within the dmarc specific text and, while DMARC tag=value pairs are not case sensitive, this one must have the explicit upper-case value DMARC1.

May take one of the following values:

none	No specific advice is offered to the receiving MTA.
quarantine	Advises the receiving MTA to treat any email that fails any DKIM and/or SPF checks as suspicious and perform additional checks or mark the mail as suspected SPAM or whatever local policy is in operation.
reject	Advises the receiving MTA to reject any email that fails any DKIM and/or SPF checks.

Mandatory and must be the second tag=value pair. Defines the policy the sending MTA advises the receiving MTA to follow.

sp=

Same values as for p= (reject, quarantine, none)

Optional. If not present the p= policy is assumed to cover the domain.name and all its subdomains. If sp= is present it indicates the defined policy that applies to subdomains of the domain.name at which the DMARC RR was discovered and not the name itself (the domain.name in this case is covered by the p= tag=value pair). Thus, if the following DMARC RR is present:

$ORIGIN example.com.
...
_dmarc  IN TXT "v=DMARC1;p=reject;sp=quarantine"

Then failed mail from user@example.com would be rejected but mail from user@a.example.com or user@b.a.example.com or user@anything.example.com would be quarantined.

adkim=

r (relaxed - default) or s (strict) mode

Optional (if omitted defaults to adkim=r). In strict mode the sender domain name must exactly match the corresponding d=name (in the DKIM mail headers). In relaxed mode any subdomain of d=domain (in the mail headers) will also be accepted. Thus if d=example.com in the mail header then mail from user@example.com will pass from either adkim = r or adkim=s, however, mail from user@a.example.com will fail if adkim=s but pass if adkim=r.

aspf=

r (relaxed) or s (strict) mode

Optional (if omitted defaults to aspf=r). In strict mode the domain.name in the MAIL FROM command (in SMTP) and the from: header (in the mail item) must match exactly. In relaxed mode any valid subdomain of domain.name is acceptable.

pct=

value from 0 to 100

Optional. Defines the percentage of mail to which the DMARC policy applies. If omitted defaults to pct=100 (100%) - all mail is subject to DMARC processing. This parameter allows mail senders to experiment with a small percentage of mail being subject to DMARC action. Problems can be progressively eliminated from the system before turning DMARC on for all mail.

fo=

May take one or more of the following values:

0	Generate report to the sending MTA if all underlying checks failed. Thus, if only DKIM is used to secure mail and the DKIM check fails a report will be sent, if only SPF is used to secure mail and the SPF check fails a report will be sent. However, if both DKIM and SPF are used and, say, the SPF check fails but the DKIM check passes a report WILL NOT be sent.
1	Generate report to the sending MTA if any underlying check failed. Thus, if only DKIM is used to secure mail and the DKIM check fails a report will be sent, if only SPF is used to secure mail and the SPF check fails a report will be sent. However, if both DKIM and SPF are used and, say, the SPF check fails but the DKIM check passes a report WILL be sent.
d	Generate a report if DKIM checks fail.
s	Generate a report if SPF checks fail.

Optional (defaults to fo=0). Defines the error reporting policy the sending MTA requests from the receiving MTA. Multiple options may be defined using colon (:) separated values, for example, fo=0:s

rf=

May take one or more of the following values:

afrf	Message format for error reporting (Abuse Report format) is defined by RFC 5965.
iodef	Message format for error reporting (Incident Object Description Exchange Format) is defined by RFC 5070.

Optional (defaults to rf=afrf). Defines the reporting format the sending MTA requests from the receiving MTA.

ri=

Defines the time in seconds between reports requested from the receiving MTA

Optional (if omitted defaults to ri=86400 - 24 hours). Defines the reporting interval in seconds. receivimg MTAs must be able to send daily (86400) reports and should be able to send hourly (3600) reports but on a best efforts basis. Implicitly anything less than 1 hour (3600) can be rounded up to 1 hour by the receiving MTA.

rua=

A comma delimited list of URI(s) to which aggregate mail reports should be sent

Optional. If not present aggregate reports will not be sent from the receiving MTA. URIs must be of the format mailto:user@example.com (implicit in the draft RFC). Aggregate report format is defined in section 7.2 of the draft RFC. Where a mailto address is lies with the sending zone no additional configuration is required, however if the mailto address lies outside the sending zone an additional empty DMRC RR is required. Thus, if the email sending zone is example.net and the DMARC TXT RR contains the parameter rua=mailto:dmarc-admin@example.net this lies inside the sending zone and no additional configuration is required. If, however the email sending zone is example.net and the DMARC TXT RR in the zone file for example.net contains the parameter rua=mailto:dmarc-admin@example.com this lies outside the sending zone and the zone example.com must validate that it will accept reports for the example.net domain by having the following minimal DMARC TXT RR:

# example.com zone file fragment
$ORIGIN example.com.
...
# authorises the receiving of DMARC reports for example.net
example.net._report._dmarc     TXT  "v=DMARC1"

ruf=

A comma delimited list of URI(s) to which detailed failure reports should be sent

Optional. If not present detailed failure reports will not be sent from the receiving MTA. URIs must be of the format mailto:user@example.com (implicit in the draft RFC). Where a mailto address is lies with the sending zone no additional configuration is required, however if the mailto address lies outside the sending zone an additional empty DMRC RR is required. Thus, if the email sending zone is example.net and the DMARC TXT RR contains the parameter rua=mailto:dmarc-admin@example.net this lies inside the sending zone and no additional configuration is required. If, however the email sending zone is example.net and the DMARC TXT RR in the zone file for example.net contains the parameter rua=mailto:dmarc-admin@example.com this lies outside the sending zone and the zone example.com must validate that it will accept reports for the example.net domain by having the following minimal DMARC TXT RR:

# example.com zone file fragment
$ORIGIN example.com.
...
# authorises the receiving of DMARC reports for example.net
example.net._report._dmarc     TXT  "v=DMARC1"

Examples

Example 1: Single Domain Name using DKIM and SPF - Aggressive

This is an aggressive policy and should only be adopted where the sender is certain that both DKIM and SPF are correctly configured. Not for the faint-hearted. Assume the domain example.net only sends mail in the form user@example.net (mail is not sent from any subdomain) and that both DKIM and SPF are used in relaxed format. The domain owner wishes to have a daily aggregate report from mail receivers (in Abuse Report format - RFC 5965) of any problems at the address dmarc-admin@example.com if either SPF or DKIM fails, suggests that mail failing any checks should be rejected and that 100% of mail should be checked. The following addition to example.net's zone file implements such a policy:

# example.net zone file fragment
$ORIGIN example.net.
...
_dmarc   TXT ( "v=DMARC1;p=reject;sp=reject;pct=100;"
   "adkim=r;aspf=r;fo=1;ri=86400;rua=mailto:dmarc-admin@example.com")

# NOTE: since the required email address is out-of-zone the 
# following change to the zone file for example.com must be made
# example.com zone file fragment
$ORIGIN example.com.
...
example.net._report._dmarc   TXT "v=DMARC1"
# functionally identical
example.net._report._dmarc.example.com.   TXT "v=DMARC1"
...

Strictly, the adkim=, aspf=, ri= and pct= are not necessary since their defaults are used. However, explicit use of defaults is good defensive configuration policy, and can prevent catastrophic errors in the event that a default is subsequently changed. The use of an out-of-zone email address requires an additional change in the report receivers zone file (example.com in this case) to authorize the reports from the example.net organizational name (see rua/ruf parameters.

Example 2: Single Domain Name using DKIM and SPF - Timid

This is a timid (or cautious if you prefer) policy where the sender is discovering the real pathology of their mail service and is unsure (or has no idea) if either DKIM and SPF are correctly configured. Assume the domain example.net only sends mail in the form user@example.net (mail is not sent from any subdomain) and that both DKIM and SPF are used in relaxed format. The domain owner wishes to have a daily aggregate report from mail receivers (in Abuse Report format - RFC 5965) of any problems at the address dmarc-admin@example.net if either SPF or DKIM fails, does not want the receiver to reject any failing mail and suggests that only 10% of mail should be checked. The following addition to example.net's zone file implements such a policy:

# example.net zone file fragment
$ORIGIN example.net.
...
_dmarc   TXT ( "v=DMARC1;p=none;sp=reject;pct=10;"
   "adkim=r;aspf=r;fo=1;ri=86400;rua=mailto:dmarc-admin@example.net")

Strictly, the adkim=, aspf=, ri= and pct= are not necessary since their defaults are used. However, explicit use of defaults is good defensive configuration policy.

Example 3: Single Domain Name using SPF only - Aggressive

This is an aggressive policy and should only be adopted where the sender is certain that SPF is correctly configured. Assume the domain example.net only sends mail in the form user@example.net (mail is not sent from any subdomain) and that only SPF is used in relaxed format. The domain owner wishes to have a daily aggregate report from mail receivers (in Abuse Report format - RFC 5965) of any problems at the address dmarc-admin@example.net if SPF checks fail, suggests that all mail failing the SPF checks should be rejected and that 100% of mail should be checked. The following addition to example.net's zone file implements such a policy:

# example.net zone file fragment
$ORIGIN example.net.
...
_dmarc   TXT ( "v=DMARC1;p=reject;sp=reject;pct=100;"
   "aspf=r;fo=0;ri=86400;rua=mailto:dmarc-admin@example.net")

Strictly, the aspf=, ri= and pct= are not necessary since their defaults are used. However, explicit use of defaults is good defensive configuration policy. It is the presence or absence of either DKIM headers or an SPF RR tested when the mail arrives at the receiver that determine which mail security method is in use rather than the configuration of the DMARC RR. In this case we have eliminated the adkim= to make the actual policy explicit and, since only SPF is in operation, fo=0. The same functional result would have ocurred if adkim=r had been retained and fo=1 as in Example 1 above. If only DKIM was being used adkim=r would have been added and aspf=r removed - but again the previous comment also applies - it is the received mail that determines which checks are invoked not the DMARC RR.

Example 4: No mail

This is a supreme act of good neighborliness. Assume the domain never sends email. The presence of a DMARC is good practice since mail could be forged with the domain's name. There is, however, no way to explictly configure a DMARC RR to indicate that mail will never be sent from this domain. Again, this emphasizes the point that DMARC processing is only invoked once the incoming mail protection mechanisms have been discovered. To indicate that a domain will never send mail must be done with a DMARC RR AND a dummy SPF TXT RR as shown:

# example.net zone file fragment
$ORIGIN example.net.
...
# negative (or dummy) SPF RR
example.net. TXT "v=spf1 -all"
...
_dmarc   TXT "v=DMARC1;p=reject;sp=reject;pct=100;aspf=s"

In this case the DMARC is simply saying reject any mail from this domain that fails the SPF check and the SPF TXT RR, by use of the -all ensures that all mail fails the SPF test. Net result - no mail is allowed to be sent from this domain name.

Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.