What is DMARC?

Domain-based Message Authentication, Reporting & Conformance (DMARC) is an email authentication policy that builds on top of SPF and DKIM. It solves a problem that neither SPF nor DKIM addresses on its own: verifying that the domain in the From header — the address the recipient actually sees — matches the domain authenticated by SPF or DKIM. DMARC also lets domain owners specify what should happen to messages that fail authentication and receive aggregate reports about authentication results.

DMARC is defined in RFC 7489 and has become a requirement for reliable inbox delivery with major providers including Gmail, Yahoo, and Microsoft.

The problem DMARC solves

SPF validates the envelope sender (the MAIL FROM in the SMTP transaction), and DKIM validates the signing domain (the d= field in the DKIM-Signature header). Neither checks whether these domains match the From header — the address the human recipient sees.

This means an attacker could send a message where:

• The envelope sender is attacker.com (passes SPF for attacker.com)
• The DKIM signature is signed by attacker.com (passes DKIM for attacker.com)
• The From header says [email protected]

Without DMARC, this message passes both SPF and DKIM while spoofing your domain. DMARC closes this gap by requiring alignment — the domain checked by SPF or DKIM must match (or be a subdomain of) the domain in the From header.

How DMARC works

When a receiving mail server gets a message, the DMARC evaluation proceeds as follows:

1. Extract the domain from the From header (e.g., sendstreak.com).
2. Look up the DMARC policy by querying DNS for a TXT record at _dmarc.sendstreak.com.
3. Check SPF alignment: did SPF pass, and does the envelope sender domain match the From domain?
4. Check DKIM alignment: did DKIM pass, and does the DKIM signing domain (d=) match the From domain?
5. If either SPF or DKIM passes with alignment, DMARC passes.
6. If both fail alignment, apply the domain’s DMARC policy (none, quarantine, or reject).
7. Record the result in the Authentication-Results header.

DMARC record syntax

A DMARC record is a DNS TXT record published at _dmarc.yourdomain.com. A typical production record:

v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100; adkim=r; aspf=r

Recommended rollout path

Moving directly to p=reject on a domain that has not been monitored risks blocking legitimate email from misconfigured services. The standard approach:

Step 1: Monitor. Start with p=none and set a rua address. This collects data about who is sending email as your domain without affecting delivery. Run this for 2-4 weeks.

v=DMARC1; p=none; rua=mailto:[email protected]

Step 2: Quarantine. After reviewing reports and ensuring all legitimate senders pass SPF or DKIM with alignment, move to p=quarantine. Start with a low pct to limit impact.

v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]

Step 3: Reject. Once confident, move to p=reject at pct=100. This tells receiving servers to block any message that fails DMARC.

v=DMARC1; p=reject; rua=mailto:[email protected]

Alignment: relaxed vs. strict

Alignment determines how strictly the From domain must match the SPF or DKIM domain.

Relaxed alignment (adkim=r, aspf=r): The organizational domain must match. A message from [email protected] passes alignment if DKIM is signed by sendstreak.com, because mail.sendstreak.com is a subdomain of sendstreak.com.

Strict alignment (adkim=s, aspf=s): The domains must match exactly. The same message would fail because mail.sendstreak.com ≠ sendstreak.com.

Relaxed alignment is the default and is appropriate for most setups, especially when using subdomains for different email streams (e.g., transactional.yourdomain.com for transactional email, marketing.yourdomain.com for campaigns).

DMARC reports

Aggregate reports (rua) are XML files sent daily by receiving mail servers. They contain:

• The source IP address of every server that sent email using your domain
• The number of messages from each IP
• SPF and DKIM pass/fail results
• The DMARC policy applied

These reports are essential for identifying unauthorized use of your domain and verifying that all legitimate email services are properly authenticated. Tools like Postmark’s DMARC monitoring or free services like DMARC Analyzer can parse the XML into readable dashboards.

Common DMARC issues

Third-party services failing alignment. When using services like SendStreak, AWS SES, or Mailgun to send email, the envelope sender and DKIM signing domain must align with your From domain. Most services support this through custom domain verification — configuring your domain’s SPF and DKIM records to include the service’s sending infrastructure.

Mailing list forwarding. Mailing lists that modify the message body or headers break DKIM signatures, and forwarding changes the sending IP (breaking SPF). This is a known limitation that the ARC (Authenticated Received Chain) protocol aims to address.

Subdomain policy gaps. Without an explicit sp= tag, subdomains inherit the parent domain’s policy. If you set p=reject on yourdomain.com but a forgotten subdomain sends email without proper authentication, those messages will be rejected.

DMARC in the authentication stack

DMARC is the policy layer that gives SPF and DKIM their teeth:

1. SPF answers: “Is this IP authorized to send for this domain?”
2. DKIM answers: “Was this message signed by this domain and unmodified?”
3. DMARC answers: “Does the domain the user sees match the authenticated domain, and what should we do if it doesn’t?”

All three are visible in the email headers under Authentication-Results. For any domain sending transactional email, having all three configured and passing is the baseline requirement for reliable inbox delivery.