DMARC (Domain-based Message Authentication) - 6/9

The Conductor#

Published in 2015 (RFC 7489).

So far, we have seen that:

• SPF validates the IP but verifies the Return-Path, not the From.
• DKIM validates the content and verifies the signature domain (d=). It does not verify the From.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) does not offer a new technical authentication method, but a policy layer that builds on SPF and DKIM to solve the alignment problem.

DMARC uses the results of SPF and DKIM and adds a simple rule: For the email to be valid, the domain visible to the user (the From) must be “aligned” (identical) with at least one of the two authenticated protocols (either the SPF domain or the DKIM domain).

The 3 pillars of DMARC#

1. Alignment (Identifier Alignment): DMARC checks whether the From domain matches either the domain validated by SPF (that of the Return-Path) or the DKIM signature domain (the d= tag of the DKIM-Signature header field). This match is called “alignment”. This is what prevents a spammer from using, for example, Mailjet’s infrastructure (SPF valid for Mailjet) to send an email with From: president@whitehouse.gov. DMARC fails because whitehouse.gov is not aligned with mailjet.com. This mechanism is what finally prevents the spoofing of the visible address.
2. Policy: DMARC lets the domain owner tell the recipient what to do if validation fails. This is defined by the p= tag in DNS:

• p=none: Observation only. “Just tell me who is failing, but let the email through.” (Ideal for getting started and auditing.)
• p=quarantine: Suspicion. “Put the failing emails in the recipient’s Spam folder.”
• p=reject: Maximum protection. “Simply reject the failing emails. They will never arrive.”

3. Reporting (RUA/RUF): This is the feedback loop. Receiving servers (Gmail, Yahoo, etc.) send daily XML reports to the address defined in the DMARC record. This allows the administrator to know exactly who is sending emails on their behalf (legitimately or not) and to fix their configuration before switching to reject mode.

graph TD
  %% --- Styles ---
  classDef input fill:#e3f2fd,stroke:#1565c0,stroke-width:2px,color:#000
  classDef check fill:#fff9c4,stroke:#fbc02d,stroke-width:2px,color:#000
  classDef pass fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px,color:#000
  classDef fail fill:#ffcdd2,stroke:#c62828,stroke-width:2px,color:#000
  classDef policy fill:#e1bee7,stroke:#8e24aa,stroke-width:2px,color:#000
  %% --- STEP 1: THE EVIDENCE ---
  subgraph INPUTS ["1 - THE AVAILABLE EVIDENCE"]
      HeaderFrom["👤 Header FROM<br/>(What the user sees)"]:::input
      
      SPF_Res["🚚 SPF result<br/>(Return-Path domain)"]:::input
      DKIM_Res["🛡️ DKIM result<br/>(Signature domain d=)"]:::input
  end
  %% --- STEP 2: THE ALIGNMENT TEST ---
  subgraph ALIGNMENT ["2 - ALIGNMENT CHECK"]
      %% Invisible links to force the structure
      HeaderFrom --> CompareSPF
      HeaderFrom --> CompareDKIM
      
      CompareSPF{"Does the FROM match<br/>the SPF?"}:::check
      CompareDKIM{"Does the FROM match<br/>the DKIM?"}:::check
      
      SPF_Res --> CompareSPF
      DKIM_Res --> CompareDKIM
  end
  %% --- STEP 3: THE DMARC VERDICT ---
  subgraph VERDICT ["3 - OVERALL VERDICT"]
      FinalDecision{"At least ONE<br/>match?"}:::check
      
      CompareSPF --> FinalDecision
      CompareDKIM --> FinalDecision
      
      FinalDecision -- YES --> DMARC_OK["✅ DMARC PASS<br/>(Inbox)"]:::pass
      FinalDecision -- NO --> DMARC_FAIL["❌ DMARC FAIL<br/>(Not aligned)"]:::fail
  end
  %% --- STEP 4: POLICY ENFORCEMENT ---
  subgraph ENFORCEMENT ["4 - POLICY"]
      PolicyCheck["👮 Reading p=..."]:::policy
      
      DMARC_FAIL --> PolicyCheck
      
      PolicyCheck -- "p=none" --> ActNone["Let it through<br/>(Monitoring)"]:::policy
      PolicyCheck -- "p=quarantine" --> ActSpam["Spam folder"]:::policy
      PolicyCheck -- "p=reject" --> ActReject["🚫 Full rejection"]:::fail
  end

Going further#

The two alignment modes: relaxed and strict#

The alignment described above can be more or less tolerant. DMARC defines two modes, configurable independently for SPF and for DKIM via the aspf and adkim tags of the DMARC record:

• relaxed (default mode, value r): alignment is validated as long as the two domains share the same organizational domain (the registrable “root” domain, for example a.com for both bnc3.a.com and mail.a.com). A subdomain is therefore enough to align with its root domain.
• strict (value s): alignment requires an exact match of the domains. bnc3.a.com is then not considered aligned with a.com.

In the absence of the aspf=/adkim= tags, the relaxed mode applies. This is the most common behavior, and it is what makes the custom Return-Path technique described below possible.

Aligning SPF: the custom Return-Path#

Recall that SPF is evaluated on the envelope domain (the Return-Path), not on the From. For DMARC, it is therefore not enough for SPF to be PASS: the domain thus validated must also be aligned with the From.

Now, by default, an ESP handles bounces under its own domain. Take Mailjet:

• The default Return-Path is of the form …@bnc3.mailjet.com.
• SPF is PASS there (the IP is indeed authorized by mailjet.com), but the validated organizational domain is mailjet.com, whereas the From is …@a.com.
• SPF alignment fails: mailjet.com ≠ a.com.

The workaround is to configure a custom Return-Path: you publish a subdomain of your own domain (for example bnc3.a.com) as a CNAME to the ESP’s bounce infrastructure (bnc3.mailjet.com). The envelope then carries …@bnc3.a.com, whose organizational domain is a.com: SPF alignment passes (in relaxed mode).

Note: this custom Return-Path is not strictly required for DMARC to pass. ESPs also delegate the DKIM signature under your domain (via selector CNAMEs), which provides DKIM alignment. Since DMARC is satisfied with the alignment of just one of the two protocols, an aligned DKIM is enough. The custom Return-Path therefore mainly adds robustness (DMARC then rests on two aligned channels instead of one), and some also like it for having their own domain appear in the Return-Path.

Where to publish (or not) a provider’s SPF#

Everything above boils down to a simple rule, which often puzzles people:

• If the bounces of a mailing are handled under your domain — a subdomain actually present in your DNS zone, with its own TXT record (this is the case with Amazon SES in “custom MAIL FROM domain”) — then it is there, on that subdomain, that you must publish the provider’s SPF include.
• If the bounces are handled under the provider’s domain — its own domain, or a subdomain on your side as a mere CNAME to its infrastructure (the case of Mailjet with bnc3.a.com → bnc3.mailjet.com) — then the SPF actually consulted is the provider’s. Publishing its include on the apex of your domain (a.com) is useless for authentication: that record is never queried for those mailings.

This last point is counterintuitive: the interface of some ESPs (Mailjet, for example) nonetheless demands this include on your root domain and shows a warning in its absence, even though it is purely cosmetic. Mailjet support explicitly confirmed this to us (exchange of Friday 10 July 2026): this include serves only to display a green check in the interface, and its absence does not affect deliverability as long as the return-path is correctly configured. It therefore has no effect on deliverability, but it consumes one of your 10 DNS queries allowed by SPF. Keep it if you are far from that limit (to avoid an administrator being alarmed by a false alert), remove it if you are running out of room.

A note on forwarding and Mailing Lists (SRS & ARC)#

You may have noticed that some email forwarding works despite SPF’s limitations. This is thanks to two mechanisms handled by intermediate servers (over which you have no control):

1. SRS (Sender Rewriting Scheme): The relay server rewrites the envelope (Return-Path) so that SPF passes with its own IP. This fixes SPF but breaks DMARC alignment.
2. ARC (Authenticated Received Chain): The relay server signs the authentication state (SPF/DKIM) before modifying the message. This allows the final recipient (such as Gmail) to validate the email through a chain of trust, even if SPF and DKIM technically fail on arrival.

A few useful URLs#

• https://easydmarc.com/tools/dmarc-lookup : Checks the DMARC syntax and provides information about the DMARC of the checked domain.