SPF vs Sender ID: a short history

20 March 2026 · 11 min read

If you have spent any time auditing old DNS zones, you will eventually meet a record that looks almost, but not quite, like SPF. It begins spf2.0/ instead of v=spf1, and it sits in a TXT record next to the SPF policy you actually rely on. That record is Sender ID, a protocol from the mid-2000s that tried to do what SPF does and a bit more, lost the argument, and never really went away. Plenty of zones still carry one because someone added it fifteen years ago following a Microsoft how-to, and nobody has touched it since.

This article is the short history: where Sender ID came from, what it shared with SPF, why it faded, and, most usefully, what you should do when you find an spf2.0/ record today. It is not a generic email-authentication explainer. If you want the modern picture of how authentication actually works, the companion pieces on RFC 7208 and RFC 7489 cover SPF and DMARC properly. Here we are doing archaeology, because understanding the dead branch of the family tree is the fastest way to stop being confused by the records it left behind.

Two protocols, one origin

To understand Sender ID you have to go back to roughly 2003 and 2004, when spam and forgery were drowning email and there was no agreed way to tell whether the server connecting to you had any right to send mail for the domain it claimed.

Several proposals appeared. One was SPF, the work of Meng Weng Wong, which let a domain publish, in DNS, a list of the IP addresses allowed to send mail for it. A separate proposal, Caller ID for E-Mail, came from Microsoft, and it tried to solve a slightly different and arguably harder problem: rather than authorising the SMTP envelope, it wanted to authorise the address a human actually sees in their mail client.

The IETF set up a working group called MARID (MTA Authorization Records in DNS) in 2004 to merge these competing ideas into one standard. The merged result was Sender ID. In practice Sender ID was SPF's syntax and DNS mechanism welded onto Microsoft's idea about which identity to check. That shared parentage is why the two look so alike, and it is the single most important fact to hold on to: Sender ID and SPF are not rivals that happened to resemble each other, they are siblings that share a record format.

MARID itself fell apart in late 2004, mostly over patent and licensing concerns around Microsoft's contributions and disagreement about the core design. Rather than ship a single blessed standard, the IETF published the surviving documents in 2006 as Experimental RFCs, which is the standards-track equivalent of "here it is, use it at your own risk, we are not endorsing it":

RFC 4406 defined Sender ID itself.
RFC 4407 defined the Purported Responsible Address (PRA), the algorithm at the heart of Sender ID.
RFC 4408 defined classic SPF.
RFC 4405 defined the SMTP SUBMITTER extension that Sender ID could use.

SPF later graduated to a proper standard, RFC 7208, in 2014. Sender ID never did. RFC 4406 and 4407 remain Experimental to this day, which tells you most of the story before we even get into the technical detail.

What they shared

The overlap is large, and it is the reason a Sender ID record can masquerade as an SPF record so convincingly.

Both protocols use the same DNS-published, IP-based model. You list the senders allowed for your domain in a TXT record, and a receiving server fetches that record and checks the connecting IP against it. Both use the same mechanisms and the same syntax: ip4, ip6, a, mx, include, all, the four qualifiers (+, -, ~, ?), and the same left-to-right evaluation that stops at the first match. If you can read an SPF record, you can read the mechanism portion of a Sender ID record, because it is the identical grammar.

Critically, Sender ID was designed to consume v=spf1 records. RFC 4406 says that in the absence of a dedicated spf2.0 record, a Sender ID implementation should fall back to evaluating the domain's plain SPF record. This was deliberate: it meant the millions of domains that had already published SPF got Sender ID checking for free, with no new DNS changes. The flip side, which we will come back to, is that this fallback caused real problems.

So a Sender ID record looks like this:

spf2.0/mfrom,pra include:_spf.google.com ip4:198.51.100.0/24 -all

Strip off the spf2.0/mfrom,pra prefix and the rest is indistinguishable from SPF. That prefix is the whole difference, and it encodes the one thing Sender ID added.

Here is the crux. SPF and Sender ID disagree about which identity in the message they authorise, and that single disagreement is what makes them different protocols rather than two names for one thing.

Classic SPF checks the envelope sender. When a sending server connects over SMTP it issues a MAIL FROM: command carrying a return-path address. SPF evaluates the domain of that address (and the HELO name). It never looks at the From: header your recipient reads. That gap, between the envelope and the visible header, is precisely why SPF on its own proves so little about the sender a human sees, and it is the reason DMARC had to be invented to add alignment on top.

Sender ID tried to close that gap directly, years before DMARC existed. Instead of the envelope sender, it checked the Purported Responsible Address, the PRA. The PRA is computed by walking the message's header fields, defined in RFC 4407, in a fixed order:

The Resent-Sender: header, if a Resent-* block is present.
Otherwise the Resent-From: header.
Otherwise the Sender: header.
Otherwise the From: header.

Whichever it lands on first becomes the address Sender ID authenticates. In most ordinary mail with no resending, the PRA resolves to the From: header, which means Sender ID was effectively trying to authorise the visible sender directly. On paper that is more useful than SPF, because it is closer to what the user actually sees. The spf2.0/ prefix tells the receiver which identity to use:

spf2.0/pra means check the PRA.
spf2.0/mfrom means check the MAIL FROM, the same identity as classic SPF.
spf2.0/mfrom,pra means the record is valid for both scopes.

So the same syntax, pointed at a different identity, with a prefix declaring the scope. That is Sender ID in one paragraph.

Why it faded

Sender ID had real backing. Microsoft pushed it hard, Hotmail checked it, and for a while it looked like a serious contender. It faded anyway, for a stack of reasons that compounded.

The licensing cloud

Microsoft held patent applications relevant to the PRA algorithm and offered them under a royalty-free licence, but the licence terms were incompatible with several open-source licences and made the open-source community deeply wary. For a protocol that needed every mail server on earth to adopt it, the lukewarm reception from the people who write mail servers was close to fatal. This was a major reason MARID collapsed and it never fully cleared.

Reusing `v=spf1` records broke things

The fallback that looked so clever, treating an existing v=spf1 record as a PRA policy, was the technical heart of the problem. Domain owners had published SPF records describing which servers were allowed to use their domain in MAIL FROM, the envelope. Sender ID then reinterpreted those same records as statements about the From: header, the PRA, which the owner had never intended and never agreed to.

These are different identities, and a record that is correct for one can be wrong for the other. The most obvious breakage was forwarding and mailing lists. A mailing list commonly rewrites the envelope sender to its own bounce address (which keeps SPF happy on the envelope) while leaving the original author's From: header intact. Sender ID, checking the PRA, would evaluate the original author's domain against the list server's IP, get a fail, and reject perfectly legitimate list mail. Classic SPF, checking the rewritten envelope, would have passed it. Reusing the record meant Sender ID inherited a policy that was never written for the identity it was applying it to.

The IETF would not bless it

The working group could not agree, and the documents shipped as Experimental rather than Standards Track. Experimental status is a quiet but powerful signal. It tells implementers the IETF is not standing behind this, and it gives risk-averse mail operators an easy reason to skip it. SPF, by contrast, eventually earned a proper Proposed Standard in RFC 7208. One sibling grew up and got a job; the other never left the experimental wing.

DMARC solved the real problem more cleanly

This is the decisive one. Sender ID's whole reason to exist was to authenticate the visible From:. In 2012 a better mechanism arrived to do exactly that. DMARC does not invent a new identity-extraction algorithm like the PRA. Instead it takes the results of the two authentication methods that already worked, SPF and DKIM, and adds alignment: it requires the domain that SPF or DKIM authenticated to match the domain in the From: header. If either passes and aligns, DMARC passes.

That achieves Sender ID's goal, tying authentication to the visible sender, without reinterpreting anyone's SPF record, without a fragile header-walking algorithm, and without a licensing cloud. DMARC also added the thing Sender ID never had: aggregate reporting, the RUA feedback loop that tells a domain owner who is sending as them. Once DMARC existed, Sender ID had no job left to do. Microsoft's own services moved to DMARC, and Sender ID was effectively abandoned. It is reasonable to treat it as deprecated today, even though the experimental RFCs were never formally withdrawn.

What this means for records you may still see

History is interesting, but the practical question is what to do when you actually find one of these in a zone you are responsible for. Here is the guidance.

Receivers stopped checking it long ago. No mainstream mailbox provider evaluates Sender ID today. Gmail, Outlook.com, Yahoo and the corporate gateways all run SPF, DKIM and DMARC. A spf2.0/ record sitting in your DNS is, to every modern receiver, simply ignored. It is not actively harming your deliverability through any Sender ID check, because nothing is performing one.

But it can still confuse tooling and humans. An spf2.0/ record is a TXT record that is not an SPF record, but at a glance it looks like one. Auditors, new staff and some checkers can mistake it for your live policy, or wonder whether you somehow have "two SPF records". You do not: a duplicate-SPF problem is specifically about two records starting with v=spf1, and an spf2.0/ record does not count toward that. Still, the ambiguity is a needless trap. If you genuinely have two v=spf1 records, that is a real fault, and the fix for multiple SPF records explains how to merge them.

Decide whether to keep or remove it. In almost every case the right move is to remove the spf2.0/ record. Run through this checklist first:

Confirm it is Sender ID, not SPF. It will start with spf2.0/, never v=spf1. Anything beginning v=spf1 is your real SPF policy and must stay.
Read what it authorises. Check the scope in the prefix (mfrom, pra or both) and compare the mechanisms against your current v=spf1 record. If they have drifted apart, that drift is itself a sign the record is stale and unmaintained.
Make sure your real SPF record is correct and current before you touch anything, because that is the record doing the actual work. Paste your domain into the SPF checker and confirm it passes cleanly with the right sources and a sensible all qualifier.
Remove the spf2.0/ record. Deleting it changes nothing for modern receivers, removes the trap for future auditors, and tidies the zone. There is no modern receiver behaviour that depends on its presence.
Re-scan after the DNS change propagates so you have a clean record of the zone in its tidied state.

One caution: do not blindly copy mechanisms from an old Sender ID record into your live SPF record on the assumption they are equivalent. They were written for a possibly different identity (PRA versus MAIL FROM) and, because the record is likely years old, the senders it lists may be wrong now in either direction. Rebuild your SPF from what you actually send today, not from a fossil. The SPF generator is a cleaner starting point than salvaging an spf2.0/ line, and you can sanity-check the result with the SPF checker.

A worked example

Suppose an audit of example.com turns up two TXT records at the apex:

v=spf1 include:_spf.google.com include:sendgrid.net ~all
spf2.0/mfrom,pra include:_spf.google.com ip4:198.51.100.0/24 -all

Read them like an investigator. The first is your live SPF policy: Google Workspace and SendGrid, softfail on everything else. The second is a Sender ID record, scoped to both mfrom and pra. Notice that the two records disagree: the Sender ID one still lists an ip4:198.51.100.0/24 block and is missing SendGrid, while ending in a hard -all. That is a classic stale fossil. It was written when you sent from your own 198.51.100.x servers, before you moved to SendGrid, and it was never updated because nothing checks it.

If, hypothetically, any receiver still evaluated Sender ID against that second record, your SendGrid mail would hard-fail it, because SendGrid is not listed and the record ends -all. The only thing saving you is that nobody runs the check. That is exactly the kind of buried inconsistency you want gone. Delete the spf2.0/ record, leave the v=spf1 record alone (or improve it separately), and re-scan.

The lesson Sender ID leaves behind

Sender ID is worth understanding for more than tidiness. It was a genuine, well-resourced attempt to authenticate the visible From: address, and it failed for reasons that shaped everything built afterwards. Its central mistake, reusing a record written for one identity to make claims about a different identity, is the precise mistake DMARC was careful not to repeat. DMARC never reinterprets your SPF record; it reads SPF and DKIM as they are and adds alignment on top. That restraint is why DMARC succeeded where Sender ID did not.

So the family tree is straightforward once you see it. SPF and Sender ID were siblings born from the same 2004 merger, sharing a syntax and a DNS model but disagreeing about which identity to authenticate. SPF kept to the modest, well-defined job of authorising the envelope and became a standard. Sender ID reached for the harder job of authorising the visible sender, stumbled over licensing, broke forwarding, never got past Experimental, and was made redundant the moment DMARC arrived to do that job properly. Today an spf2.0/ record is a fossil: harmless to receivers, mildly confusing to humans, and almost always safe to remove once you have confirmed your real SPF policy is sound.

Practical takeaway

If you find a record starting spf2.0/ in your zone, do not panic and do not treat it as a second SPF record. It is Sender ID, no modern receiver checks it, and it is almost certainly stale. Confirm your live v=spf1 record is correct first, then delete the Sender ID record to remove the ambiguity. Start by pasting your domain into the SPF checker to see exactly what you are publishing, and use the DMARC checker to confirm you have the modern protection Sender ID was groping towards twenty years ago.

If you would rather not pick through legacy DNS records and edge cases yourself, our done-for-you DMARC service audits the whole zone, retires the fossils, and takes your domain from p=none to p=reject without breaking a single legitimate sender. You can also set up emailed monitoring with change alerts so the next stray record never sits unnoticed for fifteen years.