Why Spoofhound exists
Email was built on trust.
The internet wasn't.
The protocol that carries your invoices, contracts and password resets was designed in 1982 with no security controls at all — because none seemed necessary. Everything since has been a retrofit. This page explains the problems that history left you with, and exactly how Spoofhound solves them.
A short history of an unsecured protocol
Nobody anticipated what email would become.
Spoofhound helps to secure your emails.
SMTP was written for a small network of institutions that knew each other. No one designing it anticipated billions of messages a day between strangers — or spam, spoofing and phishing as billion-dollar industries. Every safeguard email has today was bolted on decades later, and each one exists to patch a specific hole in that original trust model.
-
1978
The first spam
A marketer emails about 400 ARPANET users an unsolicited product announcement. The reaction is furious — and changes nothing. There is no mechanism to stop the next one.
-
1982
SMTP is standardised (RFC 821)
The protocol still carrying the world’s email is written for a network of a few hundred trusted, mostly academic hosts. Any server can claim any sender address; the From line is just text. No authentication, no encryption, no verification — none of it deemed necessary among colleagues who knew each other.
-
1990s
Email outgrows its assumptions
The internet opens to the public and email becomes its first killer app. The trust model built for hundreds of hosts is now carrying mail between total strangers, and spam industrialises almost immediately — by the early 2000s it is the majority of all email sent.
-
1996
“Phishing” gets its name
Attackers discover the corollary of an unauthenticated From line: mail that claims to be from your bank, your provider, your boss. The word is coined among AOL account thieves; the technique never goes away.
-
2002
STARTTLS (RFC 3207): encryption, opportunistically
Server-to-server mail can now be encrypted — but only if both sides offer it, and delivery still proceeds if negotiation fails. An attacker on the path can simply strip the offer and read the mail. Nobody is told when that happens.
-
2003–2007
SPF and DKIM retrofit authentication
SPF publishes which servers may send for a domain; DKIM adds a cryptographic signature. Both are real progress — and both verify hidden, technical identifiers rather than the From address a human actually reads. A message can pass either while displaying someone else’s domain.
-
2012–2015
DMARC ties it to the From line
DMARC requires SPF or DKIM to align with the visible From domain, lets the owner publish a policy (monitor, quarantine, or reject), and — crucially — makes receivers report back who is sending as the domain. For the first time, a domain owner can see the abuse and switch it off.
-
2018
MTA-STS and TLS-RPT (RFCs 8461/8460) close the encryption gap
MTA-STS lets a domain require verified TLS for inbound mail instead of merely hoping for it; TLS-RPT is its feedback loop — daily reports from senders about every failed or downgraded connection that would otherwise fail silently.
-
2019–2021
BIMI: a visible reward for finishing the job
Brand Indicators for Message Identification puts a domain’s verified logo next to its mail in Gmail, Yahoo, Apple Mail and others — but only for domains that have carried DMARC through to enforcement, with a validated SVG logo and, for most providers, a Verified Mark Certificate proving the brand owns it. For the first time, doing email security properly shows up somewhere everyone can see.
-
2026
DMARCbis (RFC 9989) becomes the standard
DMARC graduates to a full Internet Standard, with sharper guidance: a measured, phased path to enforcement, and policy chosen to fit how a domain is actually used.
Why DMARC
The From line your reader sees is the one that matters.
SPF and DKIM authenticate real things — the sending server, the message signature — but neither is required to match the From address a human actually reads. A phisher can pass both on a domain they own while displaying yours. DMARC closes that gap: it demands that what passed aligns with the visible From domain, and lets you tell every receiver on earth what to do when it doesn't — deliver it, junk it, or refuse it outright.
Just as importantly, DMARC reports. Every major receiver sends the domain owner a daily account of what claimed to be them: which sources, which volumes, what passed, what failed. That reporting is the visibility everything else builds on — you cannot safely enforce a policy against senders you haven't identified, which is why RFC 9989 prescribes a measured, phased path: monitor first, understand every source, then tighten.
Why TLS-RPT
Encryption you can't verify is encryption you don't have.
Mail between servers is encrypted only opportunistically: if the TLS handshake fails, or an attacker in the path quietly strips the offer, the message is sent anyway — in the clear. The sender doesn't know. You don't know. MTA-STS fixes the policy half, letting your domain require verified TLS instead of hoping for it.
TLS-RPT is the half nobody remembers: the feedback loop. Senders report to you, daily, every connection to your domain that failed or downgraded its encryption — which is both your early warning of an active attack and your only way of knowing an MTA-STS policy is working rather than silently bouncing legitimate mail. Without the reports, you're enforcing blind.
Why BIMI
Your logo, only where your mail is proven real.
BIMI is the payoff for everything above: once DMARC is enforced, participating mailbox providers — Gmail, Yahoo, Apple Mail, Fastmail — display your verified logo beside your messages. That's daily brand impressions in the one place your customers reliably look, and a visual cue a phisher can't reproduce, because the logo appears only on mail that passed authentication for your enforced domain.
Getting there has sharp edges: the logo must be a valid SVG Tiny P/S file, most providers require a Verified Mark Certificate proving the brand owns it, and everything — record, logo, certificate expiry — has to stay correct or the logo silently vanishes. Spoofhound monitors all three per domain, and can host the validated logo and certificate for you, so BIMI stays a reward rather than another thing to babysit.
The problems Spoofhound solves
Five problems every domain owner has.
Whether they know it or not.
Criminals send email as your domain
The problem: Invoice fraud, payroll redirection, and phishing aimed at your customers and staff routinely use your exact domain in the From line — because until DMARC is enforced, receivers will deliver it. Business email compromise consistently tops the FBI’s reported cybercrime losses, year after year.
How Spoofhound solves it: Spoofhound baselines every legitimate sending source in your DMARC reports, so a brand-new source failing alignment — the classic spoofing signature — raises an alarm the same day, with a runbook line telling you what it means and what to do. What DMARC does and does not stop →
Your legitimate mail lands in spam — or nowhere
The problem: Google, Yahoo and Microsoft now require authentication (including DMARC for bulk senders) as a condition of delivery. A forgotten marketing platform or a misconfigured SPF record silently costs you inbox placement, and nobody tells you which message failed or why.
How Spoofhound solves it: Every sending identity seen in your reports is inventoried and classified — legitimate, forwarder, misconfigured, or malicious — so you can fix the misconfigured ones and get every real sender passing and aligned before tightening policy.
The evidence exists, but nobody can read it
The problem: DMARC and TLS reports arrive as zipped XML and JSON attachments, per receiver, per day, into a mailbox. The visibility you need is technically already being sent to you — in a form no human being will ever read.
How Spoofhound solves it: Spoofhound ingests and reads them all, every day, and opens to a triage queue of things that actually need a decision — not a wall of charts. A Monday digest summarises the week in sentences.
Enforcement feels too risky to ever finish
The problem: Moving to quarantine or reject is where the protection is — but one wrong move junks your own invoices or payroll. So most domains stall at p=none forever, monitored but unprotected.
How Spoofhound solves it: The enforcement wizard codifies the safe path: a 98% aligned-pass gate over a rolling window plus an all-sources-explained check, with a staged recommendation at each step — the measured progression RFC 9989 itself prescribes.
Mail encryption fails silently
The problem: STARTTLS is opportunistic: if TLS negotiation fails — or an attacker strips it — the mail is delivered anyway, in the clear, and no one is notified. Without MTA-STS and TLS-RPT you cannot know it is happening.
How Spoofhound solves it: Spoofhound grades every domain A–F on transport security from its TLS reports, hosts your MTA-STS policy file (certificate issued and renewed for you), and alerts on failure patterns with severity tiers.
See it on your own domain
The free domain check scores your SPF, DKIM, DMARC, MTA-STS, TLS-RPT and BIMI setup in seconds — no signup, no agent, nothing installed.
How Spoofhound is built
Cloud-first, from the ground up.
Most monitoring tools are traditional applications that happen to run in a data centre — virtual machines and containers that have to be sized, patched and paid for whether anyone is using them or not. Spoofhound isn't. It was built for the cloud from the ground up: no virtual machines, no containers, no racks of servers. It runs as serverless code across a global edge network, close to wherever your reports arrive.
That choice shows up in three places you actually feel. It scales with demand — a day that brings ten times the usual report volume is handled the same as any other, with no capacity to provision. It is separated by design — each jurisdiction is its own self-contained deployment with its own database and region, which is what lets your data stay in the country you choose rather than in one shared system with a country column. And because it costs almost nothing when idle, it is why our pricing looks the way it does: a low per-domain price with every feature included, rather than feature tiers built to recover the cost of servers sitting warm.