A mechanism the SPF spec told you to stop using twelve years ago is still in 41,728 records.

When we parsed SPF across 5.5M domains (SPF Supply Chain 2026, scanned March 2026), 41,728 of them — 1.4% of all SPF-enabled domains — still include the ptr mechanism.

RFC 7208 §5.5 is blunt: ptr "SHOULD NOT be used."

Here's why the spec gave up on it. ptr authorizes a sender by doing a reverse-DNS lookup on the connecting IP and checking whether the result sits under your domain.

That's slow, it's spoofable if reverse DNS isn't tightly controlled, and it loads receiving mail servers on every connection.

Some receivers now skip or downrank it, so a ptr pass isn't even reliable.

So why is it still there? Cargo-cult DNS.

Someone copied an SPF record from an old tutorial a decade ago, it worked well enough, and nobody has touched it since.

For most domains, SPF is write-once-and-forget.

What to do: pull your SPF record and look for ptr. If it's there, replace it with explicit ip4:/ip6: ranges or an include: for the real sender, then drop ptr. Inspect it token by token here:

https://dmarcguard.io/tools/spf-syntax-inspector/?utm_source=linkedin&utm_medium=social&utm_campaign=jul2026&utm_content=li-w9-tue

Data: SPF Supply Chain 2026, scanned March 2026.

SPF #Sysadmin