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

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email authentication protocol (RFC 7489) that combines SPF and DKIM into an enforceable protection mechanism. For the first time, DMARC gives domain owners control over what happens to emails sent on behalf of their domain that fail authentication checks—while also providing detailed reports on all authentication attempts worldwide.

How DMARC Works

DMARC adds a crucial layer that SPF and DKIM alone do not provide: a policy mechanism. Without DMARC, an SPF or DKIM failure has no automatic consequence; the recipient’s mail server decides on its own. With DMARC, the domain owner provides explicit instructions.

DMARC verification process:

1. Email arrives at the receiving server
   From: absender@beispiel.de

2. Server checks SPF:
   Is the sending server authorized for the Envelope-From?
   → SPF result: pass or fail

3. Server checks DKIM:
   Is a valid DKIM signature present?
   → DKIM result: pass or fail

4. DMARC alignment check:
   Does the domain from SPF (Return-Path) match the From: field?
   Does the domain from DKIM (d=) match the From: field?
   → At least ONE check must pass AND be aligned

5. DNS lookup for DMARC record:
   _dmarc.example.com  IN  TXT  "v=DMARC1; p=reject; ..."

6. Apply policy:
   DMARC pass → Deliver email
   DMARC fail → Policy from record: none / quarantine / reject

7. Generate report:
   Receiving server sends aggregated report to rua=-address

DMARC Alignment in Detail

Alignment is the core of DMARC. It prevents attackers from passing a technically correct SPF/DKIM check while using a forged From: header.

Alignment Check (relaxed, standard):

SPF Alignment:
  From: absender@beispiel.de
  Return-Path (Envelope-From): bounce@mail.beispiel.de
  → Org-domain of both: example.de → SPF alignment PASS

DKIM alignment:
  From: absender@beispiel.de
  DKIM-Signature d=mail.example.de
  → Org-domain of both: example.de → DKIM alignment PASS

DMARC result:
  At least one check (SPF or DKIM) must be aligned
  → Both fail → DMARC fail → Apply policy

Strict alignment (aspf=s or adkim=s in the DMARC record):
  From: absender@beispiel.de
  Return-Path: bounce@mail.beispiel.de → FAIL (Subdomain ≠ Domain)
  DKIM d=mail.example.com              → FAIL (Subdomain ≠ Domain)
  Only if exact match: PASS

DMARC Policies

p=none (Observation mode):
  → Email is delivered normally, regardless of the result
  → No rejection, no quarantine
  → Purpose: Getting started, monitoring, collecting reports
  → Recommendation: Initial phase, until reports have been evaluated

p=quarantine (Quarantine):
  → DMARC-fail → Email ends up in the Spam/Junk folder
  → Email is delivered but marked as suspicious
  → Purpose: Transition phase after p=none has been analyzed

p=reject (Rejection):
  → DMARC fail → Email is rejected by the receiving server
  → Sender receives a bounce (5xx SMTP error)
  → Strongest possible protection: completely prevents domain spoofing
  → Recommendation: Goal for every domain after implementation is complete

pct= (Percentage):
  → Policy applies only to X% of all DMARC-fail emails
  → Enables a phased rollout: pct=10, then pct=50, then pct=100
  → Default: pct=100 (applies to all)
  → Example: p=reject; pct=10 (initially only 10% rejected)

DMARC Record Structure

Minimal DMARC record:
_dmarc.example.de  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de"

Complete DMARC record with all parameters:
_dmarc.example.de  IN  TXT  "v=DMARC1; p=reject; pct=100; \
  rua=mailto:dmarc-agg@beispiel.de; \
  ruf=mailto:dmarc-forensic@beispiel.de; \
  aspf=r; adkim=r; fo=1; rf=afrf; ri=86400"

Parameter Reference:

v=DMARC1   Protocol version (required, always "DMARC1")
p=         Policy for the domain (none/quarantine/reject)
sp=        Policy for subdomains (if different from p=)
           Default: sp= inherits value from p=
pct=       Percentage (1-100), default: 100

Reporting:
rua=       Aggregated Reports (XML reports, daily)
           Format: mailto:adresse@domain.de
           Multiple: rua=mailto:a@domain.de,mailto:b@domain.de
ruf=       Forensic Reports (Individual email reports on failure)
           Note data protection: contain email content!
fo=        Failure Reporting Options:
           fo=0  Report only if SPF AND DKIM fail (default)
           fo=1  Report if SPF OR DKIM fail
           fo=d  Report if DKIM fail
           fo=s  Report if SPF fail
rf=afrf    Report Format: afrf (Authentication Failure Reporting Format)
ri=86400   Report interval in seconds (default: 86400 = 24h)

Alignment:
aspf=r     SPF alignment: r=relaxed (default), s=strict
adkim=r    DKIM alignment: r=relaxed (default), s=strict

Understanding DMARC Reports

DMARC generates two types of reports that provide valuable insights into your domain’s email delivery.

Aggregated Reports (rua=):
  Format: XML, sent daily by every major email provider
  Content:
    - Sender IP address
    - Number of emails from this IP
    - SPF result + alignment
    - DKIM result + alignment
    - Applied DMARC policy
    - Used header From domain

  Typical sources:
    → Google (gmail.com) sends reports for all emails received via Gmail
    → Microsoft (outlook.com, hotmail.com)
    → Yahoo, Apple iCloud, other major providers

  Benefits:
    → Detect unauthorized senders (phishing on your own domain!)
    → Find misconfigured services on your own network
    → Verify completeness of DKIM/SPF configuration

Forensic Reports (ruf=):
  Format: AFRF (Application/delivery-status), contains email headers
  Content: A stripped-down copy of the failed email
  Privacy: May contain personal data!
  Many providers do not send ruf= (privacy concerns)
  Recommendation: Enable only for targeted troubleshooting

Implementation Steps

A DMARC implementation should be carried out in stages to avoid disrupting legitimate email delivery.

Phase 1 - Inventory (Weeks 1-2):
  Identify all email sources:
  → Primary mail servers (Exchange, Postfix, o365)
  → CRM systems (Salesforce, HubSpot)
  → Email marketing (Mailchimp, Brevo, CleverReach)
  → Ticket systems (Zendesk, Freshdesk)
  → Monitoring systems, web server contact forms
  → Billing software

Phase 2 - Set up SPF:
  → Create SPF records (for all sources from Phase 1)
  → Check lookup count (max. 10)
  → Start with -all or ~all
  → Test: mxtoolbox.com/spf

Phase 3 - Enable DKIM:
  → Set up DKIM signing on all sending systems
  → Publish DNS TXT records
  → For third-party providers: Configure custom domain signing
  → Test: mail-tester.com, mxtoolbox.com/dkim

Phase 4 - DMARC in monitoring mode:
  → Publish DMARC record with p=none + rua=
    _dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de"
  → Collect and evaluate reports for 2–4 weeks
  → Use DMARC analysis tools (dmarcian, Mimecast DMARC Analyzer, Google Postmaster)

Phase 5 - Gradual tightening:
  → Have all unauthenticated sources been cleaned up?
    p=quarantine; pct=25  (25% in quarantine)
    p=quarantine; pct=100
    p=reject; pct=25
    p=reject; pct=100

Phase 6 - Enforcement (Goal):
  → p=reject; pct=100
  → Domain is fully protected against spoofing
  → Check subdomains: set p=reject for subdomains that do not send email

Common Errors in DMARC Implementation

Error 1: Switching to p=reject too quickly
  Problem: Not all email sources were recorded in SPF/DKIM
  Consequence: Legitimate emails (e.g., from CRM) are rejected
  Solution: Do not skip the p=none phase; evaluate reports

Error 2: rua= points to a non-existent address
  Problem: Reports arrive, but no one reads them
  Consequence: Configuration issues go undetected
  Solution: Use a dedicated mailbox or a DMARC analysis tool

Error 3: SPF lookup limit exceeded
  Problem: SPF returns a permerror
  Consequence: DMARC-SPF alignment always fails, even though the sender is authorized
  Solution: Flatten SPF records or reduce lookup count

Error 4: Third-party provider without alignment
  Problem: Newsletter provider signs with its own domain (d=newsletter.com)
  Consequence: DKIM alignment fails for DMARC, even with DKIM-pass
  Solution: Set up custom domain signing with the provider (usually a CNAME record)

Error 5: Subdomains forgotten
  Problem: `p=reject` applies to `hauptdomain.de`, but not to `*.hauptdomain.de`
  Consequence: Attackers can send spoofed emails to `mail@subdomain.hauptdomain.de`
  Solution: sp=reject in the DMARC record, or separate DMARC records for subdomains

DMARC and BIMI

DMARC with p=reject is a prerequisite for BIMI (Brand Indicators for Message Identification)—a newer standard that allows a company’s logo to be displayed directly in the recipient’s inbox.

BIMI requirements:
  1. DMARC with p=quarantine or p=reject (pct=100)
  2. BIMI record in DNS:
     default._bimi.example.com  IN  TXT  "v=BIMI1; l=https://beispiel.de/logo.svg"
  3. Logo: SVG format (Tiny PS profile), square, HTTPS
  4. Optional: VMC (Verified Mark Certificate) from DigiCert or Entrust
     → Logo is only displayed in Gmail and Apple Mail with a VMC
     → Cost: ~1,000–1,500 EUR/year

BIMI benefits:
  → Increases trust among recipients
  → Higher open rates (studies: +10% for verified logos)
  → Brand protection: makes it harder for imitators

Provider support (as of 2025):
  Gmail, Apple Mail, Yahoo Mail: BIMI with VMC is displayed
  Outlook/Hotmail: BIMI not yet supported

DMARC is no longer an optional "nice-to-have" but a minimum requirement for professional email infrastructure. Since February 2024, Google and Yahoo have made a DMARC policy mandatory for all senders with more than 5,000 emails per day—without a DMARC record, bulk emails to Gmail and Yahoo are rejected or reliably end up in spam. Companies that have not yet protected their domain with DMARC risk both the deliverability of legitimate emails and the misuse of their domain for phishing campaigns targeting their own customers and partners.