Who Is Email Security For?

Email has a security stack. SPF, DKIM, DMARC, BIMI, spam filtering – decades of standards work and infrastructure investment. Ask one question of each layer and a pattern emerges that I think explains a lot about the state of email today:

Who is this layer designed to protect?

Authentication protects brands

SPF verifies that a mail server is authorized to send for a domain. DKIM cryptographically signs messages so tampering is detectable. DMARC ties the two to the visible From address and lets domain owners publish a policy for failures.

All three answer the same question: is this message really from the domain it claims? That is a question about the sender’s identity. The beneficiary is the domain owner – the brand whose name would otherwise be spoofed. These are anti-counterfeiting measures, and they are good ones.

Here is what none of them ask: what is this message doing to the person who receives it? A fully authenticated email – SPF pass, DKIM pass, DMARC aligned – can carry a tracking pixel, a dozen per-recipient rewritten links, hidden identifiers in its headers, and fingerprints designed to survive into your replies. The stack waves it through with every green check it has.

Authentication tells you the surveillance is genuine. It does not make it less surveillance.

DMARC’s bar was set low on purpose – mostly

DMARC has an enforcement dial: p=none (just report), p=quarantine, p=reject. The protection only exists at enforcement. At p=none, DMARC observes spoofing and files a report about it.

When Gmail and Yahoo finally required DMARC for bulk senders in 2024 – the biggest compliance event in email authentication’s history – the requirement was p=none. The minimum, non-enforcing mode. The companies with the power to set the bar set it at the level that changes nothing about delivery.

To be fair, some of this caution is engineering reality rather than choice. Strict DMARC genuinely breaks legitimate mail forwarding and mailing lists – a problem large enough that another standard, ARC, exists to patch it. Incremental deployment on a fifty-year-old protocol has real costs, and breaking grandma’s church newsletter to stop spoofing is a hard trade to sell.

But there is a sharper irony that is harder to excuse. The spoofing that actually fools people doesn’t forge the domain – it forges the display name, because that is all most people see. Mail clients, built by the same handful of companies that govern the standards, routinely hide the address behind the display name, especially on mobile. The stack rigorously authenticates a field the interface conceals, while the field the interface displays is authenticated by nothing at all.

And when the gatekeepers did extend authentication toward something users can see, the result was BIMI: display the sender’s logo in the inbox, available to brands who purchase a verified mark certificate. The newest layer of the email trust stack is a paid brand-marketing feature.

The one layer that protects you is a black box

Spam filtering is the genuine exception – it exists to protect recipients, and it works far better than it did twenty years ago. It is also the only layer of the stack that is not an open standard. It is proprietary, unexplainable, and unappealable, operated by the same few companies that run the dominant mailbox services.

That arrangement is worth sitting with. The open, standardized layers protect senders. The layer that protects you is a trade secret – and it doubles as a competitive moat, because a new mail provider can implement every open standard perfectly and still can’t replicate twenty years of proprietary reputation data. Recipient protection, as currently built, is also the gatekeepers’ market position.

What the black box optimizes for is also narrower than “protecting you.” It removes mail you don’t want. It says nothing about what the mail you DO want is doing – the tracking, the fingerprinting, the per-recipient identifiers. Wanted email is presumed safe, and the entire commercial email industry operates inside that presumption.

The envelope is the product

There is a final layer below all of this, and it has no protection at all: the metadata. Who emailed whom, when, how often, in reply to what. Message identifiers that thread conversations together. Even end-to-end encrypted email exposes all of it – encryption seals the letter, not the envelope.

Legally, this is by design. The tradition that treats the outside of the envelope as fair game – formalized in the third-party doctrine – means metadata enjoys far weaker protection than content nearly everywhere. The law protects the letter. The economy, increasingly, monetizes the envelope.

For most of email’s history this data was too vast to exploit. That defense is gone. Graph processing is cheap, identity resolution is a commercial industry, and the value of knowing who is connected to whom keeps rising. A sender who embeds per-recipient identifiers in messages can recognize those identifiers when they come back in replies – mapping who talks to whom in a group without ever seeing an address. Whether anyone is running that analysis at scale today is unknowable from the outside, which is precisely the problem: it would be invisible, it is technically trivial, and nothing in the stack prevents it.

What recipient-side security would look like

Run the thought experiment: design an email security layer whose only beneficiary is the person receiving the mail. It would look nothing like the existing stack.

It would remove tracking content before delivery, the way virus scanning removes malware – unconditionally, not as a client-side preference. It would strip the per-recipient identifiers from links. It would replace sender-issued message identifiers so reply chains can’t be mapped. It would treat the recipient’s address itself as the asset to protect, because that address is now the join key of the data economy. And it would do all of this at the relay layer, where the message can be taken apart and rebuilt – because no client plugin can unsend a signal that fired the moment the message rendered.

That is the layer we have been building at EMail Parrot. Not because the existing stack is useless – authentication and spam filtering solve real problems – but because every layer of that stack was built to answer someone else’s question. Sender authenticity matters. Inbox cleanliness matters. But somebody should be working for the person who opens the mail.

Regulators, particularly in the EU, are beginning to ask versions of this question – treating addresses as personal data, raising security baselines, scrutinizing the data brokers downstream of all this. That pressure helps. But the honest summary of email security in 2026 is still this: the stack authenticates the envelope, filters the obvious junk, and leaves you alone with whatever the genuine, verified, reputable sender decided to do to you.

Somebody should be on your side of the envelope.