According to just released research from Michigan based Inc it would appear that Sender ID is ineffective as an anti-spam solution. Despite the high profile, and frankly somewhat aggressive PR campaign by Microsoft, the 60 day statistical analysis certainly suggests that it isn’t the Holy Grail of anti-spam that Mr. Gates would have us believe.

Across a 60 day period, OnlyMyEmail discovered that emails sent by a domain without a published Sender Policy Framework (SPF) record were only slightly less likely to be spam than those sent by domains that publish Sender ID information in their DNS records. But, emails returning a positive match for Sender ID were not significantly more likely to be legitimate compared to those without a published SPF record, which is surprising. Most surprisingly, in my view, was the fact that an email that failed Sender ID verification only had a 91.4% chance of actually being spam. This translates into a false positive rate (FPR) of 8.6% if Sender ID were relied upon to accept or reject messages. When I evaluate anti-spam solutions in a professional capacity, be that for a magazine labs review or with my consulting hat on for a corporate purchase decision, anything that returns a FPR greater than 1% is rejected out of hand (no company can afford to lose 1 out of every 100 business communications because it has been wrongly flagged as spam.) With 1 out of 6 emails passing Sender ID verification also likely to be spam, according to these results, and the spam probability of incoming mail from domains not publishing Sender ID data being 49.5%, non-compliant domains are less likely to be sending spam than those who publish SPF records within their DNS (although only just.)

If you are an administrator who relies upon Sender ID to make decisions on whether or not to accept or reject inbound emails, this is bad news indeed. Crikey, some of the first generation anti-spam solutions could return a vastly superior performance when it comes to accuracy than Sender ID on these results. Worse, administrators who publish non-specific Sender ID/SPF records (in terms of their sending IP addresses) increase the chances that their outbound email will not be delivered by almost 79%. OnlyMyEmail take their criticism of Sender ID even further, claiming that spammers now commonly publish SPF entries for their sending domains which means it is being used as a weapon to increase spam delivery rates. This works because many email administrators have become over-reliant on Sender ID.

I remain unconvinced that Sender ID or SPF is the solution to spam, a conviction that has been reinforced by this research. Not that it really needed any reinforcing over and above the simple fact that pretty much every ‘traditional’ anti-spam filter either on the client or server side that I’ve tested in a real world environment has out-performed it in every meaningful way. The FPR figure being the real bottom line here. If you currently are relying upon a Sender ID or SPF bases solution, at the very least I urge you to consider what I’ve written here, and the OnlyMyEmail research, and do some real world testing of your own. If the solution is costing your company more in potential lost business than the problem is in wasted time, well, you don’t need a management consultant to tell you what to do…

Dani AI

Generated

A concise, practical addendum that extends ’s skepticism and ’s point about low adoption: Sender ID/SPF were never meant to be a single-fix anti‑spam switch. Sender ID in particular was treated as an experimental approach and never achieved broad, standardised buy‑in. (rfc-editor.org)

Technically, SPF checks the SMTP envelope identities (MAIL FROM / HELO) rather than the RFC5322.From header most users see; that gap, plus common forwarding and mailing‑list flows, is why SPF alone can misclassify legitimate mail. There are operational workarounds (Sender Rewriting Scheme, ARC) but they solve only some forwarding problems and don’t make SPF a standalone cure. (rfc-editor.org)

Practical, low‑risk approach for administrators: treat SPF/Sender ID as one signal in a layered authentication strategy and deploy DKIM + DMARC alongside it. Publish an SPF that accurately lists your senders, sign outbound mail with DKIM, then publish a DMARC record in monitoring mode (p=none) to gather aggregate reports before any enforcement. Move to p=quarantine/p=reject only after you’ve resolved sources shown in reports. (rfc-editor.org)

Quick, copy‑friendly examples (replace placeholders with your actual hosts/addresses):

TXT @  "v=spf1 ip4:198.51.100.0/24 include:mail.example.net ~all"
TXT _dmarc  "v=DMARC1; p=none; rua=mailto:dmarc-aggregate@yourdomain.tld; pct=100"

Troubleshooting tips: use DMARC aggregate reports to find missing senders; avoid -all (hard fail) until you’re confident every legitimate source is represented; watch DNS lookup limits in SPF implementations; and don’t rely on a single policy — combine content/reputation filters, RBLs, and user‑level controls. These steps deliver far better real‑world accuracy than relying solely on Sender ID/SPF.

Given the extremely low penetration of the software in current email clients and servers it's the only likely outcome.
The dataset of the trial is far too small because of that low penetration to be in any way useful, but does show that spammers will use technology designed to spoof them in order to gain apparent legitimacy which is hardly surprising as they've abused everything designed to work against them in the past.
Spammers after all are high tech criminals, and criminals aren't known to play by the rules and behave like good citizens.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.