SPF and DKIM are foundational email authentication mechanisms, but each has a critical blind spot when deployed without DMARC. SPF validates the envelope sender domain used in the SMTP transaction, but the From header visible to recipients is a separate field that SPF does not validate. DKIM validates that the message was signed by the specified domain, but does not require that this signing domain match the From header domain that users see. An attacker can craft a message where the visible From header shows a legitimate organization's domain while using a different domain for the envelope sender (passing SPF) or signing domain (passing DKIM), a technique called header spoofing.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) closes this gap by requiring alignment: the domain in the From header must match either the domain that passed SPF (envelope sender alignment) or the domain in the DKIM-Signature's d= tag (DKIM alignment). DMARC then adds a policy layer that instructs receiving servers what to do with messages that fail this combined alignment check — monitor and report, route to spam, or reject at the SMTP level with a 550 error. This policy enforcement is what transforms email authentication from passive observation into active protection against domain impersonation.
- SPF validates envelope sender IP but not the From header that users see in their email client
- DKIM signing domain does not have to match the From header without DMARC alignment enforcement
- Header spoofing exploits these gaps by keeping the visible From header as the impersonated domain
- DMARC requires the From domain to align with the domain that passed SPF or DKIM authentication
- Only DMARC policy enforcement actually causes spoofed emails to be blocked or quarantined
A DMARC record is a DNS TXT record published at _dmarc.[domain]. For example, the DMARC record for example.com is published at _dmarc.example.com. The record begins with the required version tag v=DMARC1 followed by the policy tag p=, which accepts values of none, quarantine, or reject. The rua= tag specifies the email address where aggregate XML reports should be sent, formatted as a URI: rua=mailto:[email protected]. The ruf= tag specifies where forensic failure reports are sent.
Additional optional tags refine policy behavior. The pct= tag specifies the percentage of messages to which the DMARC policy applies, allowing gradual rollout of quarantine or reject policies — pct=10 applies the policy to 10% of failing messages while reporting on all of them. The sp= tag sets a separate policy for subdomains — useful for organizations that want to reject spoofed email for their primary domain while using none for subdomains during a phased rollout. The adkim= and aspf= tags control DKIM and SPF alignment mode, accepting values of r (relaxed, the default) or s (strict).
v=DMARC1— required version tag; must be the first tag in the recordp=none— monitoring mode: collect reports but take no action on failuresp=quarantine— route failing messages to the spam or junk folderp=reject— reject failing messages at the SMTP level with a 550 permanent failurerua=mailto:[email protected]— address for daily aggregate XML authentication reports
The three DMARC policy levels represent a spectrum from passive monitoring to active enforcement. The p=none policy instructs receiving servers to take no action on messages that fail DMARC alignment — they are delivered normally. The only effect of p=none is that reports are generated and sent to the addresses specified in the rua= and ruf= tags. This monitoring-only mode is the appropriate starting point for every DMARC deployment, as it allows organizations to identify all legitimate mail streams and ensure they are properly authenticated before any enforcement policy is applied.
The p=quarantine policy instructs receiving servers to route failing messages to the recipient's spam or junk folder rather than the inbox. The p=reject policy instructs receiving servers to refuse the message at the SMTP level, returning a 550 permanent failure code — the message is never delivered to any folder. The pct= tag allows gradual escalation: setting pct=25 with p=reject means only 25% of failing messages are rejected, with the remainder receiving quarantine treatment, allowing organizations to test rejection impact before full enforcement while monitoring aggregate reports for unexpected legitimate mail failures.
p=none: no enforcement action — generates reports only, suitable for initial deploymentp=quarantine: failing messages routed to spam folder — partial enforcementp=reject: failing messages rejected at SMTP with 550 error — full enforcementpct=10: apply policy to only 10% of failing messages during gradual rollout- Do not jump directly from
p=nonetop=reject— always use quarantine as an intermediate step
Aggregate reports, delivered to the address specified in rua=, are the most operationally valuable output of a DMARC deployment. Each major receiving mail provider — Google, Microsoft, Yahoo, Apple, and others — sends one aggregate report per day covering all messages they processed that claimed to be from your domain. These reports are XML files compressed in ZIP format and contain statistics for each source IP address that sent messages claiming your domain, including SPF result, DKIM result, DMARC alignment result, and message count. Analyzing these reports reveals your complete email sending landscape.
The raw XML reports are technically detailed but difficult to read directly. DMARC report analysis services provide dashboards that aggregate reports from all providers, visualize sending sources, flag authentication failures, and identify unauthorized senders attempting to use your domain. Free and commercial tools include Postmark DMARC Digest, dmarcian, Valimail, EasyDMARC, and MXToolbox DMARC Analytics. These tools are essential during the monitoring phase when reviewing p=none reports to identify and remediate every failing mail stream before moving to an enforcement policy that could block legitimate email.
- Aggregate reports are sent daily by each major receiving provider to the
rua=address - Reports are XML files in ZIP format containing per-IP authentication statistics for your domain
- Each report entry shows: source IP, message count, SPF result, DKIM result, DMARC disposition
- Analysis services: dmarcian, Valimail, EasyDMARC, Postmark DMARC Digest, MXToolbox
- Review aggregate reports for at least 30 days before advancing DMARC policy to quarantine
Forensic reports, specified by the ruf= tag, are individual failure reports sent when a specific message fails DMARC authentication. Unlike aggregate reports which provide summary statistics, forensic reports contain redacted copies of individual messages — headers, sending infrastructure details, and sometimes partial message body — that failed DMARC checks. These reports are valuable for debugging specific authentication failures and investigating phishing campaigns targeting your domain. They provide enough message-level detail to identify the infrastructure sending spoofed email in your domain's name.
However, forensic reports come with significant privacy considerations. Because they contain portions of actual message content, they may include sensitive information from legitimate messages that failed authentication for technical reasons (such as forwarding breaking SPF alignment). For this reason, many major providers — including Google and Microsoft — do not send forensic reports even when the ruf= address is configured, citing privacy policy constraints. Organizations should carefully consider the privacy implications of collecting forensic reports and ensure the report collection address is access-controlled and treated as potentially sensitive data.
- Forensic reports are per-message failure reports containing headers and partial content
- Specified with
ruf=mailto:[email protected]in the DMARC record - Many major providers do not send forensic reports due to user privacy policy commitments
- Forensic reports are valuable for phishing investigation and diagnosing specific authentication failures
- Access-control the
ruf=mailbox — forensic reports may contain sensitive message content
A successful DMARC deployment follows a methodical phased approach. Phase one: publish p=none with both rua= and ruf= addresses specified. Collect and analyze aggregate reports for at least 30 days. Identify all legitimate sending sources — your primary mail server, marketing platforms, CRM systems, ticketing systems, and any other services that send email on behalf of your domain — and ensure each one passes both SPF and DKIM with proper alignment. Do not advance to the next phase until all legitimate sources pass authentication.
Phase two: advance to p=quarantine at pct=10 and continue monitoring for two to four weeks. Gradually increase the pct= value — to 25, then 50, then 100 — checking aggregate reports after each increase to ensure no legitimate mail streams are failing. Phase three: advance to p=reject at pct=10, again increasing incrementally while monitoring. The most common pitfall is rushing this process and applying p=reject before all legitimate mail streams are properly authenticated, resulting in blocked legitimate email, disrupted business communications, and emergency rollbacks that damage stakeholder confidence in the deployment.
- Phase 1: publish
p=none, collect reports for at least 30 days, authenticate all legitimate sources - Phase 2: advance to
p=quarantine; pct=10, incrementally increase pct while monitoring - Phase 3: advance to
p=reject; pct=10, incrementally increase pct to 100 over several weeks - Never skip the quarantine phase — it provides a safety net while identifying residual failures
- Common pitfall: forgetting transactional email services, ticketing systems, or automated notification senders