Email fraud costs organizations billions annually. The majority of phishing and business email compromise campaigns succeed because they exploit a fundamental weakness in SMTP: anyone can send an email that claims to be from any domain. The From header in an email is not authenticated by default. [1]
Domain-based Message Authentication, Reporting, and Conformance (DMARC) was designed to fix this. It is defined in RFC 7489 [2] and built on two existing mechanisms, Sender Policy Framework (SPF) [3] and DomainKeys Identified Mail (DKIM) [4] adding a policy layer and feedback loop that neither SPF nor DKIM provide alone. [5]
1. Why DMARC Exists: The Problem It Solves
Email was designed in an era when trust was assumed, not verified. The SMTP specification (RFC 5321) [1] allows any server to claim any sender address in the MAIL FROM command, and the From header (RFC 5322) [6] is similarly unverified.
SPF and DKIM addressed part of this problem. SPF [3] allows domain owners to publish which IP addresses are authorized to send from their domain. DKIM [4] attaches a cryptographic signature to messages that receivers can verify against the sender's public key published in DNS. [7]
But neither mechanism alone gives domain owners control over what happens to unauthenticated mail, and neither provides meaningful feedback about what is being sent in the domain's name. DMARC solves both: [5]
1. Policy assertion: A domain owner can publish a DMARC record in DNS telling receivers what to do with mail that fails authentication. [2]
2. Feedback loop: Receivers send aggregate reports back to the domain owner. [2]
The design philosophy: "The only way these problems can be addressed is when senders and receivers share information with each other." [5, Section 2]
2. Email Authentication Foundations: SPF and DKIM
DMARC depends entirely on SPF and DKIM. Understanding DMARC requires understanding these two mechanisms. [2]
2.1 Sender Policy Framework (SPF)
SPF is defined in RFC 7208 [3]. It allows a domain owner to publish a DNS TXT record listing the IP addresses authorized to send mail on behalf of that domain.
When a receiving mail server receives a message, it performs an SPF check by looking up the MAIL FROM domain and checking if the connecting server's IP is listed. The result is one of: pass, fail, softfail, neutral, or none. [3]
A basic SPF record for a domain that sends exclusively through Google Workspace:
v=spf1 include:_spf.google.com ~all
SPF has a well-known weakness: it only authenticates the MAIL FROM domain, not the From header domain that users see. [8] Attackers routinely send from legitimate servers they control while using a forged From address. SPF alone cannot prevent this because the MAIL FROM and From header are independent fields.
There is also a DNS lookup limit: the SPF specification imposes a 10-lookup ceiling. [9] Exceeding this causes a temperror. Large organizations with complex sending infrastructure frequently hit this limit.
2.2 DomainKeys Identified Mail (DKIM)
DKIM is defined in RFC 6376 [4]. It uses asymmetric cryptography: a sending domain publishes a private key secretly and publishes the corresponding public key in DNS. Outbound mail servers sign messages using the private key; receiving servers verify the signature using the public key.
DKIM signatures cover specific headers and the message body. A message can have multiple DKIM signatures (multiline DKIM), though this is uncommon and causes interoperability issues. [4]
DKIM authenticates the signing domain, the d= tag in the DKIM-Signature header, which may differ from the From header domain. [4] An attacker can obtain a DKIM signature from a subdomain they control and use it to sign messages with a From header from a target domain. The DKIM signature validates correctly, but the From domain is not actually authorized.
DKIM signatures are also fragile: forwarding chains, mailing list servers, and content filters frequently modify message body or headers in ways that break signatures. [10]
2.3 What Neither SPF Nor DKIM Provides
Both mechanisms authenticate an identifier but neither: [2][5]
• Authenticates the From header domain that users see [2]
• Provides the domain owner a mechanism to instruct receivers how to handle failures [2]
• Sends feedback about what is being sent in the domain's name [2]
DMARC closes all three gaps by introducing identifier alignment and policy assertion. [2]
3. Identifier Alignment
The central concept in DMARC is identifier alignment. [2] DMARC checks whether the domain in the RFC5321 MAIL FROM (used by SPF) or the signing domain in the DKIM signature aligns with the domain in the RFC5322 From header, the address the recipient's email client displays.
There are two alignment modes, controlled by the adkim and aspf tags: [2]
DKIM alignment (adkim):
• adkim=s (strict): The DKIM signing domain (d=) must exactly match the From header domain
• adkim=r (relaxed): The DKIM signing domain must match the From header domain or a parent domain
SPF alignment (aspf):
• aspf=s (strict): The MAIL FROM domain must exactly match the From header domain
• aspf=r (relaxed): The MAIL FROM domain must match the From header domain or a parent domain
Relaxed alignment is the default for both (aspf=r; adkim=r). Strict alignment is rarely used in production because it breaks legitimate multi-vendor sending scenarios. [2]
Organizational Domain
To determine alignment, DMARC identifies the Organizational Domain, the registered domain name, as opposed to a subdomain. For mail.example.co.uk, the organizational domain is example.co.uk, not co.uk. This matters for multi-level domains like .co.uk and .com.au. [2]
4. The DMARC Record: Syntax and Tags
A DMARC policy is published as a DNS TXT record at _dmarc.example.com. The record uses tag-value syntax, defined in RFC 7489 Section 6.4. [2]
A minimal DMARC record:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;
Tag reference: [2][11]
Tag Purpose Default
`v` Protocol version - must be `DMARC1` (required)
`p` Policy for the domain: `none`, `quarantine`, or `reject` (required)
`rua` URI for aggregate reports (mailto or HTTPS) (optional)
`ruf` URI for forensic (failure) reports (optional)
`pct` Percentage of messages subjected to DMARC filtering (0–100) `100`
`sp` Policy for subdomains of the domain inherit from `p`
`adkim` DKIM alignment mode: `r` (relaxed) or `s` (strict) `r`
`aspf` SPF alignment mode: `r` (relaxed) or `s` (strict) `r`
`fo` Forensic report options: `0`, `1`, `d`, `s` `0`
Policy tags: p=none = monitor only. p=quarantine = route to spam. p=reject = reject at SMTP level (full enforcement). sp applies a separate policy to subdomains. [2]
Reporting tags: rua receives ZIP-compressed XML aggregate reports (the primary operational data source). ruf receives per-message forensic reports (high volume; most large senders disable it). [2][12][13]
Percentage tag: pct controls what fraction of non-aligned messages are subjected to the policy. pct=100 is the default (all messages processed). [2]
5. DMARC Reporting: Aggregate and Forensic Reports
5.1 Aggregate Reports (RUA)
Aggregate reports arrive as ZIP-compressed XML attachments, sent to the address in the rua tag. [2][12] They follow the schema in RFC 7489 Appendix C and provide a bird's-eye view of all mail claiming to be from your domain.
Key data in aggregate reports:
• Source IP — the sending mail server's IP address [12]
• Message count — how many messages from this IP claimed to be from your domain [12]
• SPF/DKIM/DMARC result — pass/fail/neutral for each check [12]
• Disposition — none/quarantine/reject [12]
The primary operational use of aggregate reports is identifying unauthorized senders, third-party ESPs, subsidiary systems, legacy SMTP relays, before they cause failures when you move to p=reject. DMARCFlow automates the ingestion and provides a structured dashboard for aggregate report analysis. [19]
5.2 Forensic Reports (RUF)
Forensic failure reports are sent per-message when a message fails DMARC alignment. [2] They include the full headers and the receiving server's interpretation of the DMARC policy.
Because they fire per message, ruf generates high volume. At 100,000 daily outbound messages with a 1% failure rate, ruf generates 1,000 forensic reports per day. [13] Most large senders disable forensic reporting in favor of aggregate reporting.
5.3 Interpreting the Threat Signal
Aggregate report data reveals two distinct threat categories:
External domain spoofing: Messages from source IPs you do not recognize indicate someone is sending mail claiming to be from your domain. [12] A spike in unrecognized source IPs often signals an active phishing campaign using your brand.
Internal authentication failures: Messages from your own verified source IPs that still fail DMARC indicate misconfiguration, usually a vendor or internal system that sends from your domain without proper DKIM signing or with a mismatched MAIL FROM domain. [12]
6. The Complete Implementation Lifecycle
DMARC deployment is not a configuration change - it is a process that typically spans months. [14]
Phase 1: Discovery (p=none)
Publish a p=none DMARC record with an rua tag pointing to a monitored address. Collect 2–4 weeks of aggregate reports. Using a tool that ingests and parses these reports makes this phase far less labor-intensive than reading raw XML manually. [14][19]
Map every legitimate sending source:
• Your outbound mail gateway or ESP
• Each third-party ESP (Salesforce, Mailchimp, SendGrid, etc.)
• Internal systems that send as your domain (HR systems, ticketing platforms, automated alerts)
• Subsidiaries or sister companies that send on your behalf
Phase 2: Validation (p=none, active remediation)
With aggregate reports in hand, begin fixing legitimate senders that fail DMARC alignment. [14] Configure third-party ESPs to authenticate with your domain (DKIM signing with your domain key). Ensure internal systems use the correct MAIL FROM domain. Align DKIM signing domains with your From header domain. Monitor aggregate reports weekly. The goal is zero failures from legitimate sources before moving to enforcement.
Phase 3: Quarantine (p=quarantine)
After all legitimate sources are authenticated, set p=quarantine. [14] Monitor for 2–4 weeks. Watch for spikes in quarantine disposition counts from legitimate sources - this indicates a sender that was missed in discovery.
Phase 4: Reject (p=reject)
After successful quarantine monitoring, move to p=reject. [14] Receivers will reject any message claiming to be from your domain that doesn't pass either SPF or DKIM alignment. At p=reject, your domain is protected against domain spoofing in email. [5]
7. What DMARC Does Not Protect Against
DMARC is frequently mischaracterized as an anti-phishing solution. It is a domain spoofing prevention mechanism. [5][15]
DMARC does not protect against: [15]
• Display name spoofing: An attacker sends from attacker@gmail.com but sets the display name to "CEO Jane Smith." DMARC never inspects display names. This is one of the most common BEC attack vectors. [15]
• Lookalike domains: An attacker registers legitcompany.co (wrong TLD) or micros0ft.com (zero for o). Your DMARC policy covers only domains you own. [15]
• Compromised legitimate accounts: If an attacker takes over a vendor's SendGrid account, SPF passes, DKIM passes, DMARC passes, the fraud is in the message body. [15]
• Reply-to manipulation: A message arrives from a legitimate From address but with a Reply-To directing responses to an address the attacker controls. DMARC never inspects the Reply-To header. [15]
• Channel-switch attacks: Email is used as a credible signal followed by a phone call (often with AI-generated voice) directing a wire transfer. DMARC operates only at the email layer. [15]
For these attack vectors, DMARC is necessary but not sufficient. [15] DMARCFlow covers both sides of this gap: aggregate report parsing and alerting for authentication failures. [19]
7.1 DMARCFlow Free Tools
DMARCFlow provides a free DMARC Inspector tool that parses any DMARC record by domain and displays its configured policy, tags, and reporting addresses in a human-readable format, useful for quick diagnostics without creating an account. As well as a SPF Inspector & DKIM Inspector. [19]
8. DMARC and the Authenticated Received Chain (ARC)
One of DMARC's design constraints is that it was built for direct sender-to-receiver delivery. [16] The moment a message passes through intermediate handlers, forwarding services, mailing lists, security scanners, email gateways, authentication results from the original sending infrastructure can be lost or modified. This causes legitimate mail to fail DMARC at the final receiver.
The Authenticated Received Chain (ARC) protocol (RFC 8617) [16] was designed to address this. ARC creates a cryptographic chain of custody for authentication results across intermediate handlers. Each handler in the chain adds an ARC-Seal documenting its authentication assessment at that hop. The final receiver validates the full ARC chain and can use the preserved original authentication results, rather than the potentially degraded results at final delivery, to inform its DMARC evaluation.
ARC is now required by several large mailbox providers when handling mail from domains with strict DMARC policies. [16] It is also the reason mailing list forwarders that previously broke email authentication now have a standardized path to preserve it.
9. Common Implementation Failures
Failure 1: Moving to p=reject before completing sender discovery. The result is legitimate transactional email, password resets, order confirmations, invoice notifications, being rejected at the SMTP level. The fix is a full return to p=none, a complete sender audit, and methodical remediation. [14]
Failure 2: Subdomain policy gaps. Applying DMARC only to the apex domain while subdomains send unauthenticated mail causes subdomains to inherit the apex policy and have mail rejected. Explicitly set sp=none or sp=quarantine for subdomains. [2]
Failure 3: The 10-lookup SPF limit. Organizations with complex sending infrastructure frequently exceed SPF's 10-lookup DNS ceiling. When this happens, the SPF check returns temperror. Fixes: use include: mechanisms efficiently, consolidate sending infrastructure, or migrate to DKIM. [9]
Failure 4: Misaligned DKIM signing domain. Many ESPs sign with their own domain by default (d=esp.com), causing messages to fail DMARC alignment. Configure custom DKIM signing with your From header domain. [2]
Failure 5: Report address filtering. Many corporate email filters strip ZIP attachments from aggregate reports. Use a dedicated report inbox with filters configured to allow ZIP attachments from receiving mail providers. [12]
10. DMARC, Gmail, and Yahoo: The 2024 Mandates
In early 2024, Gmail and Yahoo announced DMARC requirements for senders sending more than 5,000 messages daily. [17] These requirements, which took effect in February 2024, mandate:
• p=reject for domains sending bulk email to Gmail or Yahoo addresses [17]
• Valid SPF and DKIM alignment for the From header domain [17]
• A valid postmaster@domain address for Yahoo [17]
• One-click unsubscribe headers per RFC 8058 [18]
These mandates made DMARC enforcement a deliverability requirement for any organization emailing Gmail or Yahoo users at scale, not merely a security best practice. [17]
References
[1] RFC 5321 — Simple Mail Transfer Protocol. IETF.
[3] RFC 7208 — Sender Policy Framework (SPF). Standards Track, IETF, April 2014.
[4] RFC 6376 — DomainKeys Identified Mail (DKIM). Standards Track, IETF, September 2012.
[5] DMARC Overview. dmarc.org.
[6] RFC 5322 — Internet Message Format. IETF.
[7] Kucherawy, M. and Zwicky, E., "Email Authentication in 2015: A Survey of Technical Background and Market Research," Journal of Cybersecurity, vol. 1, no. 2, 2015.
[8] Kucherawy, M., "A Direction for Email Authentication Research," IETF 89 Proceedings, 2014.
[9] RFC 7208, Section 4.6.4 — SPF DNS Query Limits.
[10] RFC 6376, Section 3.7 — Signature Durability.
[11] IANA DMARC Tag Registry. Internet Assigned Numbers Authority.
[12] RFC 7489, Appendix C — DMARC XML Schema and Aggregate Report Format.
[13] "DMARC Forensic Reports: When to Use Them (And When to Disable Them)," 2023.
[14] DMARC Deployment Best Practices. dmarc.org.
[15] Business Email Compromise: DMARC and Email Authentication Technical Information.
[16] RFC 8617 — The Authenticated Received Chain (ARC) Protocol. Experimental, IETF, July 2019.
[17] Google Security Blog
[18] RFC 8058 — List-Hardening: One-Click Unsubscribe. IETF, 2017.
FAQ
What is the difference between SPF and DKIM alignment?
SPF alignment checks whether the MAIL FROM domain matches the From header domain. DKIM alignment checks whether the signing domain in the DKIM-Signature header matches the From header domain. Both are evaluated independently under DMARC - a message can pass SPF alignment but fail DKIM alignment, or vice versa. [2]
My aggregate report shows SPF fail for an IP I don't recognize. What does this mean?
It means mail claiming to be from your domain arrived from a source IP not on your SPF authorized list. This is either a spoofing attempt or a legitimate sender (a subsidiary or vendor) that hasn't been added to your SPF record. Cross-reference the source IP against your known sending infrastructure before assuming it's an attack. [12]
Can a subdomain have a different DMARC policy than the apex domain?
Yes. The sp tag sets a separate policy for subdomains. Setting p=reject; sp=quarantine means the apex domain is fully enforced while subdomains are only quarantined. This is useful when subdomains send unauthenticated mail (legacy systems, test environments) while the apex domain is fully controlled. [2]
What causes DMARC to pass for a message sent by an attacker?
DMARC passes when either SPF or DKIM is aligned with the From domain and the result is pass. [2] An attacker who compromises a legitimate vendor's SendGrid account passes SPF, DKIM, and DMARC alignment. [15] This is not a DMARC failure - DMARC only authenticates the domain, not the intent or content of the message. [15]
Does DMARC work with forwarded mail?
Sometimes. Forwarding through traditional SMTP forwarders typically breaks SPF alignment and can break DKIM signatures. [10]
ARC (RFC 8617) [16] was designed to preserve authentication results through forwarding chains. Basic forwarding often results in DMARC failure for the forwarded message.
How long does DMARC implementation take?
For a small organization with a single outbound email system: 4–6 weeks from p=none to p=reject. For a large organization with multiple ESPs, acquired subsidiaries, complex internal systems, and legacy SMTP infrastructure: 6–18 months. [14] The bottleneck is always sender discovery.