Domain-based Message Authentication, Reporting, and Conformance (DMARC)

From InboxSys document library
Revision as of 01:58, 31 August 2023 by Sebastian (talk | contribs)
Jump to navigation Jump to search

A DMARC record is a DNS TXT record for a subdomain named _dmarc on any senderdomain.

Example: 

$ host -t txt _dmarc.senderdomain.TLD
_dmarc.senderdomain.TLD descriptive text "v=DMARC1; p=reject; rua=mailto:dmarc@dmarc.example.com; ruf=mailto:dmarc@dmarc.example.com; rf=afrf; pct=100;"

On which domains to set a DMARC record

DMARC records can be placed on the organisational domain as well as on subdomains. A subdomain that has no DMARC record inherits its DMARC record from the organisational domain. It is recommended to place a DMARC record on every organisational domain.

RFC7489 Section 3.1 states:

DMARC authenticates use of the RFC5322.From domain by requiring that it match (be aligned with) an Authenticated Identifier. The RFC5322.From domain was selected as the central identity of the DMARC mechanism because it is a required message header field and therefore guaranteed to be present in compliant messages, and most Mail User Agents (MUAs) represent the RFC5322.From field as the originator of the message and render some or all of this header field's content to end users.

RFC7489 Section 2.2 mentions to be "out of scope":

evaluation of anything other than RFC5322.From;

Policy (p)

The main purpose for DMARC is to set a policy (p). This policy contains the action that should take place when unauthenticated mail from this domain is received (and in no other case). The options are:

  • none: to do nothing when authentication fails
  • quarantine: to put the mail in the Spam folder when authentication fails
  • reject: to the message when authentication fails.

Only by using the reject policy can a domain be fully protected. "Unauthenticated" means, SPF and / or DKIM do not align.

DMARC allows ISPs to rely not only on IP reputation, but also on domain reputation. Especially when sending via shared IPs, a good domain reputation can be helpful in delivering your emails to the right place. Without a DMARC record it is impossible for ISPs to reliably measure reputation for a domain.

It is a common mistake to configure DMARC for reporting (with "p" set to "none" or "quarantine") and to forget about it afterwards. Loss in reputation comes gradually over time and is often only noticed when it's already too late. By thumb of fist it takes about as long to fix a broken reputation as it has taken this reputation to break.

Reports (ruf/rua)

A secondary functionality of DMARC enables ISPs to send reports about the authentication success or failure for a domain. Those reports are sent to the addresses defined in two switches:

  • rua: aggregated reports (recommended)
  • ruf: forensic reports (not recommended)

Bot ruf and rua switch should contain a functional mailto-link where failure- and aggregated reports can be sent. It's important to receive, read and process those reports. The following example configures DMARC for all reporting, but reporting only (test-mode): 

$ host -t txt _dmarc.sub.domain.TLD
_dmarc.sub.domain.TLD descriptive text "v=DMARC1; p=none; rua=mailto:dmarc@dmarc.example.com; ruf=mailto:dmarc@dmarc.example.com;"

DMARC reporting alone - as in the above example - does not provide protection against phishing and consequent loss in reputation. It provides reporting functionality only. Such a setting can be useful when evaluating the impact of switching the policy to reject. It is not useful in protecting your domain.

Once the reports show it's safe to reject unauthenticated mail, the following example provides full protection: 

$ host -t txt _dmarc.sub.domain.TLD
_dmarc.sub.domain.TLD descriptive text "v=DMARC1; p=reject; rua=mailto:dmarc@dmarc.example.com;"

Forensic reports (ruf)

Forensic reports (ruf) are very rare for 2 reasons:

  • High volume: failure reports generate a single report for each individual mail that failed authentication.
  • Privacy: Failure Reports are not compliant to GDPR. ARF Reports generally contain personal data, such as IPs.

It is generally recommended to refrain from setting a ruf-switch at all.

Alignment (adkim/aspf)

Alignment means, domains used for authentication mechanisms match with the sender domain (RFC5321.MailFrom or "returnpath"). DMARC only passes when either SPF identifiers or DKIM align.

  • The domain used to authenticate SPF is the RFC5321.MailFrom domain or "sender domain". To see SPF identifier aligment, it's required for the RFC5321.MailFrom domain to match the RFC5322.From domain.
  • The domain used to authenticate DKIM is the domain used by the sending mail server to sign DKIM. To see DKIM identifier aligment, it's required for the domain used to sign DKIM to match the RFC5322.From domain.

Here is an example of a DMARC record with aspf and adkim switches set to "strict": 

$ host -t txt _dmarc.sub.domain.TLD
_dmarc.sub.domain.TLD descriptive text "v=DMARC1; p=reject; aspf=s; adkim=s;"
  1. aspf: SPF alignment. Options are "s" for "strict" or "r" for "relaxed".
  2. adkim: SPF alignment. Options are "s" for "strict" or "r" for "relaxed".
  • Strict alignment means, the matching domains are exactly the same.
  • Relaxed alignment means, the matching domains have a same superior domain. For example, mail.example.com and bounce.example.com would align relaxed.

The adkim and aspf switches are optional. The default value for adkim and aspf is "r".

Useful links

Retrieved from "https://docs.inboxsys.com/index.php?title=Domain-based_Message_Authentication,_Reporting,_and_Conformance_(DMARC)&oldid=140"