Don't Make Your Email Filter Your First Line of Defense – Why organizations keep getting phished when the fix is in the DNS

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 DNS correctly.

Yet most organizations still rely almost entirely on their email filter as the primary — and sometimes only — defense against phishing.

That's backwards.

The DNS Trifecta: SPF, DKIM, DMARC

These three DNS records are the foundation of email authentication. They've been around for years. They're free to configure. And a surprising number of organizations either haven't deployed them or haven't deployed them correctly.

SPF (Sender Policy Framework) specifies which mail servers are authorized to send email on behalf of your domain. A properly configured SPF record tells receiving mail servers to reject — or at least flag — email that claims to be from your domain but comes from an unauthorized server.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outbound messages. This signature allows receiving servers to verify that the message was sent by an authorized sender and wasn't modified in transit.

DMARC (Domain-based Message Authentication, Reporting and Conformance) builds on SPF and DKIM. It tells receiving servers what to do when a message fails authentication checks — quarantine it, reject it, or let it through. It also provides reporting so you can see who is sending email claiming to be from your domain.

The DMARC Enforcement Problem

Here's where most organizations fall short: they deploy DMARC in monitoring mode (p=none) and never advance to enforcement.

Monitoring mode is a great starting point — you need it to understand your mail flow before enforcing policy. But it's a temporary state, not a destination. Without enforcement (p=quarantine or p=reject), DMARC doesn't protect your recipients. It just generates reports.

I've seen organizations that have been "monitoring" for three or four years. That's not a security posture. That's a checkbox.

MTA-STS and DANE

Two newer standards are worth knowing about:

MTA-STS (SMTP MTA Strict Transport Security) enforces that mail is delivered over encrypted connections. It prevents downgrade attacks and interception during transit.

DANE (DNS-Based Authentication of Named Entities) uses DNSSEC to publish information about acceptable TLS certificates, binding your domain's mail delivery to specific cryptographic certificates.

Both require more work to implement than SPF/DKIM/DMARC, but both meaningfully reduce attack surface.

What Your Email Filter Can and Can't Do

Your email filter is good at pattern matching, content analysis, URL scanning, and attachment sandboxing. It's not good at proving that an email actually came from who it claims to be from. That's what authentication is for.

When you rely on your filter alone, you're asking it to catch spoofed messages that could have been blocked before they were ever delivered. You're adding complexity and cost to compensate for a configuration gap that costs nothing to fix.

Start Here

Check your SPF, DKIM, and DMARC records today. Tools like MXToolbox and DMARC Analyzer will show you exactly what you have configured.
If you have DMARC in p=none, set a timeline for moving to p=quarantine and then p=reject. Don't leave it in monitoring mode indefinitely.
Review your DMARC reports. They'll tell you about unauthorized senders using your domain — which is intelligence your security team should have.
Assign ownership. DNS configuration gets neglected because nobody owns it. Make sure someone is accountable for your email authentication posture.

Your email filter is an important layer. But layers work best when the foundation is solid. Fix the DNS first.