What is DMARC? | NOC.org

Understanding DMARC

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is an email authentication protocol that builds on SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) to give domain owners control over how unauthenticated email is handled. DMARC adds two things that SPF and DKIM lack on their own: a policy mechanism that tells receiving servers what to do when authentication fails, and a reporting system that gives domain owners visibility into who is sending email using their domain.

Without DMARC, a receiving mail server may perform SPF and DKIM checks but has no clear instruction from the domain owner about what to do with messages that fail. One server might reject them, another might put them in spam, and another might deliver them normally. DMARC eliminates this ambiguity by publishing an explicit policy in DNS.

How DMARC Works

DMARC authentication follows this process:

1. Message arrives: A receiving mail server accepts an incoming message and identifies the domain in the header "From" address.
2. SPF and DKIM checks: The server performs standard SPF and DKIM checks on the message.
3. DMARC record lookup: The server queries DNS for a DMARC TXT record at _dmarc.example.com.
4. Alignment check: DMARC verifies that at least one of the authentication results (SPF or DKIM) aligns with the domain in the "From" header. Alignment means the authenticated domain matches or is a subdomain of the "From" domain.
5. Policy application: If neither SPF nor DKIM passes with alignment, the server applies the DMARC policy (none, quarantine, or reject).
6. Reporting: The server sends aggregate and/or forensic reports to the addresses specified in the DMARC record.

DMARC Record Syntax

A DMARC record is published as a DNS TXT record at the _dmarc subdomain. Here is an example:

_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensics@example.com; adkim=r; aspf=r; pct=100"

The key tags are:

• v=DMARC1: Required. Identifies this as a DMARC record.
• p=: Required. The policy for the domain. Values: none, quarantine, or reject.
• sp=: Optional. The policy for subdomains. If omitted, subdomains inherit the p= policy.
• rua=: Optional but strongly recommended. The address to receive aggregate reports.
• ruf=: Optional. The address to receive forensic (failure) reports.
• adkim=: Optional. DKIM alignment mode: r (relaxed) or s (strict). Default is relaxed.
• aspf=: Optional. SPF alignment mode: r (relaxed) or s (strict). Default is relaxed.
• pct=: Optional. The percentage of failing messages to which the policy applies. Default is 100.

Policy Modes

DMARC provides three policy levels, each representing an increasing level of enforcement:

p=none (Monitor Only)

The none policy tells receiving servers to take no action on messages that fail DMARC. It exists purely for monitoring. The domain owner receives aggregate reports showing who is sending email using their domain and whether those messages pass or fail authentication. This is the recommended starting point for DMARC deployment.

p=quarantine

The quarantine policy instructs receiving servers to treat failing messages as suspicious. In practice, this usually means delivering them to the spam or junk folder. This is a middle-ground policy that protects recipients without outright blocking messages that might be legitimate but misconfigured.

p=reject

The reject policy tells receiving servers to refuse delivery of messages that fail DMARC. This is the strongest protection and the ultimate goal of a DMARC deployment. At this level, spoofed messages using your domain will be blocked before reaching recipients' inboxes.

DMARC Alignment

Alignment is the core concept that makes DMARC effective. SPF alone checks the envelope sender (Return-Path), and DKIM checks the signing domain (d= tag). Neither inherently validates the header "From" address that users see. DMARC bridges this gap by requiring that at least one of these results aligns with the "From" domain.

For DMARC to pass, one of these must be true:

• SPF passes AND the SPF-authenticated domain aligns with the "From" domain.
• DKIM passes AND the DKIM signing domain aligns with the "From" domain.

Only one needs to pass with alignment. This is important because some legitimate email scenarios break one mechanism (for example, mailing lists often break DKIM but may preserve SPF, or forwarding may break SPF but preserve DKIM).

DMARC Reporting

Aggregate Reports (rua)

Aggregate reports are XML files sent daily (typically) by receiving mail servers to the address specified in the rua tag. They contain statistics about all messages received from your domain, including:

• The sending IP addresses
• The number of messages from each IP
• SPF and DKIM authentication results
• DMARC alignment results
• The policy applied to each message

These reports are essential for understanding your email ecosystem. Before moving to an enforcement policy, review aggregate reports to identify all legitimate sending services and ensure they are properly authenticated. DMARC reporting services can parse these XML files and present the data in human-readable dashboards.

Forensic Reports (ruf)

Forensic reports (also called failure reports) are sent for individual messages that fail DMARC. They contain more detailed information about the specific failure, including message headers. Forensic reports are useful for investigating spoofing attempts or identifying misconfigured legitimate senders. Not all receiving servers send forensic reports, and those that do often redact sensitive information for privacy reasons.

Deployment Best Practices

Deploying DMARC successfully requires a methodical approach to avoid disrupting legitimate email:

1. Inventory all email senders: Identify every service, server, and third-party platform that sends email using your domain. This includes your primary mail server, marketing platforms, transactional email services, CRM systems, ticketing tools, and any other SaaS products.
2. Deploy SPF and DKIM: Ensure SPF and DKIM are properly configured for all authorized senders. Every legitimate sender must pass at least one of these checks with alignment.
3. Start with p=none: Publish a DMARC record with p=none and a rua address. Monitor aggregate reports for several weeks to identify any legitimate senders that are failing authentication.
4. Fix authentication gaps: Work with each failing sender to configure proper SPF includes or DKIM signing with your domain. Third-party platforms usually provide documentation for setting up custom authentication.
5. Move to p=quarantine: Once reports show that all legitimate email passes DMARC, upgrade to p=quarantine. Consider starting with pct=10 and gradually increasing to pct=100.
6. Move to p=reject: After confirming that quarantine is not causing issues, move to p=reject for full enforcement. Again, use pct= for a gradual rollout if needed.
7. Ongoing monitoring: Continue monitoring aggregate reports even after reaching p=reject. New services may be added, configurations may change, and new spoofing patterns may emerge.

DMARC and DNS

Like SPF and DKIM, DMARC relies on DNS for record publication and discovery. DMARC records are always placed at the _dmarc subdomain of the domain being protected. If you want to receive aggregate reports for domains you do not own (for example, a centralized reporting address), you need to add a special DNS record at example.com._report._dmarc.reporting-domain.com to authorize cross-domain reporting.

Summary

DMARC is the capstone of email authentication, tying SPF and DKIM together with alignment requirements, enforcement policies, and reporting. A well-deployed DMARC policy at p=reject is the most effective way to prevent attackers from spoofing your domain in phishing campaigns. The key to success is a gradual deployment: start with monitoring, fix gaps, and incrementally increase enforcement while continuously reviewing reports.

Need help securing your infrastructure? Explore NOC.org plans to get started.