How DKIM signatures make email verification possible

Billions of emails are sent every day, and virtually all of them carry a cryptographic proof that most people never notice. It is called a DKIM signature, and it has been quietly running in the background of email infrastructure for nearly two decades. Originally designed to fight spam and phishing, DKIM creates something far more powerful than its inventors intended: a chain of cryptographic trust from the sending organization to the email content itself.

At Burnt, we build on top of this existing infrastructure to turn emails into a verification channel. Here is how it works.

What is DKIM?

DKIM stands for DomainKeys Identified Mail. It is an email authentication standard that allows a sending mail server to attach a digital signature to every outgoing message. The mechanics are rooted in public-key cryptography, the same mathematical foundation that secures HTTPS, banking systems, and blockchain networks.

Here is the process in simplified terms:

• Key generation. The sending domain (say, united.com) generates a public-private key pair. The private key is kept secret on the mail server. The public key is published as a DNS TXT record, accessible to anyone.
• Signing. When the mail server sends an email, it computes a cryptographic hash of specified email headers (From, Subject, Date, etc.) and the body content. It then signs that hash with the domain's private key. The resulting signature is attached to the email as a DKIM-Signature header.
• Verification. When the recipient's mail server receives the email, it looks up the sender's public key via DNS, recomputes the hash of the same headers and body, and checks it against the signature. If the signature is valid, two things are proven: the email came from the claimed domain, and the signed content has not been altered in transit.

This process runs automatically on virtually every email sent by major providers — Gmail, Outlook, Yahoo, and the mail servers of corporations, government agencies, airlines, banks, and payroll systems worldwide.

DKIM in practice

To make this concrete, consider a real-world example. United Airlines sends a booking confirmation to a customer. Here is what happens behind the scenes:

United's mail server composes the email with the booking details — flight number, dates, passenger name, confirmation code. Before sending, the server takes the relevant headers and the body content and computes a SHA-256 hash. It then signs that hash with United's private DKIM key (the one associated with the selector published in united.com's DNS records).

The signed email travels through the internet. The recipient's mail provider (say, Gmail) receives it, looks up the DKIM public key from united.com's DNS, and verifies the signature. If it checks out, Gmail knows with mathematical certainty that the email was sent by a server authorized by united.com and that no one has tampered with the content.

This verification happens silently on every email. Most users never see it. But the signature is there, embedded in the email headers, and it can be independently verified by anyone with access to the email and the sender's public DNS records.

From spam prevention to verification

DKIM was designed to solve a narrow problem: help mail servers distinguish legitimate senders from spammers and phishers. It was never intended as a general-purpose verification mechanism. But the cryptographic properties it provides are more broadly useful than its creators envisioned.

Consider what a valid DKIM signature actually proves:

• The email was sent by a server authorized to send on behalf of that domain.
• The signed content (headers and body) has not been modified since it was sent.
• The signature can be verified by any third party using the publicly available DNS key.

This creates a chain of trust from the sending organization to the email content. If you receive an email from united.com with a valid DKIM signature, you have a cryptographic guarantee that United Airlines (or at least their authorized mail infrastructure) produced that exact content. No one intercepted it and changed the flight date. No one fabricated it from scratch.

A DKIM-signed email is, in effect, a cryptographically certified statement from the sending organization. The infrastructure to create and verify these statements already exists, runs at global scale, and requires no new adoption.

Selective disclosure

Here is where it gets interesting for verification use cases. If Burnt can prove that an email is authentic — that it genuinely came from a specific domain and has not been tampered with — then the facts contained in that email are also proven authentic.

The key insight is that you do not need to reveal the entire email to prove a specific fact from it. Burnt's approach works like this:

• The user grants read access to a specific email (or a narrow set of emails) through a standard OAuth flow.
• Burnt retrieves the email and verifies the DKIM signature against the sender's public key.
• If the signature is valid, Burnt extracts only the specific fact that was requested — a flight date, a pay amount, a membership tier, a booking confirmation.
• The verified fact is returned. The email content is processed in memory and immediately discarded. No email content is stored, logged, or transmitted.

The result is a verified signal — not a document, not a screenshot, not a forwarded email, but a cryptographically backed confirmation of a specific fact. Here is what the output looks like:

The email_content field is always null. The full email is never part of the output. Only the specific, verified fact is returned.

Why this matters

Email verification through DKIM has a unique structural advantage over other verification methods: coverage.

Building API integrations with data sources is slow and expensive. Each new source requires a partnership, a technical integration, legal agreements, and ongoing maintenance. The number of sources you can connect to is always limited by the number of integrations you can build and maintain.

Email takes a fundamentally different approach. Almost every service sends transactional emails — booking confirmations, pay notifications, account statements, purchase receipts, membership updates, shipping notifications. And virtually all of these emails are DKIM-signed by the sending domain. This means that verification coverage is essentially universal. Any organization that sends email (which is nearly all of them) is already producing cryptographically verifiable statements about their interactions with users.

No partnerships are needed. No API integrations are required. No data-sharing agreements need to be negotiated. The verification infrastructure is already running, at scale, across the entire internet. It has been running for almost twenty years.

The trust model

It is worth noting what DKIM does and does not prove. DKIM proves that the email was sent by an authorized server for that domain and that the content has not been modified. It does not prove that the content itself is accurate — only that the sending organization produced it.

In practice, this is sufficient for most verification use cases. If United Airlines sends a booking confirmation, you can trust that the booking exists because United has no incentive to fabricate booking confirmations. If a payroll provider sends a pay notification, the pay event is real because the provider would not generate a fraudulent notification. The trust is in the institution, and DKIM provides the cryptographic link between the institution and the statement.

The infrastructure for email-based verification has existed for decades. Billions of DKIM signatures are generated and verified every day. The protocol is mature, universally adopted, and cryptographically sound. It was built to stop spam. It turns out it also provides the foundation for a verification system that reaches virtually every data source on the internet.

It just needed someone to build on top of it.