What Does DMARC Do? A Practical Guide to Domain‑Based Message Authentication
Key Takeaways
- DMARC, which stands for Domain-based Message Authentication, Reporting, and Conformance, tells receiving mail servers what to do when email messages fail SPF and DKIM checks.
- DMARC enforces domain based message authentication, helps stop direct domain spoofing, and strengthens dmarc email security against phishing attacks and business email compromise.
- A dmarc record is a dns txt record in the domain’s dns settings that publishes the domain’s dmarc policy and tells providers where to send dmarc reports.
- Since 2024–2025, Google, Yahoo, and Microsoft have expected many bulk email senders to use spf and dkim with DMARC for reliable email deliverability.
- DMARC is powerful, but it is not a complete shield. It must be monitored, tuned, and combined with broader email security controls.
If someone can send an email that looks like it came from your organization, they can damage your brand, trick customers, and trigger costly fraud. This guide explains what does DMARC do, how it works with SPF and DKIM, and how to move from your first record to full enforcement without breaking legitimate messages. For implementation steps, see our DMARC setup guide. For troubleshooting, see why emails fail DMARC. For a protocol comparison, see DMARC vs DKIM.
What Does DMARC Actually Do?
DMARC is an email authentication protocol that helps protect an email domain from being used in cyber-attacks like phishing and spoofing. In plain language, it lets a domain owner say: “If an email claims to come from my domain but is not properly authenticated, here is what you should do with it.”
That control is the core answer to what does DMARC do.
DMARC sits on top of sender policy framework and domainkeys identified mail. First, recipient mail servers check SPF and DKIM. Then the recipient mail server checks DMARC to decide whether a message should be delivered to the recipient’s inbox, sent to the spam folder, or rejected.
The key concept is dmarc domain alignment. DMARC checks whether the visible “From:” domain matches the domain authenticated by SPF or DKIM. This helps block spoofed messages that use your exact sender’s domain, which is why DMARC is especially useful against direct domain spoofing.
DMARC adds two things SPF and DKIM do not provide alone: policy and visibility. It enables domain owners to publish instructions, authenticate email senders, and receive reporting on who is using their domain. In practical terms, dmarc domain based message authentication reporting and conformance means policy-based email validation plus reporting.
How DMARC Works With DKIM and SPF
DMARC, DKIM, and SPF are three email authentication methods that work together to prevent unauthorized parties from sending emails on behalf of a domain. To make dmarc work, at least one of DKIM or SPF must pass and align with the visible From domain.
SPF, or Sender Policy Framework, lets domain owners specify which servers are authorized to send emails on behalf of their domain. A spf record is a txt record in DNS that lists approved hosts or sending IPs. SPF authentication is checked against the return path domain, not necessarily the visible From address.
DKIM, or DomainKeys Identified Mail, adds a digital signature to emails to verify their authenticity. The sending service signs the message using a private key, and the receiving server verifies the dkim signature using a public key published in DNS. This supports dkim authentication by confirming that key parts of the message were not changed.
Here is the simple flow:
- A message arrives at mail servers.
- SPF and DKIM checks run.
- DMARC checks whether dkim and spf results align with the From domain.
- The domain’s dmarc policy is applied if the email fails authentication.
What Is a DMARC Record and Where Are DMARC Records Stored?
A DMARC record is a DNS TXT record that specifies how receiving mail servers should handle emails that fail authentication checks, and it is published in the domain’s DNS settings. The standard location is:
_dmarc.yourdomain.com
So, where are dmarc records stored? They are stored publicly in DNS, usually managed through your dns provider or dns hosting company, alongside the domain’s spf record and DKIM txt record entries.
Common DMARC tags include:
| Tag | What it does |
|---|---|
| v | Sets the dmarc version, usually DMARC1 |
| p | Defines the dmarc policy: none, quarantine, or reject |
| rua | Tells providers where to send aggregate reports |
| ruf | Optional failure report destination |
| pct | Applies policy to a percentage of mail |
| adkim | Sets DKIM alignment mode |
| aspf | Sets SPF alignment mode |
Example dmarc dns record for 2025:
_dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; pct=50; adkim=s; aspf=r"
This dmarc txt record tells receiving mail servers to quarantine half of failing mail, send aggregate data to the reporting address, require strict DKIM alignment, and allow relaxed SPF alignment. The domain owner publishes this through the domain’s dns settings.
The record itself is public. The dmarc reports are private messages sent to the addresses you list. You can use a dmarc record checker to confirm that the domain’s dmarc record is valid.
DMARC Domain Alignment and DMARC Policy Levels
DMARC domain alignment checks whether the visible From domain aligns with the authenticated domain. For SPF, alignment compares the From domain with the return path domain. For DKIM, alignment compares the From domain with the d= domain in the DKIM signature.
Alignment can be relaxed or strict. Relaxed alignment allows subdomains under the same organizational domain. Strict alignment requires an exact match. Organizations that need tighter dmarc email security may choose strict alignment, but only after confirming all legitimate email senders are configured correctly.
DMARC offers three distinct policy levels: none, quarantine, and reject, which determine how receiving mail servers handle emails that fail authentication.
- p=none: monitor only.
- p=quarantine: treat suspicious messages with caution.
- p=reject: block unauthenticated messages.
Start with p=none for at least 30 days before moving to p=quarantine and eventually to p=reject, ensuring that legitimate emails are identified and authentication issues are resolved before enforcement.
DMARC Aggregate Reports: What They Are and What They Tell You
DMARC reports are the “R” in based message authentication reporting. They give domain owners feedback from receiving servers about how their email messages are being authenticated.
Aggregate reports, sent through rua, are the main type. These are usually daily XML summaries that include sending ip addresses, source domains, authentication results, the applied policy, and whether SPF or DKIM passed. They also show whether messages pass dmarc or fail authentication.
Failure reports, sent through ruf, are more detailed and may contain samples or headers from failed messages. Many organizations avoid or tightly limit these reports because of privacy and volume concerns.
Security teams use aggregate reports to find unknown services, validate legitimate senders, detect email fraud, and identify third-party platforms that are not properly authenticated. Raw XML is hard to read, so most teams use dashboards or internal parsers to turn the data into usable trends.
DMARC Email Security: What It Does for Business Risk
DMARC helps protect brand reputation by preventing unauthorized use of a domain in email communications, which can lead to phishing attacks and loss of customer trust. If attackers cannot easily impersonate your organization’s domain, customers and partners are less likely to receive fake invoices, password reset scams, or supplier impersonation messages that appear to come from you.
By implementing DMARC, organizations can improve their email deliverability rates, as emails that pass authentication are less likely to be marked as spam or rejected by recipient mail servers. This matters even more since major email service providers tightened bulk-sender expectations in 2024 and 2025.
DMARC does have limits. It does not stop lookalike domains, such as a domain with swapped letters. It also does not stop a compromised account that sends mail through legitimate systems. That is why DMARC should be treated as an email security protocol and email validation protocol, not a complete anti-phishing program.
How DMARC Helps Against Business Email Compromise (BEC)
Business email compromise is a fraud pattern where attackers impersonate executives, suppliers, or trusted employees to request payments, credential changes, or sensitive data. The FBI Internet Crime Complaint Center has repeatedly reported multi-billion-dollar losses from BEC schemes between 2019 and 2025.
DMARC disrupts common BEC patterns that rely on simple spoofing. For example, an attacker may try to send “CEO” mail from your real email domain without authorization. With strong dmarc authentication and p=reject, messages that fail authentication are rejected instead of landing in the recipient’s inbox.
This greatly reduces basic spoofing-based business email compromise. However, advanced BEC often uses lookalike domains or compromised real accounts that may pass authentication. DMARC shrinks the attack surface, but it does not replace user training, anomaly detection, payment approval workflows, or fraud controls. A cybersecurity services provider can layer DMARC enforcement with these additional protections.
Implementing DMARC: From First Record to Full Enforcement
To implement DMARC, organizations must first ensure that they have valid SPF and DKIM records published in their DNS, as DMARC requires at least one of these protocols to pass for authentication to succeed. Include corporate mail, marketing platforms, CRM tools, support systems, billing systems, and any application that sends as your domain.
A starting record might look like this:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; pct=100; adkim=s; aspf=s
Monitor aggregate reports for 30–60 days. Fix services that fail authentication, update SPF records, enable DKIM where possible, and remove unknown senders. Reverse dns records may help with reputation checks, but they do not replace DMARC, SPF, or DKIM.
Then move gradually:
- p=none for visibility.
- p=quarantine; pct=10 to test enforcement.
- Increase to pct=50, then pct=100.
- Move to p=reject when all legitimate messages align.
Common DMARC Domain Based Message Authentication Misconceptions
A few misconceptions still appear in email security discussions.
First, DMARC does not protect all inbound email from every other domain. It protects your own domain from being used in unauthenticated outbound-looking mail.
Second, “SPF and DKIM are enough” is not true. Without DMARC policy and reporting, there is no clear instruction to reject failures and much less visibility into abuse.
Third, DMARC is not set-and-forget. New SaaS tools, new mail streams, expired selectors, and changed authentication practices can all create delivery problems.
Common errors include multiple DMARC records on one domain, missing rua addresses, overlong SPF records that exceed DNS lookup limits, and forgotten third-party services. These mistakes can cause legitimate messages to be quarantined or rejected.
DMARC in the Context of 2024–2026 Email Requirements
In early 2024, Google and Yahoo tightened requirements for high-volume senders, expecting valid SPF, DKIM, and DMARC records. Microsoft followed with similar requirements in 2025. Google explains these expectations in its email sender guidelines.
These changes are designed to promote broader adoption of domain-based message authentication reporting and conformance across organizations of all sizes. The direction is clear: unauthenticated bulk mail is becoming harder to deliver.
Regulators and industry standards are also pushing stronger authentication in high-risk sectors like finance, healthcare, and government, making DMARC part of broader IT compliance expectations. Non-compliant senders may face degraded email deliverability, more spam placement, or outright rejection.
Starting now positions your organization well for future authentication mandates and makes your email more trustworthy over time.
FAQ
Does DMARC work if I only use SPF or only DKIM?
Yes, DMARC can pass if either SPF or DKIM passes and aligns with the From domain. However, using both is strongly recommended because forwarding can break SPF, and some systems may not preserve DKIM correctly.
For non-sending domains, such as parked domains, you can publish a restrictive DMARC record with p=reject to prevent any use of that domain for email.
How can I quickly check if a specific email passed DMARC?
Open the full message headers in your email client and look for the Authentication-Results header. You should see values like spf=pass, dkim=pass, and dmarc=pass or dmarc=fail.
If raw headers are hard to read, use a reputable header analyzer that parses SPF, DKIM, and DMARC verdicts.
What is the difference between aggregate DMARC reports and forensic DMARC reports?
Aggregate reports are regular XML summaries, usually daily, that group messages by source, ip address, and outcome. They generally do not include full message content.
Forensic reports are more detailed failure reports and may include header samples. Most organizations should start with only aggregate reports, then carefully decide whether forensic data is necessary.
How long does it usually take to move from p=none to p=reject?
Small organizations with only a few senders may reach p=reject in 4–8 weeks. Larger enterprises with many third-party systems may need several months.
Do not rush. Review dmarc reports, confirm dmarc domain alignment, and make sure all legitimate senders are covered before enforcing rejection.
Can DMARC stop phishing from lookalike or cousin domains?
No. DMARC controls mail using your exact domain. It does not directly stop attackers from registering a similar-looking domain and authenticating that domain correctly.
Combine DMARC with brand monitoring, defensive registrations, user awareness, and advanced email security tools to detect lookalike-domain impersonation.
If your organization has not implemented DMARC or is stuck at p=none without a path to enforcement, contact our team to get your email authentication where it needs to be.
LeadingIT is a cyber-resilient technology and cybersecurity services provider. With our concierge support model, we provide customized solutions to meet the unique needs of nonprofits, schools, manufacturers, accounting firms, government agencies, and law offices with 25–250 users across the Chicagoland area. Our team of experts solves the unsolvable while helping our clients leverage technology to achieve their business goals, ensuring the highest level of security and reliability. Call us at 815-788-6041 or contact us today.
