Domain-based Message Authentication, Reporting, and Conformance (DMARC) is an email authentication standard that tells receiving mail servers how to handle messages that claim to come from your domain but cannot prove it. It closes a blind spot that older standards leave open in the address recipients actually see in the "From" line, a weakness attackers have exploited for years.
Most domains still leave that exposure wide open. Fortra's 2025 analysis of 10 million domains found that 81.6% had no DMARC record at all. DMARC gives domain owners a way to close that opening.
Key Takeaways
- DMARC is an email authentication standard that tells receiving servers how to handle messages that fail to prove they came from your domain.
- It closes a vulnerability left by SPF and DKIM by linking authentication results to the domain a recipient actually sees in the "From" field.
- A DMARC record set to reject blocks unauthenticated spoofing attempts before they reach an inbox, while a record set to none only collects reports.
- DMARC reduces exact-domain spoofing but does not stop lookalike domains, display-name impersonation, or phishing that relies on message content rather than domain authentication.
What DMARC Does
DMARC works by linking the results of two older authentication checks to the domain a recipient actually sees in the "From" field, then publishing what receiving servers should do when that link fails. Domain owners publish a DMARC policy in their DNS records, and participating mail servers check incoming messages against it before delivery.
Fraudulent email often relies on unauthorized use of a legitimate domain name in the visible "From" header. Sender Policy Framework (SPF) authenticates the envelope sender used during the mail transaction. DomainKeys Identified Mail (DKIM) authenticates a signing domain. DMARC checks whether either authenticated domain matches the domain shown to the recipient.
DMARC adds both enforcement and visibility. Receiving servers can report back to the domain owner about messages claiming to originate from their domain, including messages that failed authentication. As a result, senders can protect their domain reputation and identify misuse, while recipients gain a stronger signal about whether a message is genuinely authorized.
How DMARC Stops Domain Spoofing
DMARC works by comparing the visible "From" domain against the domains authenticated by SPF and DKIM, then applying the domain owner's published policy when those checks do not line up.
Domain Owners Publish the Policy in DNS
The process starts when a domain owner publishes a DMARC record as a DNS TXT entry at the _dmarc subdomain. This record is a structured text string that declares how the domain handles authentication and what it wants receivers to do with mail that fails. A basic record specifies the protocol version and requested policy, with an address for aggregate reports.
The policy tells receiving servers whether to take no action, treat failing mail as suspicious, or reject it outright. Because the record lives in public DNS, any participating mail server can look it up when an email arrives. This allows the domain owner's instructions to travel with every message claiming to come from that domain, without direct coordination between sender and receiver.
The published instruction turns authentication into enforcement. SPF and DKIM can produce pass or fail results, but the DMARC record tells the receiver how the domain owner wants those results interpreted when the visible sender cannot be verified.
Alignment Determines Whether a Message Passes
When a message arrives, a DMARC-enabled receiver runs an SPF check, evaluates any DKIM signatures, and looks up the DMARC policy for the domain in the "From" header. DMARC then asks whether at least one authenticated domain aligns with the author domain. A message earns a DMARC pass only when SPF or DKIM passes and the passing domain matches the visible sender closely enough to satisfy the domain's alignment settings.
That alignment requirement blocks a common spoofing path. Without it, an attacker could authenticate mail using their own domain while displaying a trusted brand in the visible address. With DMARC, a message passes only when the authenticated identity lines up with the domain the recipient sees.
Once the receiver has the combined result, it applies the domain owner's requested policy. If the message fails DMARC, the policy determines whether it is delivered normally, quarantined, or rejected. Receivers retain some discretion in practice; they may still quarantine a message that technically passes, or accept one that fails, based on their own filtering judgment. Even so, the policy gives them a clear, sender-authorized signal to act on.
DMARC vs. SPF vs. DKIM
DMARC, SPF, and DKIM are separate email authentication standards that solve different parts of the same problem, and DMARC only works when it sits on top of the other two.
SPF and DKIM Blind Spots
SPF is the standard way for a domain to declare which mail servers are authorized to send on its behalf. A receiving server checks the sending IP address against the domain's published SPF record and confirms whether that source is permitted. DKIM takes a different approach by attaching a digital signature generated by the sending server, so a receiver can verify that the message was authorized by the signing domain and was not altered in transit.
Each mechanism authenticates a different part of the message:
- SPF: Authenticates the envelope sender used during the transaction.
- DKIM: Authenticates the domain in its signature.
- DMARC: Supplies the link to the visible "From" header, the field a recipient relies on to judge whether a message is trustworthy.
That difference matters because the envelope sender, signing domain, and visible sender can be different. A message can pass SPF or DKIM and still show a trusted domain to the recipient that was not actually authenticated by either mechanism.
The Alignment Requirement
SPF or DKIM can pass while the visible "From" domain goes unverified. DMARC closes that flaw by requiring identifier alignment: SPF or DKIM must pass, and the domain that passed must also align with the domain in the "From" header. Without this linkage, an attacker could authenticate mail using their own domain while still displaying a trusted brand to the recipient.
DMARC supports two alignment modes, set through the aspf and adkim tags in the record:
- Strict Mode: Only an exact domain match counts as alignment, so the authenticated domain and the "From" domain must be identical.
- Relaxed Mode: The default setting, where the two domains pass as long as they share the same organizational domain.
The difference shows up in everyday mail flows. A validated DKIM signature with a signing domain of example.com on a message from alerts@news.example.com would pass relaxed alignment because the domains share the same organizational domain. Under strict alignment, the same message would fail because the signing domain does not exactly match the subdomain in the "From" address.
DMARC Policy Levels and Record Tags
DMARC defines three policy levels and a small set of record tags that let domain owners move from monitoring to enforcement while controlling reports and subdomains.
Three Policy Levels, Two Required Tags
DMARC supports three policy levels that escalate the response to failing mail:
- None: The domain owner requests no specific delivery action, so mail is handled as it normally would be. This mode exists to collect reports rather than block anything, making it useful at the start of a rollout since it shows who is sending mail under the domain's name without changing delivery behavior.
- Quarantine: Receivers treat failing mail as suspicious, which can mean routing it to the spam or junk folder or subjecting it to additional scrutiny.
- Reject: Receivers block failing mail outright, ideally during the SMTP transaction before it ever reaches a mailbox.
The intended path is to start at none for visibility, then tighten to quarantine and reject once legitimate mail is reliably passing.
A DMARC record is a DNS TXT entry built from tag-value pairs, with two required tags:
v: Must be the first tag and set toDMARC1. If it's missing or incorrect, the entire record is ignored.p: Sets the policy to none, quarantine, or reject.
Together, v and p form the minimum valid record, with every other tag building on that foundation to add reporting, alignment, and subdomain control.
Reporting and Subdomain Tags
Most records use only a handful of the available tags, but reporting and scope tags are what make DMARC practical to manage:
rua: Lists one or more addresses that should receive aggregate feedback reports.ruf: Lists addresses for message-specific failure reports.fo: Sets the conditions under which failure reports are generated, such as when either SPF or DKIM fails rather than only when both do.adkimandaspf: Control DKIM and SPF alignment mode respectively, both defaulting to relaxed unless set to strict.sp: Sets a separate policy for subdomains; if it is absent, subdomains follow the mainppolicy.
Two older tags, pct and rf, are deprecated in the updated DMARCbis specification and can signal a configuration that needs review. A basic record can still be valid with just the required version and policy, but a reporting address turns the record from a static instruction into a useful management tool.
DMARC Reports and Rollout
DMARC reporting helps domain owners identify legitimate senders and spot abuse before they enforce a blocking policy.
Aggregate and Failure Reports
DMARC generates two distinct report types:
- Aggregate Reports: Requested through the
ruatag, these arrive on a regular schedule as redacted XML summaries showing message counts, SPF and DKIM results, alignment outcomes, and the policy applied, without exposing recipient addresses or message content. - Failure Reports: Requested through the
ruftag, these arrive almost immediately after a failure and can include a full copy of the offending message, useful for debugging or investigating an active spoofing campaign.
Every spoofed message can trigger a failure report, so the stream can dwarf legitimate mail, and not all receivers honor these requests. A practical approach is to begin with aggregate reports in monitoring mode, study them carefully, and add failure reporting to a separate mailbox only once the policy is ready to tighten.
Monitoring Before Enforcement
A safe DMARC rollout follows a staged sequence: monitor first, confirm alignment, then enforce gradually.
- Start at None: Set the record to
p=noneto collect aggregate reports without changing how any mail is delivered, giving the domain owner a picture of every source sending under their name, authorized or not. - Confirm Sender Alignment: Verify that legitimate senders, including third-party services such as marketing platforms and support ticketing tools, are producing aligned mail. Forwarded or modified messages can complicate this step, since routing and header changes may affect the identifiers DMARC compares.
- Escalate Enforcement Gradually: Move to quarantine and then reject only once every sending service has been accounted for, since rushing to reject risks blocking legitimate mail that hasn't yet been brought into alignment.
The end state is p=reject applied to all mail, an outcome CISA's broader performance goals recommend for corporate email infrastructure generally.
Why DMARC Matters and Where Its Limits Are
DMARC matters because direct domain spoofing is a common entry point for fraud, but its protection is limited to the domain authentication problems it was designed to solve. Many business email compromise schemes begin with a message that appears to come from a trusted domain, which is exactly the deception DMARC's alignment check is built to close.
At an enforcing policy, DMARC automatically blocks unauthenticated messages that claim to come from your domain, which removes a favorite tool from attackers running phishing attacks and business email compromise campaigns. It also protects the domain's reputation by preventing spammers from sending under a trusted name. The reporting function adds a quieter benefit: it surfaces apparent forgeries and misconfigured legitimate services before a domain owner commits to blocking anything.
DMARC is precise about what it covers, and that precision defines its limits. It protects the domain in the address portion of the "From" field, but it does not protect the display name. Lookalike domains use registered names deceptively similar to a target, such as a name that swaps the letter "i" for the numeral "1." Malicious attachments and links to fraudulent sites can likewise pass through because they involve message content, outside DMARC's domain-authentication check.
Building a Trustworthy Email Foundation
DMARC turns email authentication into an enforceable, observable control. Tying SPF and DKIM results to the domain recipients actually see, while giving senders feedback on how their domain is used, removes one of the most reliable tricks attackers depend on. A domain that progresses thoughtfully from monitoring to reject gives everyone who receives its mail a stronger basis for trust.
Frequently Asked Questions
Is DMARC Required?
Specific DMARC requirements apply in important contexts. CISA requires U.S. federal civilian agencies to publish valid DMARC records and progress to a reject policy on all second-level domains and mail-sending hosts.
What Happens if You Don't Have a DMARC Record?
Without a DMARC record, receiving servers have no published instruction on how to handle unauthenticated mail claiming to come from your domain. SPF and DKIM can authenticate messages, but neither tells a receiver what to do when validation fails. The practical effect is that direct domain spoofing cannot be blocked at the receiving server, so attackers can more easily send convincing mail in your domain's name.
How Do You Check a DMARC Record?
A DMARC record is published as a DNS TXT record at the _dmarc subdomain of the sending domain, for example _dmarc.example.com. DNS lookup tools query that location and return the policy along with any syntax issues. A minimal valid record needs only the version and policy tags, though including an aggregate reporting address is strongly recommended so the domain owner can see results.
Does DMARC Stop All Phishing?
No. DMARC stops exact-domain spoofing, where an attacker sends mail using your real domain in the visible address. It does not stop lookalike domains, display-name impersonation attacks, compromised legitimate accounts, or malicious content within otherwise authenticated mail. DMARC is a strong layer of defense, and phishing requires defenses beyond domain authentication.
