What Is DMARC?
An email authentication protocol that lets domain owners control what happens to email that fails SPF or DKIM checks. It stops attackers from sending email that appears to come from your domain — a technique called spoofing — by publishing a policy in DNS that tells receiving mail servers how to handle unauthenticated messages. DMARC is defined in RFC 9989 (published May 2026), which updated the original RFC 7489 standard. Existing records configured correctly before the update remain valid with no migration needed.
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is an open email authentication protocol that gives domain owners the ability to protect their domain from unauthorized use — commonly known as email spoofing.
Email spoofing is one of the most common tactics in phishing attacks. Without DMARC, anyone can send an email that appears to come from your domain, deceiving customers, employees, and partners. DMARC solves this by building on two existing authentication standards — SPF and DKIM — and adding a critical layer: a published policy that tells receiving mail servers what to do when authentication fails.
Published as a DNS TXT record at _dmarc.yourdomain.com, a DMARC record gives you control over how your domain is used in email and provides visibility through aggregate and forensic reports.
DMARC is defined in RFC 9989 (published May 2026), which updated the original RFC 7489 standard. Existing records remain valid with no migration needed.
How DMARC Works
DMARC does not work alone. It builds on two existing authentication protocols — [SPF](https://simpledmarc.com/tools/spf-checker) (Sender Policy Framework) and [DKIM](https://simpledmarc.com/tools/dkim-checker) (DomainKeys Identified Mail), and adds a concept called alignment that ties them together.
1. SPF Check
SPF verifies that the sending server's IP address is authorised to send mail for your domain. The receiving server looks up your SPF record in DNS and checks whether the sending IP is listed. DMARC then checks whether the domain in the SPF result aligns with the domain shown in the email's From: header.
2. DKIM Check
DKIM attaches a cryptographic signature to outgoing email. The receiving server retrieves the public key from your DNS and verifies the signature, confirming the message was not altered in transit. DMARC then checks whether the DKIM signing domain aligns with the From: header domain.
3. Alignment
Alignment is the core innovation DMARC adds. For a message to pass DMARC, either SPF or DKIM must pass, and the domain they authenticate must match the domain shown in the visible From: header. This closes the gap that lets attackers pass SPF or DKIM using their own domain while forging your domain in the From: field.
4. Policy Application
If neither SPF nor DKIM passes with proper alignment, the receiving server applies the policy in your DMARC DNS record: deliver the message anyway, send it to spam, or reject it outright.
The Three DMARC Policies
The p= tag in your DMARC record defines the enforcement policy. There are three levels.
p=none — monitor only
No action is taken on failing email. Messages are delivered normally regardless of whether they pass or fail authentication. This is the correct starting point: you collect data and understand what's sending email as your domain before enforcing any restrictions.
p=quarantine — suspicious email goes to spam
Email that fails DMARC authentication is delivered to the recipient's spam or junk folder rather than their inbox. The message still reaches the recipient but is flagged as suspicious. This is the intermediate enforcement step — meaningful protection while you confirm that all legitimate senders are authenticated.
p=reject — unauthorised email is blocked
Email that fails DMARC is rejected by the receiving server before it reaches the recipient at all. This is full protection: no spoofed email claiming to come from your domain can reach an inbox anywhere. Most organisations should target p=reject as their end state.
DMARC Reporting
Reporting is what makes DMARC operationally useful, not just protective. When you publish a DMARC record with a rua= address, receiving mail servers send you daily reports on everything that claims to come from your domain.
Aggregate Reports (RUA)
Aggregate reports are sent daily in XML format. They contain a statistical breakdown of all email traffic using your domain: which IP addresses sent email claiming to be from you, how many messages passed or failed SPF, DKIM, and alignment checks, and which policy was applied. These reports are how you identify legitimate senders that need to be authenticated before you can enforce DMARC.
Raw aggregate report XML is difficult to interpret manually. SimpleDMARC's [XML report analyser](https://simpledmarc.com/tools/xml-to-human-converter) converts them into a readable dashboard automatically.
Forensic Reports (RUF)
Forensic reports provide message-level details on individual emails that fail DMARC authentication — headers, metadata, and the failure reason. They're useful for investigating specific spoofing attempts or diagnosing why a particular sender is failing. Not all mailbox providers send forensic reports due to privacy considerations, so they're a supplement to aggregate data, not a replacement.
What the DMARC DNS Record Looks Like
A DMARC record is a TXT record published at _dmarc.yourdomain.com. Here is a typical starting record for a domain entering the monitoring phase:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:reports@example.com; fo=1;"What each tag does:
- v=DMARC1 — required, must be first. Identifies this as a DMARC record.
- p=none — the policy. Start here, move to quarantine then reject as you verify senders.
- rua=mailto:reports@example.com — where aggregate reports are sent. Use your DMARC platform's reporting address so reports are parsed automatically.
- fo=1 — forensic reporting options. fo=1 generates a forensic report if any authentication mechanism fails.
Once you have verified all your legitimate senders and are ready to enforce, the record moves to
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:reports@example.com; fo=1;"The pct=100 tag applies the policy to 100% of failing email. During the transition from p=quarantine to p=reject, you can use a lower percentage pct=10, pct=25) to roll out enforcement gradually.
Why DMARC Matters Now
Email spoofing is involved in the majority of phishing attacks and nearly all business email compromise (BEC) attempts. Without DMARC at p=reject, anyone can send email that appears to come from your domain — targeting your customers, your staff, or your suppliers.
Major mailbox providers have made DMARC a deliverability requirement. Google and Yahoo require a valid DMARC record for domains sending more than 5,000 messages per day to their platforms. Microsoft enforces equivalent requirements for Outlook.com. Non-compliant email is throttled, sent to spam, or rejected.
PCI DSS v4.0, effective March 2025, requires DMARC as part of anti-phishing controls for organisations that process payment card data. CISA Binding Operational Directive 18-01 requires DMARC for US federal executive branch domains.
DMARC also protects your brand. When attackers send phishing email using your domain, the reputation damage affects your customers' trust in your legitimate email, including marketing campaigns, transactional receipts, and support responses..
Getting Started with DMARC
_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1;"Implementing DMARC is a journey that typically follows four phases:
Publish a DMARC record with p=none
Start collecting data without affecting email delivery. Use the [DMARC record generator](https://simpledmarc.com/tools/dmarc-generator) to create your record, then add it as a TXT record at
_dmarc.yourdomain.comin your DNS provider.Analyze your reports
After 24–48 hours, reports start flowing in. Review which IP addresses and services are sending email as your domain. Identify everything — your mail server, your CRM, your helpdesk tool, your newsletter platform, and verify each one is configured with correct SPF and DKIM authentication.
Move to p=quarantine
Once every legitimate sender is passing authentication, update your policy to
p=quarantine. Unauthorised email goes to spam. Monitor for false positives over the next one to two weeks.Enforce with p=reject
Update to
p=reject. Spoofed email claiming to come from your domain is blocked before it reaches any inbox anywhere.SimpleDMARC has been monitoring domains since 2020. Unlike platforms that charge by email volume, we price on storage — meaning attack traffic targeting your domain never counts against your plan. [Start monitoring free at simpledmarc.com](https://simpledmarc.com/pricing).
Ready to Protect Your Domain?
Start with a free DMARC check to see where your domain stands today.
Check your domain's current DMARC status free — no account required.
Frequently Asked Questions
Do I need both SPF and DKIM for DMARC?
DMARC requires at least one of SPF or DKIM to pass with proper alignment. You don't need both to pass — just one. In practice, setting up both is worth doing. SPF alone fails for forwarded email because the forwarding server's IP isn't in your SPF record. DKIM signatures survive forwarding intact. Having both means DMARC passes on DKIM even when SPF breaks due to forwarding, which reduces false positive failures when you move to enforcement.
What is DMARC alignment?
Alignment is the mechanism that connects an SPF or DKIM pass to the domain your recipient actually sees in the From: header. Without alignment, an attacker could set up their own domain, pass SPF or DKIM on that domain, and still forge your domain in the visible From: address. DMARC closes this by requiring that the domain authenticated by SPF or DKIM matches your From: domain. DMARC supports two alignment modes: strict (exact domain match) and relaxed (organizational domain match, so mail.example.com aligns with example.com). Relaxed is the default and works for most configurations.
Is DMARC free to set up?
Publishing a DMARC DNS record is free — it is a TXT record in your DNS, the same as SPF and DKIM. The records themselves cost nothing regardless of which DNS provider you use. What most organisations pay for is a monitoring platform to parse the aggregate report XML into something readable and useful, since raw DMARC reports are machine-formatted XML that is difficult to interpret manually. SimpleDMARC offers a free tier that covers a single domain with automatic report parsing and no credit card required.
Can DMARC break my email delivery?
Yes, if you move to p=reject before all your legitimate senders are authenticated. Any sending service that isn't covered by your SPF record or signing with DKIM will fail DMARC, and at p=reject its email gets blocked. This is why the recommended approach starts at p=none: you collect reports, identify every service sending email as your domain, fix authentication for each one, and only enforce after everything is verified. Use the pct= tag to roll out enforcement gradually — pct=10 applies the policy to 10% of failing email, giving you a controlled test before going to 100%.
What is the difference between DMARC and email encryption?
DMARC and email encryption solve different problems. DMARC verifies the identity of the sender and prevents domain spoofing. Email encryption (like TLS or S/MIME) protects the content of the message from being read during transit. Both are important, but they serve complementary purposes.
What is DMARC and why do I need it?
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a DNS-published policy that tells receiving mail servers how to handle email that fails authentication checks. You need it because without it, anyone can send email that appears to come from your domain. Attackers use this to run phishing campaigns against your customers, impersonate your business in wire fraud attempts, and damage your brand reputation. DMARC at p=reject makes domain spoofing technically impossible — the spoofed email never reaches the recipient's inbox.
What is the difference between DMARC and DKIM?
DKIM and DMARC solve different problems. DKIM is a cryptographic signing mechanism: your mail server signs outgoing email with a private key, and receiving servers verify the signature using your public key published in DNS. This confirms the message came from an authorised server and wasn't altered in transit. DMARC is the policy layer that sits on top. It evaluates whether SPF or DKIM passed and aligns with your From: domain, then tells the receiving server what to do if they don't. DKIM provides the authentication; DMARC provides the enforcement and reporting. You need both.
What happens to DMARC reporting if I don't add an rua= address?
If your DMARC record has no rua= tag, you receive no aggregate reports. The policy still applies — email that fails DMARC will be handled according to your p= setting — but you have no visibility into what's happening. You won't know which senders are failing, whether attackers are spoofing your domain, or how many of your legitimate emails are passing authentication. Operating DMARC without reporting is like installing a lock but never checking whether it's working. Always include a rua= address pointing to a platform that parses the reports automatically.