You’re Outsourcing Risk That’s Easy to Reduce
Having worked in the world of email filtering for more than 15 years, I know a thing or two about the proper email configuration settings necessary to dramatically reduce SPAM and phishing. Over time, new configuration standards have been improved to the point that it’s possible to drastically reduce your exposure simply by configuring your email service settings appropriately.
Unfortunately, many organizations don’t take the time to do this correctly or don’t have the expertise needed to configure a few simple settings. The email authentication stack (SPF, DKIM, DMARC, DANE, DNSSEC and MTA-STS) is unglamorous, technically accessible, and wildly under-deployed. Instead, companies simply outsource the risk to a third-party filtering company hoping that will solve the problems they are facing. That doesn’t typically work well in the end.
Filtering is reactive – meaning you are acting after the enemy is already in the door. Authentication is a preventative measure that keeps the enemy outside the door. Your third-party filter doesn’t stop your domain from being weaponized against others or your own users
Here’s The Problem
The statistics back up the fact that as of 2024, 84% of domains exchanging email on the Internet are completely misconfigured and have no published DMARC record. Of the ~16% that attempted implementation, 7.6% have invalid records — only ~8% of domains have valid DMARC in place. (Validity, Nov 2024)
Among the top 1 million domains, 57.2% of those with DMARC use p=none — meaning failed DMARC results in normal delivery anyway. Effective DMARC protection covers roughly 14% of even the most prominent domains. (dmarcchecker.app, 2024)
86.62% of global domains still lack adequate email authentication protection — an improvement of only 4.46% in all of 2024. (Red Sift, Dec 2024)
The average cost of a phishing-related breach hit $4.88 million in 2025. AI is accelerating the threat: a phishing email that once took 16 hours to craft can now be generated in 5 minutes. (PowerDMARC, 2025)
The kicker: In 2024, 48% of healthcare organizations and 73% of financial institutions reported phishing attacks, while 61% of healthcare organizations lack proper protection against data breaches. (Red Sift, 2025)
The Stack — What Each Protocol Actually Does
Let’s look at the email authentication stack and how we can easily configure for our domains.
SPF — Sender Policy Framework
SPF Declares which mail servers are authorized to send on behalf of your domain. This list should be complete. The data lives in DNS as a TXT record; the receiving MTA checks it. The gotcha: SPF only validates the envelope sender (Return-Path), not the “From” header the user sees. It can fail for many reasons including too many DNS lookups (10-lookup hard limit), overly permissive ~all vs. hard fail -all, forgotten subdomains or the record length can exceed 256 character. There are solutions for building extended SPF records. These records get long because many organizations use third-party services to send email on behalf of their domain and these outside third-parties must be listed in your domain’s SPF record. Most businesses fail to track this and wonder why third-party app email deliverability is problematic.
39% of the top 1 million domains lack an SPF record entirely — and 77% of those domains also lack MX records, meaning orgs are leaving unsigned domains open to spoofing even when they don’t actively send email. (dmarcchecker.app, 2024)
DKIM — DomainKeys Identified Mail
DKIM adds a cryptographic signature to outgoing mail that the receiving server validates against a public key in your DNS. This survives forwarding better than SPF and attaches authentication to the message itself. It can fail due to weak key length (use 2048-bit minimum), key rotation neglect, misconfigured ESPs that strip or break signatures and failure of intermediary servers to implement ARC (Authenticated Received Chain), which preserves authentication results across forwarding hops. DKIM alone doesn’t stop spoofing, it needs DMARC to close the loop
DMARC — Domain-based Message Authentication, Reporting & Conformance
DMARC Ties SPF and DKIM together and gives the receiving server instructions on what to do with failures based on the selected policy. There are three policies: p=none (monitor only), p=quarantine, p=reject (the only one that actually stops spoofed mail). DMARC also generates aggregate (rua) and forensic (ruf) reports — a largely untapped source of visibility into who’s sending as your domain.
Organizations deploy DMARC and stop at p=none, and declare victory — but p=none is a monitoring mode, not a control! 61% of organizations with DMARC will only upgrade their policy if required by regulatory or business pressure. Another 13% have no plans to strengthen their policy at all. (PowerDMARC, 2025)
Effective March 31, 2025, PCI DSS v4.0 mandates that organizations handling payment card data implement DMARC policies set to quarantine or reject. (Red Sift, 2025)
Want proof DMARC works? DMARC enforcement contributed to approximately 265 billion fewer unauthenticated messages sent in 2024. Meaning enforcement, not just adoption, drives outcomes. (PowerDMARC, 2025)
DANE — DNS-based Authentication of Named Entities
DANE is the least-deployed of the six, and the most misunderstood. DANE binds your mail server’s TLS certificate to your domain via DNSSEC using a TLSA record. This addresses the gap DMARC doesn’t cover: transport-layer attacks (TLS downgrade, man-in-the-middle on the wire). This requires DNSSEC as a prerequisite — which is itself underdeployed. Only 4% of .com domains use DNSSEC as of early 2025, though 35% of internet users rely on resolvers that validate DNSSEC signatures. (dmarcchecker.app, Feb 2025)
In a rigorous national survey (Netherlands, Sept 2025), only 14% of domains had DANE configured and 6% had MTA-STS. One in three domains had no transport protection standard at all — and dozens of domains regressed within two months due to expired certificates or DNS misconfigurations. (Zivver, Sept 2025)
Microsoft announced general availability of inbound SMTP DANE with DNSSEC for Exchange Online, with plans to make outbound SMTP DANE mandatory per-tenant in Q4 2025 — the first major cloud mail platform to push DANE into mainstream enterprise environments. (Microsoft, 2024)
MTA-STS – Mail Transfer Agent Strict Transport Security
MTA-STS is a standard that allows a domain to declare that its mail servers support TLS and that sending servers must refuse to deliver mail if a secure connection can’t be established (RFC 8461).
The problem it solves: Standard SMTP uses opportunistic TLS meaning it tries to encrypt the connection but will happily fall back to plaintext if TLS fails or is stripped by an attacker. This downgrade attack means messages in transit can be intercepted and read in the clear.
How it works: You publish a DNS TXT record at _mta-sts.yourdomain.com signaling that a policy exists, then host the actual policy file over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. That file lists your authorized mail servers and sets the enforcement mode. Sending servers that support MTA-STS fetch the policy over HTTPS and refuse delivery unless a valid TLS connection to one of your listed servers can be established.
The three policy modes mirror DMARC’s progression: testing (violations reported but mail still delivered), enforce (TLS required — failures result in rejection), and none (policy withdrawn). Start in testing mode, monitor your TLS-RPT reports, then move to enforce once you’ve confirmed clean delivery.
MTA-STS pairs with TLS-RPT (SMTP TLS Reporting, RFC 8460), which delivers daily reports on TLS connection failures to your domain — the equivalent of DMARC’s rua reports for transport security.
Compared to DANE, MTA-STS is easier to deploy since it relies on HTTPS and the existing CA certificate trust model rather than requiring DNSSEC. It’s less cryptographically robust for that same reason, but it’s a solid interim step and a meaningful control in its own right. The general recommendation is DANE where DNSSEC is available, MTA-STS everywhere else.
The Dirty Secret — Why Orgs Don’t Do This
What’s going on here? With these tools available, every domain admin should be configuring their DNS records to these simple standards to lock down the front door and prevent the entry of most malicious emails. But it doesn’t happen. Why? Here are some potential reasons:
- “We have a third-party filter” (Proofpoint, Mimecast, etc.) — the conflation of filtering and authentication
- IT/security team capacity: DNS-level configuration feels like infrastructure work, not “security” work
- Fear of breaking mail flow: the p=reject hesitation is real but manageable with proper DMARC reporting first
- Lack of ownership: who manages DNS? IT. Who owns email security? InfoSec. Who’s responsible for the gap? Nobody.
- Shadow IT sending: SaaS tools, marketing platforms, HR systems all sending as your domain — DMARC reports expose this
- The uncomfortable truth: you may be so focused on detecting inbound threats that you’ve left your domain open as an attack tool against others
A Practical Implementation Process
So how can we make positive changes in our organizations to limit inbound email access?
- Select the right email service: Be sure that the service provider you use as your primary inbound and outbound email provider supports all these security features. Many don’t so check before you buy or migrate to a service that does.
- Then enable visibility: deploy SPF and DKIM, then DMARC at p=none with reporting enabled — understand who and what is sending as your domain before you enforce anything
- Clean up before locking down: identify all authorized senders (ESPs, SaaS platforms, HRIS, CRM, ticketing tools), ensure they’re properly DMARC-aligned and included in your SPF record
- Move to enforcement: quarantine first, monitor for false positives, advance to reject — typically a 60–90 day process if disciplined
- Add transport security: DNSSEC-sign your domain, then publish TLSA records for DANE; if your DNS provider or MTA doesn’t support DANE yet, MTA-STS is a viable interim step
- Don’t forget: subdomain policy (sp= tag in DMARC) and parking non-sending domains with v=spf1 -all and p=reject
- Tooling worth naming: MXToolbox, DMARC Analyzer, Valimail Monitor, dmarcian, Mail Hardener — most offer free tiers for initial assessment
Doing These Steps is a Baseline, Not a Differentiator
These protocols don’t require a budget line item, a vendor contract, or executive sign-off, they require ongoing attention to manage and tune. Remember, a spam filter catches threats in your inbox. Authentication prevents your domain from being the threat in someone else’s inbox and prevents eavesdropping of email flow. The organizations getting phished aren’t all lacking budget or tools. They simply haven’t implemented the best practice configurations and are simply lacking DNS records.
Once your organization has completed these steps, then you can be confident that a SPAM & URL filtering service will provide greater value.
“If your email security strategy lives entirely in a vendor dashboard, you haven’t secured email. You’ve subscribed to the illusion of it.”
Optional Standard
An optional standard called BIMI (Brand Indicators for Message Identification) is the reward for reaching p=reject — logo display in Gmail and Apple Mail as a visible trust signal; easy win for brand teams to get behind enforcement. This is a bit more costly to configure as it requires a specific type of validated certificate.
Call to Action
Run your critical domains through a free DMARC checker (MXToolbox, dmarcian, or PowerDMARC) before you finish reading — the results may surprise you. If you need a better way to track your email configuration setting, I recommend Mail Hardener.
Let me know your thoughts or hit me up if you need help getting things set up correctly or have questions. Remember – taking time to configure things correctly the first time one of the highest-ROI controls available to you.
Key Data Sources
- Validity — DMARC Adoption: A Deep Dive into the Current State of Email Authentication (Feb 2025)
- Red Sift — Achieving DMARC Adoption: A Global Approach to Email Security (Jan 2026)
- PowerDMARC — Email Phishing and DMARC Statistics: 2026 Security Trends
- dmarcchecker.app — SPF, DKIM, and DMARC in 2024: Analyzing the Top 1M Domains
- Microsoft — Announcing General Availability of Inbound SMTP DANE with DNSSEC for Exchange Online (2024)
- Zivver — Use of Email Security Standards in the Netherlands (September 2025): only 14% DANE, 6% MTA-STS
- dmarcchecker.app — DNSSEC and Why It Matters for Email Security (Feb 2025)
#EmailSecurity #DMARC #DKIM #SPF #DANE #Cybersecurity #CISO #InfoSec #PhishingPrevention #EmailAuthentication #SecurityLeadership #CyberDefense #ZeroTrust #RiskManagement #CyberAwareness
