Any domain can be forged in the From field of an email. Nothing in the original SMTP specification requires a sending server to prove it is authorized to use the domain it displays to the recipient, which is why exact-domain spoofing has remained a durable attack technique for decades. DMARC is the protocol-level mechanism that closes that gap, giving domain owners a way to state how receiving servers should treat mail that fails authentication.
What is DMARC in Email Security?
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It is an email security protocol that lets a domain owner publish a policy in DNS describing how receiving mail servers should handle messages that claim to come from that domain but fail authentication checks. The same record tells receivers where to send reports on what they observed.
The distinction that matters most in DMARC email security is that DMARC does not authenticate anything on its own. It has no cryptography and no IP verification of its own. It consumes the results of SPF and DKIM, applies an alignment test against the domain the recipient actually sees, and then applies the policy the domain owner published. It is a policy and reporting layer built on top of two existing authentication mechanisms.
That layering is what makes DMARC useful operationally. Before DMARC, a domain owner could configure SPF and DKIM and still have no visibility into how their domain was being used across the internet, and no way to tell receivers what to do when checks failed. DMARC supplies both the instruction and the feedback loop.
How DMARC Works with SPF and DKIM
SPF and DKIM answer different questions. SPF checks whether the sending server’s IP address is authorized to send on behalf of the envelope domain, the one used in the SMTP MAIL FROM command. DKIM checks whether the message carries a valid cryptographic signature that ties it to a signing domain, verified against a public key published in that domain’s DNS.
Neither of those checks is anchored to what the recipient sees in their mail client. A message can pass SPF for one domain, carry a valid DKIM signature for a second, and still display a completely unrelated third domain in the From header. DMARC introduces the alignment requirement that resolves this. Alignment can be strict, requiring an exact match, or relaxed, allowing organizational domain matching.
DMARC passes if either aligned SPF or aligned DKIM passes. Both are not required. In practice, configuring both is still the correct approach because the two mechanisms fail in different circumstances. SPF breaks on forwarding, since the forwarding server presents a new IP address that is not in the original domain’s SPF record. DKIM survives forwarding as long as the message content and signed headers are not modified in transit, which makes it the more durable of the two across mailing lists, forwarding rules, and intermediary gateways. Having both configured means a legitimate message has two independent paths to an aligned pass.
The correct way to describe what this achieves is that DMARC reduces spoofing risk and supports enforcement through published policy. Receivers make the delivery decision. DMARC tells them what the domain owner wants that decision to be.
The Three DMARC Policy Levels
A DMARC record specifies one of three policies, and the choice determines what a receiving server does with mail that fails the alignment check.
1. p=none
The first is p=none, which applies no enforcement at all. Messages that fail DMARC are delivered exactly as they would have been without a DMARC record. What p=none does provide is data: receiving servers still generate aggregate reports, which gives the domain owner visibility into every source sending mail that claims to come from the domain. This is monitoring mode, and it exists so that organizations can discover their legitimate sending infrastructure before enforcing anything.
2. p=quarantine
The second is p=quarantine, which instructs receiving servers to treat failing mail as suspicious and route it to the spam or junk folder rather than the inbox. The message still reaches the recipient’s mailbox, but it lands somewhere that signals distrust. Quarantine is the intermediate step, useful when an organization has identified most of its sending sources but wants a recoverable failure mode while it finishes.
3. p=reject
The third is p=reject, which instructs the receiving server to refuse delivery of failing messages outright at the SMTP level. This is where the question of how does dmarc enhance email security has its clearest answer: at p=reject, mail that forges the exact domain in the From header does not get delivered anywhere, including the spam folder. It is worth being clear that p=reject is not a finish line. It is the enforcement baseline, and maintaining it requires continuous monitoring. Sending infrastructure changes constantly as marketing platforms, ticketing systems, HR tools, and vendors are added or replaced, and any new source that is not authenticated and aligned will have its mail rejected. Enforcement without monitoring turns into deliverability failures for legitimate mail.
One point on record syntax: the pct= tag, which historically allowed partial policy application, was removed in RFC 9989 and should no longer be treated as a current mechanism.
What DMARC Protects Against and What It Does Not
DMARC reduces spoofing risk for one specific thing: the exact domain in the From header. That is a meaningful category of attack, and it is the category DMARC was designed for. It is also the entire scope.
DMARC does not address lookalike or cousin domains. If an attacker registers company-secure.com and sends mail from it with fully valid SPF, DKIM, and DMARC on that domain, every authentication check passes because the attacker owns the domain they are authenticating. DMARC has no opinion about whether a domain resembles another one.
DMARC does not address compromised legitimate accounts. Mail sent from a real mailbox on the real domain, through the organization’s own authorized infrastructure, authenticates correctly because it genuinely is what it claims to be. Account takeover is an identity and access problem, not an authentication protocol problem.
DMARC does not address display name spoofing. When a message shows “Finance Department” as the sender name but the underlying address belongs to an unrelated domain, DMARC evaluates that unrelated domain and has nothing to say about the name string, which is what most recipients actually read on mobile clients.
It is also worth being precise about direction. DMARC is strictly a domain-owner outbound control. Publishing a DMARC record does not filter anything arriving in your own inboxes. It tells other organizations’ receiving servers how to handle messages claiming to be from your domain. Inbound protection is a separate set of controls.
DMARC Reporting: Aggregate and Failure Reports
DMARC reporting comes in two types, and they serve different purposes.
Aggregate reports, requested through the rua= tag, are generated by receiving mail servers and contain volume and pass/fail data across all mail claiming to come from the domain. They are XML documents summarizing sending IPs, message counts, authentication results, and the policy the receiver applied. Aggregate reports are the primary monitoring tool because they show the full picture of who is sending as the domain, including sources the organization did not know about. They are delivered on a per-reporting-cycle basis rather than in real time, so they are a visibility instrument, not an alerting one.
Failure reports, requested through the ruf= tag, are per-message reports sent when an individual message fails DMARC evaluation. They contain more detail about the specific failing message, which makes them useful for diagnosis, but availability varies considerably by receiver, and many large providers do not send them at all. Because failure reports involve message metadata, organizations should evaluate ruf= usage alongside their privacy and compliance requirements rather than enabling it by default.
Under RFC 9989, reporting is no longer specified in the core DMARC document. Aggregate reporting and failure reporting are now defined in separate RFCs, RFC 9990 and RFC 9991, respectively. If you want to confirm what your current record publishes, including which reporting addresses are configured, a DMARC checker will return the parsed record as receivers see it.
DMARC and Email Compliance in 2026
DMARC is no longer optional for domains sending 5,000 messages/day. Google and Yahoo introduced requirements for bulk senders in February 2024 that included SPF, DKIM, and a published DMARC record. Microsoft enforced equivalent requirements for Outlook, Hotmail, and Live accounts from May 5, 2025. In both cases, non-compliant mail is rejected at the SMTP level rather than filtered into spam, which means senders do not get the soft landing of poor inbox placement. The mail simply does not arrive.
Regulatory frameworks have followed. PCI DSS v4.0 requirement 5.4.1, requires automated mechanisms to detect and protect personnel against phishing, and names DMARC, SPF and DKIM as the anti-spoofing controls in its guidance. The requirement is technology-neutral on paper, but in practice assessors expect DMARC at enforcement, which puts it inside audit scope rather than in the category of optional hardening.
Adoption has moved, but enforcement has not kept pace. EasyDMARC’s 2026 DMARC Adoption Report found that 52.1% of the top 1.8 million domains have published a DMARC record, while most of those remain at p=none with no active enforcement. A published record at p=none satisfies the letter of the bulk sender requirements without delivering the protection DMARC exists to provide, which leaves a large population of domains technically compliant and practically spoofable.
Closing that gap is a monitoring problem before it is a policy problem. EasyDMARC aggregates and parses incoming reports to identify and authenticate sending sources before enforcement is applied. For a fuller view of how DMARC maps to specific regulatory obligations, see DMARC service compliance readiness.
Getting Started with DMARC
The standard starting point is a record at p=none with rua= configured to a mailbox or platform that can receive aggregate reports. This publishes a valid DMARC record, satisfies bulk sender requirements, and begins collecting data without any risk to mail flow. Nothing is enforced, so nothing legitimate can break.
The work between publishing and enforcing is inventory. Aggregate reports will surface every source sending mail as the domain, and in most organizations that list is longer than expected: marketing automation, invoicing systems, support desks, HR platforms, CRM tools, and vendors nobody documented. Each legitimate source needs SPF authorization, DKIM signing, or both, with alignment to the From domain. Only once that inventory is complete and authenticated does policy advancement make sense. The progression is p=none for visibility, p=quarantine as intermediate enforcement, and p=reject as full enforcement, with monitoring continuing at every stage. If existing records still carry pct=, removing it is now correct practice under RFC 9989.
EasyDMARC provides monitoring and reporting across that full progression, turning raw aggregate report XML into an identifiable list of sending sources and authentication status. Managed service providers running this across a client base can find the multi-tenant approach covered under DMARC for MSPs. For implementation detail on record configuration and policy advancement, see DMARC best practices.
DMARC Is the Baseline
DMARC addresses exact-domain spoofing at the protocol level, and it does that job well enough that publishing an enforced record should be treated as a baseline rather than an achievement. It is one layer within a broader email security posture that also includes authentication hygiene, continuous monitoring, threat detection, and user awareness. Start with visibility: publish a record, collect aggregate reports, and find out what is sending as your domain today.
Frequently Asked Questions
DMARC is an email authentication protocol that lets a domain owner publish a DNS policy telling receiving mail servers how to handle messages that claim to come from their domain but fail authentication. It builds on SPF and DKIM rather than replacing them, adding an alignment check against the visible From domain plus a reporting mechanism. It is a policy and reporting layer, not a standalone authentication method.
It gives domain owners two things they otherwise lack: visibility into every source sending mail as their domain, and an enforceable instruction to receivers about failing mail. At p=reject, messages that forge the exact domain in the From header are refused at the SMTP level rather than delivered. The aggregate reporting side is equally important, since it exposes unauthorized and undocumented sending sources.
No. DMARC reduces spoofing risk for the exact domain in the From header and nothing beyond that. Lookalike domains, compromised legitimate accounts, and display name spoofing all pass or bypass DMARC entirely because none of them forge the protected domain. DMARC is one control within a layered defense, not a complete anti-phishing solution.
Technically no, since DMARC passes if either aligned SPF or aligned DKIM passes. In practice, you should configure both, because they fail under different conditions. SPF breaks when mail is forwarded and the IP changes, while DKIM survives forwarding as long as the signed content is unmodified, so having both gives legitimate mail two independent paths to an aligned pass.
That depends entirely on the published policy. Under p=none, they are delivered normally and only recorded in aggregate reports. Under p=quarantine, receivers route them to spam or junk, and under p=reject, receivers refuse delivery outright. Receiving servers make the final decision, and some apply their own filtering logic on top of the stated policy.
We’re glad you joined EasyDMARC newsletter! Get ready for valuable email security knowledge every week.
You’re already subscribed to EasyDMARC newsletter. Continue learning more about email security with us
