DMARC – Explained

Before we start, it is important to understand two terms that will be used in this article:

• Envelope Sender
  This is the email address responsible for delivering the email, it is also referred to as MAIL FROM, Header Sender, Bounce Address, Return Address, Return Path, Reverse Path, or 2821 FROM, or 5321.MailFrom. When comparing an email with posted mail, this would be the return address mentioned on the envelope.
  
• Header From
  This is the email address that recipients see in the “From:” field, it is also referred to as Envelope From, or 5322.FromHeader. When comparing an email with posted mail, this would be the name on the letter head of the mail inside the envelope identifying who wrote the actual message.

DMARC fixes a major security flaw in the authentication standards SPF and DKIM, it protects a domain or brand from appearing in the Header From of spam, spoofing, and phishing emails.

Most ISPs and ESPs support DMARC and emails passing DMARC validation are generally given a better score when passing through their spam filters resulting in a better deliverability and improved inbox placement (avoid landing in the spam folder).

DMARC is a set via a single DNS-Record for an entire domain, it provides instructions to receiving mail servers on how to enforce the DMARC policy.

The Problem with SPF & DKIM

The architecture of both, SPF & DKIM, makes it impossible to prevent spam, spoofing, and phishing emails from being sent/received, even when both have passed their respective checks.

The Flaw in SPF based authentication

SPF clients MUST check the “MAIL FROM” identity.

RFC4408 Section 2.2

SPF-authentication is always done on the Envelope Sender‘s domain. The recipient has no guarantee the email really came from the Header From.

The Flaw in DKIM based authentication

DKIM authentication can be done on the Envelope Sender or Header From domain. So, while the DKIM check may pass using the Envelope Sender domain, the recipient has no guarantee the email really came from the Header From.

DMARC Domain Alignment

Domain Alignment is a concept in DMARC that expands the domain validation intrinsic of SPF and DKIM. DMARC domain alignment always matches the “Header From” domain of an email with information related to SPF and/or DKIM:

• For SPF, the Header From and Envelope Sender must have a matching (root) domain
• For DKIM, the Header From and the DKIM-Signature’s d flag must have a matching (root) domain

The aspf and/or adkim tags define the DMARC Domain Alignment method(s), the possible options are:

• relaxed
  matching root domains, but allowing different subdomains (default)
• strict
  precisely matching the entire (sub-)domain

Both tags are optional and default to relaxed.

SPF and/or DKIM Based Domain Alignment

While the check is always done on both authentication methods, only one of them is required to pass Domain Alignment in order to pass DMARC validation.

Whether SPF, or DKIM, or both will pass Domain Alignment depends on the circumstances under which an email is sent.

If you are using an ESP to deliver emails for your domain, then Domain Alignment will most likely only pass using DKIM, as it allows the Header From (you) and the Envelope Sender (ESP) to have different domains.

This would pass SPF-based DMARC Domain Alignment:

SPF based Domain Alignment may be impossible to achieve in some sending scenarios, because it requires the Envelope Sender and Header From to use an least an identical root domain. Most Email Service Provider (to send a Newsletter) put themselves in the Envelope Sender which uses the ESP’s domain, while the Header From uses the Domain of the actual sender, so a Domain Alignment based using SPF is not possible.

Strict (exact domain match)	Relaxed (root domain match)
Envelope From: [email protected] Envelope Sender: [email protected]	Envelope From: [email protected] Envelope Sender: [email protected]
Envelope From: [email protected] Envelope Sender: [email protected]	Envelope From: [email protected] Envelope Sender: [email protected]

This would pass DKIM-based DMARC Domain Alignment:

DKIM based Domain Alignment is fairly easy to achieve, as it only requires a DKIM Signature that can be decoded with a DKIM Key hosted on the Header From domain’s DNS Zone. It doesn’t matter which server or Envelope Sender is delivering the email, nor do their domains have to match.

Strict (exact domain match)	Relaxed (root domain match)
Envelope From: [email protected] DKIM Signature: d=janos.work;	Envelope From: [email protected] DKIM Signature: d=infos.janos.work;
Envelope From: [email protected] DKIM Signature: d=news.janos.work;	Envelope From: [email protected] DKIM Signature: d=infos.janos.work;

DMARC DNS-Record Tags

Required Tags

Tag Name	Purpose	Value
Version	The v tag represents the protocol version. It must be the first tag.	v=DMARC1
Policy	The required p tag defines the handling policy for Emails that fail DMARC authentication. It directs the receiver to report, quarantine, or reject emails that fail authentication checks.	p=none The result of the DMARC authentication doesn’t change how email is handled by the receiving mail server. This option should only be used for testing purposes. p=quarantine This policy sets aside questionable emails for further processing, which are usually exiled to the “Junk” folder. p=reject The receiving mail server is directed to reject messages that fail DMARC authentication.

Optional Tags

Tag Name	Purpose	Values
Subdomain Policy	The optional sp tag defines the handling policy for ALL subdomains. It functions exactly like the p tag.	sp=none The result of the DMARC authentication doesn’t change how email is handled by the receiving mail server. This option should only be used for testing purposes. sp=quarantine This policy sets aside questionable emails for further processing, which are usually exiled to the “Junk” folder. sp=reject The receiving mail server is directed to reject messages that fail DMARC authentication.
Percentage	The optional pct tag defines the percentage of email messages subjected to filtering.	pct=20 20% of Emails received by the recipient’s server will be checked
RUA Report Email Address(s)	The optional rua tag defines the Addresse(s) to which aggregated DMARC reports are sent by recipient mail servers	rua=mailto:[email protected] rua=mailto:[email protected], [email protected]
RUF Report Email Address(s)	The optional ruf tag defines the Addresse(s) to which message-specific forensic information is to be sent by recipient mail servers	ruf=mailto:[email protected]
ADKIM Tag	The optional adkim tag defines the alignment mode for the DKIM protocol.	adkim=s strict alignment adkim=r relaxed alignment [Default]
ASPF Tag	The optional aspf tag defines the alignment mode for SPF. An optional tag, aspf=r is a common example of its configuration.	aspf=s strict alignment aspf=r relaxed alignment [Default]
Failure Reporting Options	The optional fo tag defines how forensic reports are created and presented to DMARC users	fo=0 Generate a DMARC failure report, if all underlying authentication mechanisms (SPF and DKIM) fail to produce an aligned “pass” result. [Default] fo=1 Generate a DMARC failure report, if any underlying authentication mechanism (SPF or DKIM) produced something other than an aligned “pass” result. [Recommended] fo=d Generate a DKIM failure report, if the message had a signature that failed evaluation, regardless of its alignment. fo=s Generate an SPF failure report, if the message failed SPF evaluation, regardless of its alignment.
Report Format	The optional rf tag defines the forensic reporting format(s)	rf=afrf “Authentication Failure Reporting Format” (afrf) is the only value currently supported and therefore [Default]. This flag should only be set for testing. According to the specifications, receiving servers seeing a different value should ignore it or disregard the entire DMARC record.
Report Interval	The optional ri tag defines the aggregate reporting interval	ri=86400 The DMARC Report Interval tag is used to define the reporting interval between when aggregate reports should be sent, it defaults to 86,400 seconds (24 hours), which is the shortest possible interval. Set to receive DMARC reports less often (48 hours, 72 hours, etc.).

Note: Depending on the volume sent, the RUA Report Email Address(s) may receive thousands of aggregated DMARC reports per day! There are software solutions that help analyze them.

Warning: Sending emails to any of the email addresses mentioned in the tables above will result in a permanent ban.

Actual DMARC DNS record

_dmarc.janos.work. TXT "v=DMARC1; p=quarantine"

---

Sources & Further Reading

Official & Regulatory

• Domain-based Message Authentication, Reporting & Conformance (DMARC)
  https://dmarc.org/overview/

Industry

• DMARC Tags
  https://mxtoolbox.com/dmarc/details/dmarc-tags
• What is DomainKeys Identified Mail (DKIM) alignment for DMARC?
  https://help.returnpath.com/hc/en-us/articles/220564567-What-is-DomainKeys-Identified-Mail-DKIM-alignment-for-DMARC-
• What is Sender Policy Framework (SPF) alignment for DMARC?
  https://help.returnpath.com/hc/en-us/articles/224236627-What-is-Sender-Policy-Framework-SPF-alignment-for-DMARC-
• What are the SPF, DKIM and DMARC tools and how do they operate?
  https://freshmail.com/blog/spf-dkim-dmarc-tools-what-are-they-and-why-are-they-useful/