Industry Insights
8 min read

Only 16% of Domains Have DMARC. Yours Probably Does Not Either.

Email authentication adoption remains shockingly low despite enforcement by Google and Yahoo. Here is the current landscape and what needs to change.

Transactional Team
Jan 16, 2026
8 min read
Share
Only 16% of Domains Have DMARC. Yours Probably Does Not Either.

The Numbers Are Embarrassing

Domain configuration data from across the industry shows that the numbers have improved since Google and Yahoo started enforcing authentication in 2024, but they are still concerning.

Here is what the data shows across millions of domains in early 2026:

  • SPF adoption: ~73% of domains have some SPF record
  • DKIM adoption: ~52% of domains sending email use DKIM signing
  • DMARC adoption: ~16% of domains have a DMARC policy
  • DMARC at enforcement (p=quarantine or p=reject): ~6% of domains

That last number is the one that matters. Only 6% of domains are actually using DMARC to protect against spoofing. The other 10% have DMARC records set to p=none, which means they are monitoring but not enforcing. It is the email equivalent of installing a security camera but never looking at the footage.

Email Authentication Adoption (2026)

16%DMARC Adoption
SPF Only21
SPF + DKIM36
DMARC (p=none)10
DMARC (enforced)6
No Auth27

Why This Matters More Than Ever

Email spoofing is not a theoretical threat. It is the primary vector for business email compromise (BEC), which cost organizations $2.9 billion in 2023 according to the FBI's Internet Crime Complaint Center. An attacker who can send email that appears to come from your domain can:

  • Trick your customers into sending payments to fraudulent accounts
  • Phish your employees with messages that look internal
  • Damage your brand reputation
  • Trigger fraud investigations that freeze your legitimate email

DMARC is the only mechanism that tells receiving mail servers what to do when authentication fails. Without it, spoofed emails from your domain will be delivered to inboxes.

Why Adoption Is So Low

The reasons for low adoption fall into predictable categories.

"We do not know what DMARC is"

This is more common than you would think, even among technical teams. Email authentication is not covered in most CS curricula. Developers learn HTTP authentication, OAuth, JWT tokens, but not SPF, DKIM, and DMARC. It is infrastructure that somebody else is supposed to handle, except nobody does.

"It is too complex to implement"

This one has some truth to it. Getting DMARC right requires:

  1. Publishing an SPF record that includes every service authorized to send email as your domain
  2. Configuring DKIM signing for every email source
  3. Publishing a DMARC policy
  4. Monitoring DMARC reports to identify legitimate senders you missed
  5. Gradually moving from p=none to p=quarantine to p=reject

Step 4 is where most companies stall. DMARC reports are XML files sent by receiving mail servers. They are dense, voluminous, and difficult to parse. Without tooling, nobody reads them.

"We have too many email sources"

A typical mid-size company sends email from:

  • Their main email server (Google Workspace, Microsoft 365)
  • Their transactional email provider (that is us)
  • Their marketing email platform (Mailchimp, HubSpot)
  • Their CRM (Salesforce)
  • Their support platform
  • Various SaaS tools that send notifications
  • Legacy systems nobody remembers

Getting all of these aligned with SPF and DKIM is a project, not a task. And companies are afraid of breaking legitimate email by enforcing DMARC before everything is configured correctly.

"We tried and broke things"

This is the saddest category. A company publishes a DMARC record with p=reject, discovers that some critical system was not included in their SPF record, and suddenly their order confirmations or password reset emails are being rejected. They panic, remove the DMARC record, and never try again.

Google and Yahoo Changed the Game

In February 2024, Google and Yahoo started enforcing email authentication requirements for bulk senders (5,000+ messages per day to their users). The requirements:

  • SPF or DKIM authentication (at least one)
  • DMARC policy published (even p=none counts)
  • ARC headers for forwarded messages
  • One-click unsubscribe for marketing messages

This was the single biggest driver of DMARC adoption in the protocol's history. Overnight, companies that had ignored email authentication for years were scrambling to publish DMARC records. The DMARC adoption rate jumped from roughly 8% to 16% in 2024-2025.

But there is a problem. Google and Yahoo only require p=none, which provides monitoring but no protection. Most companies published their DMARC record, saw that their emails were still being delivered, and stopped there. They never moved to enforcement.

What Is Coming Next

Google has signaled that future requirements will tighten. The industry expectation is:

  • 2026-2027: DMARC at p=quarantine required for bulk senders
  • 2027-2028: Full DMARC enforcement (p=reject) required

Microsoft is also moving in this direction. Outlook and Office 365 have started flagging emails from domains without DMARC. It is not enforcement yet, but the writing is on the wall.

The Deliverability Impact

Even without enforcement, DMARC affects deliverability today. Here is what platform data shows:

Inbox Placement Rates

Authentication LevelAverage Inbox Rate
No authentication62%
SPF only74%
SPF + DKIM83%
SPF + DKIM + DMARC (p=none)87%
SPF + DKIM + DMARC (p=quarantine)91%
SPF + DKIM + DMARC (p=reject)94%

The difference between no authentication and full DMARC enforcement is over 30 percentage points of inbox placement. For a company sending 100,000 transactional emails per month, that is 30,000 emails that reach the inbox instead of spam.

Sender Reputation

Mail providers use authentication signals as inputs to their reputation algorithms. Domains with proper authentication build reputation faster, recover from issues more quickly, and are less likely to be affected by shared IP reputation problems.

What the Industry Needs to Do

Email Providers Need to Make It Easier

The biggest failure is on our side, the email service providers. Setting up authentication should not require reading RFCs and understanding DNS record syntax. It should be:

  1. Add your domain
  2. Copy these DNS records to your provider
  3. We verify and monitor automatically
  4. We tell you when you are ready to enforce

At Transactional, this is exactly what we do. Our email platform handles DKIM signing automatically, provides SPF records with correct includes, and monitors DMARC reports on your behalf. We will tell you when all your email sources are aligned and it is safe to move to enforcement.

Companies Need a DMARC Project, Not a DMARC Task

Moving to DMARC enforcement is not something one person does in an afternoon. It requires:

Phase 1 - Discovery (2-4 weeks): Publish DMARC at p=none. Collect reports. Identify all legitimate email sources. This is the foundation. Do not skip it.

Phase 2 - Alignment (4-8 weeks): Configure SPF and DKIM for every identified sender. Verify alignment in DMARC reports. Fix any services that are failing authentication.

Phase 3 - Quarantine (4 weeks): Move to p=quarantine. Monitor for delivery issues. This catches problems without hard-failing email. Set pct=10 initially and ramp up.

Phase 4 - Enforcement (2 weeks): Move to p=reject. You are now protected against domain spoofing. Continue monitoring.

Total timeline: 3-4 months for a typical organization. It is not trivial, but it is not years of work either. The main cost is attention, not engineering effort.

DNS Providers Need Better Tooling

Most DNS management interfaces treat SPF, DKIM, and DMARC records as generic TXT records. They do not validate syntax, warn about common mistakes, or provide guidance. A DNS provider that understood email authentication and could guide users through the process would be a significant improvement.

Common Mistakes to Avoid

Flattening SPF records incorrectly: SPF has a 10-lookup limit. When you exceed it, the entire record fails. Tools that "flatten" SPF records by resolving includes into IP addresses create brittle records that break when providers change their IP ranges.

Using too many DKIM selectors: Each email source needs its own DKIM selector. But some providers require you to manage the keys yourself, leading to key rotation failures and expired signatures.

Setting DMARC to p=reject too early: Without proper monitoring, you will break legitimate email. Always start with p=none, verify your sources, then gradually enforce.

Ignoring subdomain policy: DMARC applies to the exact domain by default. If you send email from subdomains, you need sp= (subdomain policy) in your DMARC record, or separate DMARC records on each subdomain.

Not monitoring after enforcement: DMARC is not set-and-forget. New email sources get added, providers change IP ranges, and configurations drift. Check your DMARC reports monthly at minimum.

The Takeaway

Email authentication is not optional anymore. Google and Yahoo forced the first step. Full enforcement is coming. The 84% of domains without DMARC are on borrowed time.

If you have not started, start today. Publish a DMARC record at p=none. That single DNS change takes five minutes and gives you the data you need to plan your path to enforcement. The emails you send carry your brand, your reputation, and your customers' trust. Protecting them is not a nice-to-have. It is a responsibility.

Written by

Transactional Team

Share
Tags:
email
security
dmarc

YOUR AGENTS DESERVE
REAL INFRASTRUCTURE.

START BUILDING AGENTS THAT DO REAL WORK.

Deploy Your First Agent