Your Email Security May Be Working. Make Sure You Know.

The Email That Never Showed Up

A few weeks ago I was expecting an email authorizing the return of some hardware. Someone had sent a legitimate file to my email address. It never arrived. It wasn’t in Spam, it wasn’t in a promotions tab, and it wasn’t sitting anywhere obvious. It simply wasn’t there.

The obvious question was why? Unfortunately, email isn’t as simple as pressing Send and watching a message appear at the other end. Several systems sit between those two events, and more and more of them check whether a message really is what it claims to be.

I didn’t have the message headers, and I had no access to the mail server logs on either end. That means I can’t tell you exactly what happened to this particular email. What I can do is look at the sending domain’s email authentication setup and see if anything looks off.

It does. And that’s where it gets interesting.

Having SPF, DKIM, and DMARC records in DNS doesn’t mean your email authentication is working the way you think it is.

This post walks through what I found on a real domain, why each piece matters, and what I’d change. It’s a good example of how “security in place” and “security you can see” are two different things.

Throughout this post I’m using a fictional setup: a company called Acme Widgets at acmewidgets.dev. The domain, hostnames, and IP addresses are made up, but the structure of the records and the problems they run into are the same as what I found.

SPF, DKIM, and DMARC in Plain English

If you own a domain and send email from it, you’ve probably run into these three acronyms. You may even have paid someone to set them up. That’s a good thing. Here’s the short version:

• SPF tells receiving mail servers which systems are allowed to send email for your domain.
• DKIM adds a digital signature to outgoing messages, so the receiver can verify the message was authorized by the signing domain and wasn’t altered along the way.
• DMARC ties the two together. It tells the receiving system what to do when a message doesn’t authenticate properly.

DMARC also brings in one more concept, and it’s the one that trips people up: alignment.

Authentication Isn’t Quite Enough

Say an email claims to be from [email protected]. The receiving server checks SPF and finds the message really was sent by a server authorized to send for mailservice.example.net. SPF passes. Great!

Except example.net isn’t acmewidgets.dev. The message authenticated, but that doesn’t prove the owner of acmewidgets.dev authorized it. That’s the gap DMARC closes by checking whether the authenticated domain aligns with the address people actually see in the From line.

The good news is that DMARC only needs one of two paths to work. Either SPF passes and aligns, or DKIM passes and aligns. It doesn’t need both. Keep that in mind, because it’s the reason redundancy matters so much here.

What I Found

The domain has this DMARC policy:

v=DMARC1;p=quarantine;aspf=s;sp=reject

At first glance, that’s not bad. This isn’t a domain that ignored email security. There’s a real policy in place. Let’s break it down:

• p=quarantine tells receivers to treat messages that fail DMARC as suspicious. What that means in practice is up to the receiving system. It doesn’t guarantee the message lands in a Spam folder.
• sp=reject applies a stronger policy to subdomains.
• aspf=s means strict SPF alignment. With relaxed alignment, related domains can still qualify. With strict, the domains have to match exactly.

Strict alignment isn’t inherently bad, but it leaves less room for configuration mistakes, especially when third-party services send mail on your behalf.

Where’s DKIM?

I couldn’t find an obvious DKIM configuration for the domain. That doesn’t prove the mail provider isn’t signing messages somehow, and without real message headers I can’t say either way. But there’s no published DKIM setup that I’d expect to see.

That matters because DKIM is the second path to a DMARC pass. If SPF fails to align, DKIM can still save the message. If DKIM isn’t in play, that safety net is gone. Combine that with strict SPF alignment and any third-party sender that isn’t configured perfectly can cause trouble.

The SPF Record Is Doing a Lot of Work

Here’s the SPF record (with the real hostnames and addresses swapped for made-up ones):

v=spf1 a:mail.acmewidgets.dev ip4:203.0.113.10 ip4:198.51.100.20 ip4:192.0.2.30 include:spf.protection.outlook.com include:_spf.prod.hydra.sophos.com include:sendgrid.net -all

There’s nothing wrong with this record. It’s valid. It’s just busy.

SPF has a limit that’s easy to miss: an evaluation can make a maximum of 10 DNS-querying mechanisms. Things like include, a, mx, ptr, and exists count toward it. Plain ip4 and ip6 entries don’t. Go over 10 and the result becomes a permerror, which is not what you want.

This record uses 9 of the 10. Here’s roughly where they go:

acmewidgets.dev SPF
│
├── a:mail.acmewidgets.dev              1
├── ip4 (x3)                            0
├── include:spf.protection.outlook.com  1
├── include:_spf.prod.hydra.sophos.com  5  (1 + 4 nested regional includes)
├── include:sendgrid.net                2  (1 + 1 nested include)
│
└── Total                               9 / 10

One lookup left means it isn’t broken today. It also means there’s almost no room to grow. Add another service, or have one of your vendors add an include to their own record, and you can cross the line without touching your own DNS. That’s the kind of problem that sits quietly for six months until someone makes a change, with no idea they just broke email authentication.

Adding another include for a new invoicing or newsletter platform, and your SPF alignment check will fail.. and silently in this scenario.

And the Part That Bothers Me Most

The DMARC record has no reporting address. There’s no rua=mailto:... and no ruf=mailto:.... The domain owner isn’t asking receiving mail systems to send anything back.

DMARC isn’t just enforcement. It’s also a monitoring system. Aggregate reports show you which sources are sending mail as your domain, whether SPF and DKIM are passing, whether they align, and what the receiver did about it. Without them, you’re mostly guessing.

Security Without Monitoring

Think of it like a building with good locks and an alarm that’s set up to call the police. Then somebody unplugs the phone. The alarm might still work, but you’d have no idea whether it’s doing its job.

That’s what this domain looks like. It has enforcement (p=quarantine, sp=reject) but no feedback loop. If legitimate email starts failing DMARC, nobody gets told. If an unauthorized system starts sending as the domain, nobody gets told that either.

Does This Explain the Missing Email?

No, and I want to be clear about that. I don’t have the headers from the missing message, the sending server’s logs, or Google’s delivery logs. I can’t honestly say the email disappeared because of DMARC, because there isn’t enough evidence to back that up.

What I can say is that several things here are worth investigating:

• SPF is complex and already uses 9 of 10 available lookups.
• SPF alignment is strict.
• I couldn’t identify an apparent DKIM configuration.
• DMARC has an enforcement policy.
• There’s no rua address, so no aggregate reports.

Any one of these might be harmless on its own. Together, they make this setup worth a closer look.

What I’d Change

1. Confirm DKIM is actually signing outgoing mail. Not just “somebody said it’s set up.” Check the headers of a real message and see the signature.
2. Simplify the SPF record where possible. Nine out of ten isn’t broken, but it’s not much breathing room.
3. Turn on DMARC reporting by adding a rua address, so the domain owner has somewhere to look when something changes.
4. Test real mail flow. DNS records tell you a lot, but not everything. The only way to know whether a message passed SPF, passed DKIM, aligned, and what happened afterward is to look at the message and the logs.

The Bigger Lesson

This isn’t really about one missing email. It’s something I see regularly with small businesses. Someone is told they need SPF, so they add SPF. Someone else says they need DKIM, so that gets added. Then DMARC. Boxes checked, everything looks secure.

Or it could be technical debt. Perhaps this was never set up, or it’s changed over multiple years and unused details haven’t been removed.

Email authentication isn’t a checklist. It’s a system, and systems need to be monitored and maintained. You need to know what’s sending mail for your domain, whether those services are still authorized, whether authentication is passing, and whether the authenticated domains actually line up with the address your customers see.

Where This Leaves You

The worst time to discover a problem is when a customer says, “I was expecting something from you three days ago,” and all you can say is, “I sent it.” So you send it again. And again. If you haven’t figured out why it isn’t getting through, sending it yet again won’t help.

You know you clicked Send. That’s not the same as knowing it arrived. Now you know how to change that!