

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)
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:
- Publishing an SPF record that includes every service authorized to send email as your domain
- Configuring DKIM signing for every email source
- Publishing a DMARC policy
- Monitoring DMARC reports to identify legitimate senders you missed
- 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 Level | Average Inbox Rate |
|---|---|
| No authentication | 62% |
| SPF only | 74% |
| SPF + DKIM | 83% |
| 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:
- Add your domain
- Copy these DNS records to your provider
- We verify and monitor automatically
- 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.
Sources & References
Related Posts

From 78% to 99.5% Inbox Placement. One SaaS Team's Email Fix.
How a B2B SaaS sending 2M transactional emails per month went from 78% inbox placement to 99.5% in 6 weeks by fixing authentication, IP reputation, and sending practices.

Your Developers Are Already Using AI Tools You Do Not Know About
Shadow AI is the new shadow IT. Developers are using ChatGPT, Copilot, and Claude without oversight. Blocking them is not the answer. Here is a governance framework that actually works.

AI Security in 2026: 77% of Companies Have No Policy. That is a Problem.
Most enterprises have deployed AI without any security policy. Here is what a minimal AI security framework looks like and why you need one before August.
YOUR AGENTS DESERVE
REAL INFRASTRUCTURE.
START BUILDING AGENTS THAT DO REAL WORK.