Your Inbox Is a Vault of Cryptographic Proofs

For 15 years, almost every operations engineer who has touched DKIM has thought of it as an inbound thing. A signal in the spam filter pipeline. A pass/fail bit. You set it up so your transactional email gets delivered, you tick the box, you move on.

Agentic commerce inverts the frame. The interesting question isn’t whether the emails you send are signed. It’s that almost every email anyone has ever received from a serious business is signed — and once an AI agent can read someone’s inbox with their consent, those signatures become a vault of cryptographically-verifiable attestations about that person’s entire commercial life.

This post is about that flip. What DKIM actually does, why it’s a near-perfect trust primitive for agent-mediated buyer verification, what it unlocks specifically, and the limits to be honest about.

What DKIM actually is

DKIM is short for DomainKeys Identified Mail — RFC 6376. It was developed in the mid-2000s by Yahoo and Cisco to fight email spoofing. The mechanism is unglamorous and rock-solid:

1. The sending mail server holds a private RSA or Ed25519 key tied to its domain.
2. When it sends an email, it computes a hash of selected headers and the body, signs the hash with the private key, and attaches the signature as a DKIM-Signature header.
3. The signature header names the domain (d=agl.com.au), a key selector (s=2025q3), and the canonical form of what was signed.
4. The corresponding public key is published as a DNS TXT record at <selector>._domainkey.<domain>.
5. Anyone who receives the email can fetch the public key from DNS, recompute the hash, verify the signature, and prove the message was authored by the holder of that domain’s private key — and that it hasn’t been altered in transit.

That last line is the load-bearing one. The signature binds the email to the sending domain’s private key. Forging an email convincingly — with a valid signature that verifies against current DNS — would require either stealing the sender’s private key or breaking RSA. Neither happens at scale.

Why this matters for agentic commerce

Agentic commerce has a structural problem: the agent shows up at a vendor’s negotiate endpoint claiming things about its principal. “My user spends A$170 a month on electricity.” “My user has been with this provider for 18 months.” “My user is an existing customer of yours.” The vendor has no way to verify any of it without the agent producing evidence.

Three obvious options for evidence, all of them inadequate:

• Self-reported claims. Trivial to fake. Useful as a thin signal, but the vendor can’t safely authorise a deep discount against pure self-report. (See Not Every Segment Needs Proof for the cases where self-report is good enough — they exist, but they’re bounded.)
• OAuth into the buyer’s current provider. Heavy. Requires the incumbent vendor to have an API, which most don’t. Requires the buyer to trust the API broker. And it only ever proves a relationship with that one specific incumbent — not the broader pattern across the buyer’s commercial life.
• Document upload. PDFs of bills, screenshots, contracts. The buyer collects them, the agent submits them. Tampering is trivial — PDF metadata is editable, screenshots can be photoshopped — and most receivers have no good verification path. Lots of friction, low cryptographic guarantee.

Now consider what’s sitting in the average person’s inbox. Twelve months of electricity bills from their retailer, each signed by the retailer’s mail server. Two years of credit-card statements, signed by the issuer’s mail server. Six months of SaaS subscription receipts. Hotel confirmations. Insurance renewals. Bank notifications. Gym memberships. Every single one of those messages carries a DKIM signature that ties the message to the sending domain’s private key.

Those signatures were never collected for the buyer. They were collected by the buyer, passively, as a side effect of using the modern internet. They are sitting unused, in place, ready to be presented as evidence.

What DKIM signatures specifically prove

Once you have a DKIM-signed email in hand, what can you actually claim from it? Five useful things:

• Sender identity. The message was sent by whoever controls the private key at <selector>._domainkey.<domain>. For a major provider that’s their corporate mail infrastructure. The domain in the signature is the identity claim.
• Content integrity. The headers and body that were signed have not been altered. Numbers in the receipt, account IDs, line items — all tamper-evident.
• Spend amount. Six monthly bills averaging A$170 prove A$170 of monthly spend with that retailer. The bill subject lines and bodies carry the numbers; the signatures bind them.
• Account tenure. Oldest signed email from a domain to the user’s inbox is a clean lower bound on how long that relationship has existed. Self-reported tenure is unfakable as far back as the inbox goes.
• Behavioral signals. E-billing consent (presence of statement emails), autopay (absence of payment-reminder emails), high-engagement product use (newsletters, feature updates) — all readable from the metadata pattern across the corpus.

Crucially, none of these claims required the sender’s cooperation in the moment. They’re emitted from evidence the sender produced in the past, signed at the time, and saved in the buyer’s inbox. The vendor on the receiving end of the buyer’s agent doesn’t need to call AGL’s API to verify the buyer is an AGL customer — an AGL-signed bill in the inbox already proves it.

How haggl actually uses it

Inside the haggl protocol, every proof a buyer agent submits carries a trust_level. The two relevant tiers for this discussion are:

• dkim_verified — the agent submitted a raw .eml file. haggl’s server-side pipeline parses the DKIM header, fetches the corresponding public key from DNS, recomputes the canonical hash, and verifies the signature against current DNS — with archival fallback for keys that may have rotated since the email was sent. If verification passes, the proof is tagged dkim_verified and forwarded to the vendor agent with the bound payload (sender, date, body, extracted fields).
• unverified — the agent submitted a document (PDF, screenshot, transcribed bill) that the haggl pipeline accepts as evidence but cannot cryptographically authenticate. Useful at lower trust ceilings, useless where deep discounts are at stake.

From the vendor agent’s perspective, by the time a proof tagged dkim_verified arrives, the cryptographic work is done. The agent just reads the bound fields and scores ICP fit — the same way it would score any other piece of evidence, but with the knowledge that this one can’t be a lie.

That trust separation is what lets vendors authorise meaningfully deeper discounts on DKIM-verified proofs than on self-reported claims. The mechanism behind “up to 22% off if you can prove six months of consistent spend” is DKIM. There is no other cheap, passive, cryptographic way to prove that.

Why DKIM beats the alternatives

A useful comparison — how the trust primitives commonly proposed for agentic commerce stack up:

Three properties make DKIM uniquely useful: it’s passive (the evidence accumulates without anyone trying), it’s cross-vendor (every commerce relationship that sends email is in scope, not just the incumbent the buyer is currently with), and it’s already deployed everywhere (the senders all turned it on a decade ago for spam reasons).

The honest limits

DKIM isn’t a panacea, and pretending otherwise sets up worse decisions downstream. Four real limits:

• Some senders don’t sign. Major brands almost always do. Small businesses, legacy mailers, niche vendors sometimes don’t. A trust ladder needs a fallback tier (haggl’s unverified level) for evidence from non-signing senders.
• DKIM proves the SENDER signed, not that the user is the named recipient. A DKIM-signed AGL bill in the buyer’s inbox proves AGL sent the bill. The inference that the buyer is the addressed party requires reading the email’s To: header and trusting that the user controls that mailbox — usually obvious (it’s in their inbox) but worth being explicit about.
• Key rotation. DKIM keys rotate. A signature from 2024 may not verify against today’s DNS if the sender rotated and didn’t keep an archival record. The haggl pipeline handles this by cross-referencing historic DKIM key archives, but the verification window for very old emails is not infinite.
• Privacy. The email body contains the data the agent extracts. Forwarding raw .eml files moves real customer information. Done right, this is a privacy step the user opts into per message. Done wrong, it’s a leak surface. zkTLS-style zero-knowledge attestations are the next step up the trust ladder for cases where the data itself shouldn’t leave the buyer’s environment (see zkTLS Explained).

The mental-model flip

Most engineers who hear the haggl pitch ask “but how do you know the buyer is telling the truth?” The answer is rarely satisfying when given abstractly — “a trust ladder, weighted evidence, server-side verification.” The answer is much more concrete once you actually look at someone’s inbox.

Open it. Search for “invoice” or “statement” or “receipt.” Look at how many distinct domains have sent the buyer a billable message in the last six months. Twenty? Forty? Each of those messages, almost all of them, carries a cryptographic signature binding the message to the sending domain.

That collection — built up passively over years, paid for by no one, sitting untouched until an agent comes along that can read it — is the buyer’s commercial passport. It proves who they bank with, what they spend, what they subscribe to, where they travel, how long they’ve been at each. It does all of this without the buyer having to ask any incumbent for permission, fill out any form, or trust any third party with their credentials.

That’s the unsung primitive. DKIM was built for spam. It turns out to be the cleanest mechanism we have for an agent to prove arbitrary, granular, third-party-attested facts about its principal — passively, cryptographically, and at the speed of a single email parse.

The point

Every other proposed trust mechanism in agentic commerce either requires the incumbent vendor to cooperate (OAuth, open banking), the buyer to upload tamperable artifacts (PDFs), or a slow regulated intermediary (bureaus). DKIM requires nothing from anyone: the senders already signed, the buyer already received, and the signatures already verify against public DNS. The trust is sitting in place. An agent just has to look.

haggl looks. That’s most of why a DKIM-verified proof can unlock 20–30% margin authorisation on a vendor’s ICP segment while a self-reported claim can’t. The cryptography behind that gap is doing very real commercial work.

Related Reading:

• Anatomy of a <meta name="haggl-negotiate"> Tag
• Privacy Without Trust: How haggl.ai Solves the Accountability Dilemma
• zkTLS Explained: How Verified Data Is Changing Agentic Commerce
• Not Every Segment Needs Proof. Here’s When to Skip It.