What is DMARC? Why 66% of Companies Still Don't Have It Configured

What is DMARC?

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It is an email authentication protocol that sits on top of SPF and DKIM and does three things none of the others can do alone:

It enforces alignment. DMARC checks that the domain authenticated by SPF or DKIM actually matches the visible From address your recipient sees. This closes the biggest gap in email authentication: the fact that SPF and DKIM can both pass while the visible From header still shows a spoofed address.

It enforces policy. DMARC lets you tell receiving mail servers what to do with emails that fail authentication. Do nothing, send them to spam, or reject them outright. Without DMARC, that decision is entirely up to the receiving server. With DMARC, you are in control.

It reports back to you. DMARC sends you aggregate reports showing who is sending email using your domain, whether it is passing or failing authentication, and where in the world those emails are coming from. This gives you visibility into your own email ecosystem and into anyone trying to impersonate you.

If you have read the previous blogs in this series, you already understand SPF and DKIM. DMARC is the layer that ties them together and gives them teeth.

The Problem DMARC Was Built to Solve

SPF and DKIM are both genuinely useful, but they each have a critical blind spot when used without DMARC.

SPF checks the Return-Path address, which is the envelope sender used during the SMTP transaction. It does not check the visible From header your recipient sees.

DKIM checks that the email was signed by a particular domain and has not been tampered with. It does not check that the signing domain matches the visible From header.

This means an attacker can craft an email where:

• The Return-Path is from a domain that passes SPF
• The DKIM signature is valid for that same domain
• The visible From header shows ceo@yourcompany.com

Both SPF and DKIM pass. Your recipient sees your CEO's address. The email lands in their inbox. Without DMARC, there is nothing to catch this.

This specific attack vector, spoofing the visible From header while passing SPF and DKIM for a different domain, is one of the most common techniques in business email compromise today. DMARC closes it.

The alignment check is the key concept. For an email to pass DMARC, either the SPF-authenticated domain or the DKIM-signing domain must match the domain in the visible From header. Not just pass, but match. This is what makes DMARC fundamentally different from SPF and DKIM.

How DMARC Works: Step by Step

Step 1: You publish a DMARC record in DNS

A DMARC record is a TXT record published at a specific subdomain of your domain:

1_dmarc.yourcompany.com

A basic DMARC record looks like this:

1v=DMARC1; p=none; rua=mailto:dmarc-reports@yourcompany.com; pct=100

Step 2: An email arrives claiming to be from your domain

The receiving mail server extracts the domain from the visible From header and looks up the DMARC record at _dmarc.thatdomain.com.

Step 3: The receiving server runs SPF and DKIM checks

The server checks whether SPF passes and whether the SPF-authenticated domain aligns with the From domain. It checks whether DKIM passes and whether the DKIM-signing domain aligns with the From domain.

Step 4: DMARC alignment is evaluated

For DMARC to pass, at least one of the following must be true:

• SPF passes AND the Return-Path domain aligns with the From domain
• DKIM passes AND the DKIM signing domain aligns with the From domain

If neither is true, DMARC fails.

Step 5: The receiving server applies your policy

Based on the p= value in your DMARC record, the server either delivers the email, routes it to spam, or rejects it.

Step 6: The server sends you a report

At the end of each day, receiving servers send aggregate reports to the email address in your rua= field. These reports tell you every domain that sent email claiming to be from you, and whether those emails passed or failed authentication.

Understanding the DMARC Record

A full DMARC record has several tags. Here is a complete example with everything explained:

1v=DMARC1; p=reject; sp=quarantine; pct=100; 
2rua=mailto:dmarc@yourcompany.com; 
3ruf=mailto:forensic@yourcompany.com; 
4adkim=r; aspf=r

v=DMARC1
The version tag. All DMARC records start with this. There is currently only one version.

p=reject
The policy. This is the most important tag. It tells receiving servers what to do with emails that fail DMARC. The three options are covered in detail in the next section.

sp=quarantine
The subdomain policy. This sets a separate policy for subdomains of your domain, for example mail.yourcompany.com or news.yourcompany.com. If you omit this, the main policy p= applies to subdomains as well.

pct=100
The percentage of failing emails the policy applies to. At 100, every failing email is subject to your policy. You can set this lower during rollout, for example pct=10 to apply the policy to only 10% of failing emails, which lets you test the impact gradually. Most deployments should run at 100.

rua=mailto:
Where to send aggregate reports. These are daily XML reports showing authentication pass and fail rates across all email sent using your domain. Every DMARC record should include this.

ruf=mailto:
Where to send forensic (failure) reports. These are sent immediately when an email fails DMARC and include more detail about the specific failure. Not all receiving servers send these, and they can contain sensitive information, so handle the receiving address carefully.

adkim=r
DKIM alignment mode. r is relaxed (the default), which means the DKIM signing domain can be a subdomain of the From domain and still align. s is strict, which requires an exact domain match.

aspf=r
SPF alignment mode. Same options as above: r for relaxed, s for strict.

The Three DMARC Policy Levels

This is where most explanations get vague. Here is exactly what each policy does in practice.

p=none (Monitoring Mode)

1v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com

What it does: Nothing to the email. Emails that fail DMARC are delivered exactly as they would be without DMARC in place. The only thing p=none does is generate reports.

What it is for: The starting point when you first implement DMARC. You are telling the world: we have published a DMARC record, but we are not ready to enforce anything yet. We are watching and learning.

What it does not do: Block anything. An attacker can spoof your domain all day and every email will still be delivered. p=none gives you no protection whatsoever.

When to use it: Only during the initial setup phase while you are reviewing reports and confirming that all your legitimate email is properly authenticated. The mistake most organisations make is staying here permanently.

In email headers: dmarc=fail (p=none) - the email failed but was delivered anyway.

p=quarantine (Spam Folder)

1v=DMARC1; p=quarantine; rua=mailto:dmarc@yourcompany.com; pct=100

What it does: Emails that fail DMARC are sent to the recipient's spam or junk folder rather than their inbox. They are not rejected, but they are not delivered to the inbox either.

What it is for: The intermediate step between monitoring and full enforcement. You are starting to enforce a policy, but you are giving yourself a safety net: if something legitimate is failing authentication, it will end up in spam rather than being lost entirely.

What it does not do: Fully block spoofed emails. They still reach the recipient, just in the spam folder. A motivated recipient could still find and act on a spoofed email in their junk folder.

When to use it: After you have reviewed DMARC reports for several weeks, resolved any configuration issues, and confirmed that all your legitimate email is passing. Move here before going to reject.

In email headers: dmarc=fail (p=quarantine) - the email failed and was sent to spam.

p=reject (Full Enforcement)

1v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.com; pct=100

What it does: Emails that fail DMARC are rejected at the server level. They do not reach the recipient's inbox. They do not reach the spam folder. They are refused entirely, usually with a bounce back to the sender.

What it is for: Full protection. This is the goal. When you have p=reject in place, an attacker cannot successfully spoof your domain to your customers, partners, or staff. Any email claiming to be from your domain that does not pass authentication will be refused.

What it does not do: Catch every phishing attack. An attacker who sets up their own domain with valid authentication and sends from it will still reach inboxes. p=reject protects your specific domain from being spoofed, not from lookalike domains.

When to use it: Once you have completed the monitoring phase, resolved all configuration issues, confirmed all legitimate email is passing, and transitioned through quarantine. This is the end state every organisation should be working toward.

In email headers: dmarc=fail (p=reject) - the email was refused.

DMARC Alignment: Relaxed vs Strict

The alignment check is what makes DMARC work, and the mode you choose affects how strictly it is applied.

Relaxed alignment (the default)
The authenticated domain just needs to be the same organisational domain as the From domain. Subdomains are allowed.

For example, if your From address is user@yourcompany.com and the DKIM signature is from mail.yourcompany.com, relaxed alignment would pass because both are part of yourcompany.com.

Strict alignment
The authenticated domain must exactly match the From domain. No subdomains are permitted.

Using the same example: mail.yourcompany.com signing for a From address of @yourcompany.com would fail strict alignment because the domains do not exactly match.

For most organisations, relaxed alignment is the correct choice. It is flexible enough to accommodate common email infrastructure where subdomains handle sending, while still providing strong protection against spoofing.

Why 66% of Companies Still Have No DMARC

Given that DMARC has been available since 2012 and the consequences of not having it are well understood, the adoption gap is striking. The reasons are consistent across organisations of all sizes.

They did not know it existed. DMARC is not taught in most IT curricula. Many IT teams responsible for email administration have managed systems for years without understanding that SPF alone leaves a major gap.

They set it to p=none and forgot about it. A significant portion of the organisations that have published DMARC records have never moved past monitoring mode. The reports come in, nobody looks at them, and nothing gets enforced. This is arguably worse than no DMARC at all because it creates a false sense of security.

They are worried about breaking legitimate email. This concern is valid but manageable. The correct approach is the phased rollout through monitoring, quarantine, and reject, using DMARC reports to identify every legitimate sender first. Organisations that skip this process and jump to reject do sometimes break their own email. Organisations that follow the process rarely do.

Their email setup is genuinely complex. Large organisations often have dozens of third-party services sending email from their domain: marketing platforms, CRM tools, HR systems, support platforms, automated transactional services. Getting all of those properly authenticated before moving to reject takes time and coordination. It is genuinely hard work. It is also necessary.

Nobody prioritised it. Email authentication does not cause visible incidents until something goes wrong. There is no flashing alert that says "your domain was spoofed 47 times this week." The attacks are silent. DMARC reports exist specifically to make the invisible visible, but only if someone is looking at them.

The Microsoft Update That Changed Everything

In May 2025, Microsoft updated its email filtering requirements for Outlook, Hotmail, and Live accounts.

The change is significant. Microsoft is now:

• Requiring SPF, DKIM, and DMARC to be published for domains sending to Outlook users
• Routing emails from non-compliant domains to junk folders
• Warning that hard rejection is the next step for senders who do not comply

This follows Google and Yahoo, who introduced similar requirements for bulk senders in early 2024. Google required DMARC at p=none as a minimum for senders sending more than 5,000 messages per day. Microsoft has gone further by applying requirements to all senders.

The combined effect is that the three largest personal email providers in the world now treat DMARC as table stakes. If your domain does not have it published, your emails to these platforms are already being penalised.

For organisations that do business with individuals using Outlook, Hotmail, or Live addresses, the deliverability impact is immediate and measurable. Newsletters, invoices, onboarding emails, and password reset emails are all affected.

The practical message is this: DMARC is no longer optional infrastructure. It is a deliverability requirement.

Reading DMARC Reports

The reporting feature is one of DMARC's most underused capabilities, and it is genuinely valuable.

Aggregate reports (RUA) are sent daily as XML files from receiving mail servers to the address in your rua= tag. They are not particularly readable in raw form, but DMARC reporting tools parse them into dashboards that give you clear information.

A typical aggregate report tells you:

• The source IP addresses that sent email claiming to be from your domain
• The volume of email from each source
• Whether SPF passed or failed for each source
• Whether DKIM passed or failed for each source
• Whether DMARC passed or failed for each source
• The disposition applied to failing emails

During the monitoring phase, this data tells you everything you need to know: which of your legitimate services are passing authentication, which are failing, and whether any outside parties are trying to spoof your domain.

If you see IP addresses you do not recognise sending email from your domain, that is not a configuration issue. That is an active spoofing campaign. DMARC reports let you see attacks that would otherwise be completely invisible to you.

Tools worth knowing about for DMARC report parsing include Postmark's DMARC tool (free), Dmarcian, EasyDMARC, and Valimail. For most small to mid-size organisations, the free tier of any of these tools is enough to get started.

Common DMARC Mistakes

Staying at p=none indefinitely
This is the most widespread mistake. Monitoring mode generates reports but blocks nothing. An attacker can spoof your domain with complete success while you sit at p=none watching the reports come in. Set a deadline: review reports for four to six weeks, fix issues, move to quarantine, then reject.

Publishing DMARC without SPF or DKIM
DMARC depends on SPF and DKIM to function. If neither is set up correctly, DMARC has nothing to align against. Every email will fail DMARC, including your own legitimate mail. Sort SPF and DKIM first.

Not setting up rua reporting
A DMARC record without a reporting address is flying blind. You will have no idea what is passing, what is failing, or whether attackers are trying to spoof you. Always include rua=mailto:youremail.

Moving to p=reject without reviewing reports
Jumping straight to reject before understanding your full email ecosystem is how organisations accidentally break their own email. The monitoring phase exists for a reason. Use it.

Forgetting third-party senders
Your CRM, marketing platform, helpdesk tool, and payroll system may all send email from your domain. If they are not in your SPF record and do not have DKIM set up, they will fail DMARC once you start enforcing. Identify every service that sends on your behalf before moving past monitoring.

Using pct= less than 100 permanently
The pct= tag is useful during rollout to gradually increase the percentage of failing emails your policy applies to. It is not intended as a permanent setting. A domain at p=reject; pct=50 is only protecting half its email. Work toward pct=100.

How to Check If Your Domain Has DMARC

Two minutes and a free tool is all it takes.

MXToolbox:
Go to mxtoolbox.com/dmarc.aspx and enter your domain. You will see your current DMARC record, what policy it is set to, and any obvious issues.

Command line:

1dig TXT _dmarc.yourdomain.com

What you want to see: a TXT record starting with v=DMARC1, a policy of p=quarantine or p=reject, and an rua= address for reports.

What you do not want to see: no record at all, p=none with no plan to progress, or a record with no rua= address.

The Recommended Rollout Path

Week 1 to 2: Audit your email sending sources
List every service that sends email from your domain. Check that each one has SPF and DKIM configured correctly.

Week 2 to 4: Publish DMARC at p=none with reporting

1v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com; pct=100

Set up a DMARC reporting tool and start reading the reports.

Week 4 to 8: Review and fix
Work through the reports. Any source failing SPF or DKIM needs to be fixed before you tighten the policy. This is where most of the real work happens.

Week 8 to 10: Move to p=quarantine

1v=DMARC1; p=quarantine; rua=mailto:dmarc@yourcompany.com; pct=100

Monitor closely for the first week. Check whether any legitimate email is landing in spam folders.

Week 10 to 12: Move to p=reject

1v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.com; pct=100

You are now fully enforcing DMARC. Your domain cannot be spoofed in the From header without the email being refused.

Keep monitoring reports. Attackers will keep trying. The reports will show you when they do.

What DMARC Does Not Protect Against

DMARC is the most powerful of the three email authentication protocols, but it is still not a complete solution.

Lookalike domain attacks
An attacker who registers yourcompany-invoices.com and sets up SPF, DKIM, and DMARC for that domain will pass all checks. Your DMARC record only protects yourcompany.com. It says nothing about domains that look similar to yours.

Compromised accounts
An attacker who gains access to a legitimate email account within your domain sends authenticated email. DMARC passes because the email genuinely came from your domain with valid credentials.

Malicious links inside authenticated emails
DMARC says nothing about the content of a message. A fully authenticated email containing a link to a malicious website is still a threat. Authentication and content inspection solve different problems.

Display name spoofing without domain spoofing
An attacker can set the display name to "PayPal Support" while sending from a completely unrelated authenticated domain. The visible name in the email client may fool recipients even though the email address itself is unrelated to PayPal.

Interview Questions on DMARC

Q: What is DMARC and what does it add that SPF and DKIM cannot provide?
DMARC is an email authentication policy protocol that sits on top of SPF and DKIM. It adds two things the other protocols lack. First, it performs an alignment check: it verifies that the domain authenticated by SPF or DKIM matches the visible From address the recipient sees. Second, it gives the domain owner control over what happens to emails that fail: they can be delivered, quarantined, or rejected. Neither SPF nor DKIM alone can enforce these outcomes.

Q: What is DMARC alignment and why does it matter?
DMARC alignment is the check that the domain verified by SPF or DKIM matches the domain in the visible From header. Without this check, an attacker can pass both SPF and DKIM for their own domain while showing a completely different domain in the From address. Alignment closes this gap by requiring that the authenticated domain and the From domain are the same organisational domain (in relaxed mode) or an exact match (in strict mode).

Q: What is the difference between p=none, p=quarantine, and p=reject?
p=none is monitoring mode: failing emails are delivered normally and reports are generated. p=quarantine routes failing emails to spam folders: recipients can still find them but they do not reach the inbox. p=reject refuses failing emails at the server level: they never reach the recipient at all. The progression from none to quarantine to reject is the standard rollout path.

Q: What are DMARC aggregate reports and what information do they contain?
Aggregate reports are daily XML reports sent by receiving mail servers to the address in the rua= tag. They contain the source IP addresses that sent email claiming to be from your domain, email volume per source, SPF and DKIM pass and fail results, DMARC pass and fail results, and the disposition applied to failing messages. They give domain owners visibility into their full email sending ecosystem and into active spoofing attempts.

Q: Why should you not jump straight to p=reject?
If any of your legitimate email sources are not properly authenticated, moving to reject will cause those emails to be refused by receiving servers. They will not reach recipients. The monitoring phase using p=none exists to identify all legitimate sending sources and fix any configuration issues before enforcement begins. Skipping this step risks breaking your own email.

Q: What is the pct tag in a DMARC record?
pct= specifies the percentage of failing emails that the DMARC policy applies to. At pct=100 the policy applies to all failing emails. At pct=10 it applies to only 10% of failing emails, chosen at random. It is used during rollout to test the impact of a policy gradually rather than applying it all at once. The end goal for any production environment is pct=100.

Q: What is the difference between the rua and ruf tags in DMARC?
rua= specifies where to send aggregate reports: daily summaries of authentication results across all email from your domain. ruf= specifies where to send forensic reports: immediate, per-message reports sent when specific emails fail DMARC. Forensic reports contain more detail about individual failures but not all receiving servers send them. Aggregate reports are the more important of the two for ongoing monitoring.

Q: What is subdomain policy in DMARC and when would you use it?
The sp= tag sets a separate policy for subdomains of your main domain. For example, if your main policy is p=reject but you want to be more cautious about subdomains because they have more varied email setups, you could set sp=quarantine. If sp= is omitted, the main p= policy applies to subdomains as well. It is useful for organisations that have many subdomains with different email configurations and want to enforce them independently.

Frequently Asked Questions

We already have SPF and DKIM. Do we really need DMARC too?

Yes, and the reason is specific. SPF and DKIM do not check the visible From address your recipients see. An attacker can pass both SPF and DKIM for their own domain while showing your domain in the From header. DMARC's alignment check is what catches this. Without DMARC, your domain can be successfully spoofed to anyone despite having SPF and DKIM in place.

Will setting up DMARC affect our email deliverability?

Not negatively, provided you follow the phased rollout. In fact, having DMARC in place improves deliverability because major providers like Google, Yahoo, and Microsoft now treat it as a signal of domain trustworthiness. Since Microsoft's May 2025 update, not having DMARC is what hurts deliverability.

How long does the monitoring phase need to be?

For most organisations, four to six weeks is sufficient to collect meaningful report data and identify all legitimate sending sources. Larger organisations with complex email ecosystems may need longer. The right time to move to quarantine is when your reports show that all your legitimate email is consistently passing DMARC, not after an arbitrary number of weeks.

Our reports show IP addresses we do not recognise. What does that mean?

It means someone is sending email claiming to be from your domain. This could be a misconfigured third-party service you have forgotten about, or it could be an active spoofing campaign. Check the volume: occasional low-volume failures are often misconfigured services. High-volume failures from unfamiliar IP addresses are more likely to be spoofing attempts. This is exactly the visibility DMARC was designed to provide.

What is a DMARC reporting tool and do we need one?

DMARC aggregate reports arrive as raw XML files. A reporting tool parses them into readable dashboards. You can technically read the raw XML yourself but it is slow and error-prone. Free tools like Postmark DMARC, MXToolbox, and EasyDMARC make the reports genuinely useful without any cost. For most organisations the free tier of any of these is enough.

Does DMARC protect against all phishing?

No. DMARC protects your specific domain from being spoofed in the From header. It does not protect against emails sent from lookalike domains, does not inspect link content, and does not prevent phishing from compromised accounts. It is one layer in a broader defence, and the most important layer for protecting your brand and your domain specifically.

We are a small business. Does DMARC apply to us?

Yes. Smaller organisations are frequently targeted precisely because their email security is weaker. A spoofed email from a small accountancy firm, law practice, or financial adviser can be just as damaging to their clients as one from a large bank. The protocols are free to implement. The time investment is the only cost.

News

In May 2025, Microsoft quietly changed the rules of email. If your domain does not have DMARC published, emails you send to Outlook, Hotmail, and Live addresses are now being routed to junk folders. Full rejection is next.

Google and Yahoo made similar moves in 2024 for bulk senders. The major inbox providers have essentially decided: if you have not published a DMARC record, your email is not trustworthy enough to land in someone's inbox.

And yet, as of early 2026, around 66% of companies still do not have DMARC configured. Of those that do, the vast majority are sitting on a monitoring-only policy that blocks nothing.

This blog explains what DMARC actually is, how it works, what the policy levels mean, and why the window for ignoring it has closed.

Summary

DMARC is the enforcement layer of email authentication. SPF verifies the sending server. DKIM verifies message integrity. DMARC aligns both against the visible From address and lets you decide what happens when they fail.

The three policy levels are not equally useful. p=none is a starting point, not a destination. p=quarantine is a transition. p=reject is the goal.

The Microsoft change in May 2025 removed the last remaining argument for treating DMARC as optional. If your domain sends email to anyone with an Outlook, Hotmail, or Live address and you do not have DMARC published, your emails are already going to junk. Full rejection is coming.

The good news is that DMARC is not complicated to implement. It requires SPF and DKIM to be set up first, a monitoring phase to understand your email ecosystem, and a methodical progression through the policy levels. Most organisations can reach p=reject within three months.

The bad news is that two thirds of companies have not started yet.

DMARC ties SPF and DKIM together and gives your email authentication real teeth. The next step is understanding what happens to threats that pass all three checks — and why link-level inspection is the layer that catches them: What is Email Sandboxing? How Links Get Tested Before You Click Them

Related reading:

• Email Authentication Explained: SPF, DKIM, DMARC and Why All Three Matter
• What is SPF? The Sender Policy Framework Explained in Plain English
• What is DKIM? How Email Signatures Prove Your Messages Are Genuine