auth.spf.sender_id_deprecated

Deprecated Sender ID Record

What we check

We check the apex TXT records for a Sender ID record beginning with spf2.0/. Sender ID was Microsoft's SPF variant; RFC 4406 was reclassified as Historic, so the record is dead weight and can confuse tooling.

What this finding means

Alongside your SPF record, the domain publishes a legacy spf2.0/ Sender ID record. Modern receivers don't use Sender ID, so the record does nothing useful — but it lingers in the zone, adds clutter, and occasionally trips up tools that try to parse it as SPF.

Why it matters

Obsolete standard. Sender ID (RFC 4406) is Historic. No current mailbox provider evaluates spf2.0/ records.
Potential confusion. Some older or naive tools treat spf2.0/ as a second sender-authorization record and mis-report your configuration.
Not harmful, just stale. It doesn't break SPF or DMARC — it's residue from an approach the industry abandoned.

How to fix

Remove the spf2.0/ record from your apex TXT records. Keep only your v=spf1 SPF record:
```
example.com.  IN  TXT  "v=spf1 include:_spf.your-provider.example -all"
```
Delete any TXT record starting with spf2.0/pra or spf2.0/mfrom.

How it's graded

A deprecated Sender ID record is informational and carries no point deduction. See Grading Methodology for the full scoring model.

Evidence example

$ dig +short TXT example.com
"v=spf1 include:_spf.your-provider.example -all"
"spf2.0/pra include:_spf.your-provider.example -all"
 ^^^^^^^^^^ Historic Sender ID record (RFC 4406) — safe to delete