The Record Nobody Checks

Somewhere in your organization right now, there is a DNS record that was created by someone who no longer works there, pointing to a mail server that was decommissioned two years ago, and your DMARC policy is set to "none" because whoever set it up meant to come back and tighten it down once the monitoring looked clean. They never came back.

This is not a hypothetical.

Most organizations treat email authentication like a compliance checkbox. You publish an SPF record. You configure DKIM. You slap a DMARC policy on the domain. You move on. And then the record sits there, slowly drifting out of sync with your actual sending infrastructure, until someone notices because something broke or, worse, because attackers noticed first.

The problem is not that these standards are bad. SPF, DKIM, and DMARC together form a genuinely solid authentication chain. The problem is that organizations treat a living, breathing DNS configuration as a document they file once.

Let me explain why that framing is wrong, and what it costs you.

SPF works by listing the IP addresses and domains authorized to send mail on behalf of your domain. You publish it in DNS as a text record. Sounds simple. Except that over a typical enterprise's lifetime, you add cloud vendors, marketing automation platforms, HR systems, security awareness training tools, transactional email services, and regional business units that all send email on your behalf. Every one of those adds to your sending footprint. SPF has a lookup limit. Hit it, and you fail authentication silently for legitimate mail. Worse, if you use large shared-IP providers and you specify their IP ranges broadly, you have inadvertently authorized every other customer on that shared infrastructure to send mail that looks like it comes from you.

DKIM is more resilient because it ties authentication to a cryptographic signature, not an IP address. Your mail server signs outbound messages with a private key, receivers retrieve your public key from DNS, and they verify the signature. It survives most delivery paths. It does not survive forwarding, which is why DMARC is necessary to make the full system work. DMARC ties SPF and DKIM alignment together and tells receivers what to do when a message fails: monitor, quarantine, or reject.

The policy setting is where organizations stall. "None" means you are collecting data but doing nothing with it. "Quarantine" means suspicious mail goes to spam. "Reject" means it gets dropped. Moving from none to reject requires you to first understand every legitimate mail stream leaving your domain. That analysis is tedious and never quite finished, so organizations sit on "none" for months, then years, watching the reports pile up without acting on them.

I manage email authentication across dozens of agencies and hundreds of thousands of devices. The single most common failure mode is not a misconfigured SPF record. It is a DMARC policy stuck at "none" because no one owns the work of reading the aggregate reports and cleaning up the sending inventory.

Aviation safety culture builds its discipline around one principle: checklists are not optional, and revisiting them is not a sign that you did something wrong the first time. You run the checklist before departure and again before landing. Not because you forgot what the checklist says, but because conditions change between runs. Your DNS is the same. The record you published eighteen months ago was accurate for the infrastructure you had then. It is probably not accurate now.

The fix has three parts, and none of them are technically difficult. They require organizational attention, which is harder.

First, audit your current sending inventory before you touch any policy settings. Pull your DMARC aggregate reports. If you are not receiving them, that itself is a problem. List every source sending mail on behalf of your primary domains. Include the obvious ones, your email gateway and your marketing platform, and the non-obvious ones, your ticketing system, your e-signature vendor, automated reports from your SIEM. For each source, verify that it is covered by your SPF record without blowing through the lookup limit, and that it is signing with DKIM.

Second, designate someone who owns this ongoing. Not as a project with a finish line. As an ongoing operational responsibility. Every time a new SaaS vendor gets onboarded, someone needs to answer two questions: does this vendor send email on our behalf, and if so, are we updating our authentication configuration before they go live? The answer to the first question is "yes" more often than people expect. The second question almost never gets asked at vendor onboarding time.

Third, move your DMARC policy. If you are sitting at "none," you are getting telemetry but you are not protecting anyone. Work through the aggregate reports until you understand your legitimate sending streams, fix the gaps, move to "quarantine" on a subdomain or low-volume domain first, watch what breaks, and then progress to "reject." This process is not fast. It should take months for a large organization. But it has a finish line, and the finish line matters. "Reject" is the only policy that actually stops spoofing.

The underlying trust problem with email is that the protocol was not built with authentication in mind. SMTP predates the threat model we live in now. SPF, DKIM, and DMARC are retrofitted solutions, and retrofits require more ongoing attention than native designs. The fact that DMARC took from 2011 until recently to reach standards-track approval tells you something about how long standards work takes and how much patience the security community has spent dragging email authentication forward.

That history is also a warning. Standards that took fifteen years to formalize are not going to be replaced quickly. Whatever comes next in email authentication, the organizations that understand the current stack deeply will adapt faster than the ones who treated it as a one-time configuration. Knowing why DKIM breaks on forwarding, knowing what DMARC alignment actually checks, knowing how SPF lookup limits work in practice: that knowledge transfers. The next iteration will be different in the specifics but identical in the shape of the problem.

Your domain is your identity on the internet. Someone is probably trying to send mail that impersonates it right now. The question is whether your DNS records reflect your actual infrastructure accurately enough to stop them.

Check the record.