As AI assistants start reading and acting on email for us, the old question of "did it arrive?" is giving way to "can we prove where it came from?" Fastmail argues SPF, DKIM, and DMARC are following the same path HTTPS did, from best practice to infrastructure. The trend is real, but the trust it promises has limits worth examining.
For most of email's history, spoofing was a problem you could live with. Anyone can type anything into the "From" field, and they always could, but a reasonably alert human caught the tells. A domain with one letter off. A tone of urgency that didn't fit. A request from your CEO that your CEO would never make. The friction of human attention was, in practice, a security layer.
That layer is thinning. Fastmail's recent post on the future of email makes a case that's worth taking seriously: as AI assistants increasingly read, summarize, and act on email for us, the question shifts from whether a message arrives to whether we can actually verify where it came from. An automated agent scanning your inbox for action items doesn't pause to squint at a sender domain. It reads the content, registers the urgency, and proceeds. The human friction that used to catch spoofs is exactly what we're automating away.
The three standards doing the work
Email authentication rests on three interlocking pieces, none of which most users have ever consciously encountered.
SPF (Sender Policy Framework) lets a domain publish a list of servers authorized to send mail on its behalf. The receiving server checks whether the message actually came from one of them.
DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to each message. The receiver uses a public key published in DNS to confirm the message wasn't altered in transit and genuinely originated from the claimed domain.
DMARC ties the two together and adds policy. It tells receiving servers what to do when a message fails the underlying checks: reject it outright, quarantine it, or let it through with a note. It also generates reports back to domain owners about who is sending mail in their name.
Together they're how your inbox can form an opinion about whether the message claiming to be from your bank really came from your bank. Without them, a spoof and a legitimate message are byte-for-byte indistinguishable at the protocol level.
The trajectory looks a lot like HTTPS
The Fastmail framing leans on an analogy that holds up well. In early 2024, Google and Yahoo began requiring bulk senders to have DMARC properly configured as a condition of reliable delivery. Overnight, authentication moved from something senders could deprioritize to a prerequisite for landing in inboxes at all.
That's the HTTPS pattern almost exactly. The padlock in your browser started as a best practice for banks and checkout pages, became an expectation, and is now simply assumed. Most people never learned what TLS does, but they learned that its absence is a warning. Email authentication is on the same path, with the mailbox providers acting as the forcing function the way browsers did when they started flagging plain HTTP as "not secure."
New standards are stacking on top of the foundation. BIMI lets verified senders display their logo directly in supporting inboxes, a visual trust signal aimed squarely at a moment when AI-generated phishing is hard to catch by content alone. There's also active work revisiting DKIM with lessons from the experimental ARC specification, which tries to track and attribute changes as messages pass through mailing lists and forwarders, so filtering systems can blame the right party instead of penalizing an innocent intermediary.
Where the consensus deserves a second look
Here is the part that gets glossed over in the enthusiasm. Authentication confirms domain identity, not intent. This is not a small footnote.
A scammer who registers a convincing look-alike domain, paypa1-secure.com instead of paypal.com, and configures SPF, DKIM, and DMARC correctly will pass every authentication check cleanly. The system will report the message as fully authenticated, because it is. The signature is valid. The sending server is authorized. The domain owner approved the policy. Everything the standards are designed to verify checks out. The message is still a scam.
This matters more, not less, in an AI-mediated inbox. An assistant trained to trust authentication results, or a BIMI logo treated as a trust badge, could plausibly weight a well-configured fraudulent domain higher than a legitimate sender whose DMARC happens to be misconfigured. And misconfiguration is common. Plenty of real organizations, small businesses especially, run imperfect records, break authentication when they route mail through a third-party newsletter tool, or never set up DMARC at all. The forcing function from the big providers improves the median, but it also creates a cliff that legitimate senders fall off of for boring operational reasons.
There's a second tension Fastmail is refreshingly direct about. The whole premise rests on AI assistants acting on inboxes, yet the company says it hasn't integrated AI into your mail and isn't running your messages through a background model. Its MCP server is an opt-in API endpoint you connect to a client of your choosing, with explicit authorization, and nothing changes if you ignore it. So the urgency is partly about a future the author is choosing not to ship by default. That's a defensible position, arguably the right one, but it means the strongest argument for authentication-as-infrastructure is built on a usage pattern much of the industry is racing toward and Fastmail itself is holding at arm's length.
What actually changes
None of this makes authentication optional. Raising the cost and complexity of impersonation is genuinely valuable, and a world where look-alike domains are the main remaining attack is better than one where anyone can spoof your bank's exact address for free. The honest framing is that authentication is a floor, not a ceiling. It answers "is this domain who it claims to be" and leaves "should I trust this domain" entirely open.
For anyone running a domain, the practical takeaways are unglamorous and worth doing anyway. Publish SPF and DKIM, move your DMARC policy from p=none toward quarantine or reject once you've read your reports and confirmed nothing legitimate is failing, and treat the reports as an ongoing monitoring task rather than a one-time setup. For users, the realistic posture is that an authenticated message and a logo in the corner mean less than they look like they mean. They tell you the plumbing is correct. They do not tell you the person on the other end is honest.
Email is not going anywhere. It remains where banks send statements, where every other site sends password resets, and the best predictor of a technology's longevity is how long it has already lasted. The infrastructure underneath it is being quietly hardened for a more automated decade. The useful skepticism is to remember what that hardening does and doesn't buy. Verified origin is real progress. Verified trust is still a human problem, and handing it to an assistant doesn't make it go away.
Comments
Please log in or register to join the discussion