An old DNS interface may offer a record type labelled SPF. That label can refer to the historical type 99 resource record, which is not the publication format required by the current SPF version 1 specification. RFC 7208 §3.1 requires SPF policy in TXT, DNS type 16, and discontinued the earlier alternative-type approach.
For an administrator maintaining an older domain, the useful task is a compatibility cleanup: establish what is actually served, make TXT correct, and identify any legacy systems that still depend on type 99 before removing obsolete data.
Confirm the wire type
A product can use “SPF” as a friendly configuration label while actually creating TXT data. Another interface may genuinely create type 99. Do not decide from the menu wording alone. Query TXT explicitly and, where your DNS tooling supports it, query type 99 separately. Save the answer types, owner name, values and TTLs.
The SPF policy belongs at the evaluated domain name. A TXT policy at the root does not automatically cover a separate envelope subdomain. Ensure the domain being inspected matches a real sending identity before concluding that a missing TXT result explains a mail problem.
Understand why dual publication is not the goal
The historical RFC 4408 §12 records the allocation of SPF type 99; that experimental specification allowed an alternative resource-record type. RFC 7208 §3.1 explains that the transition approach did not yield a dependable common deployment model and selected TXT only for SPF version 1. Maintaining two divergent copies does not improve modern SPF evaluation; it creates another configuration that people may inspect and misunderstand.
A type 99 record alone is therefore insufficient for standards-conforming SPF version 1 publication. A correct TXT record is the operational priority. If TXT and type 99 disagree, do not select whichever value looks stricter. Reconstruct the intended sender policy from current service ownership and provider instructions.
Plan a conservative migration
Start by exporting the existing DNS state. If TXT is absent, design and validate the correct policy before publishing it. If TXT already exists, confirm it is the sole applicable SPF TXT record under RFC 7208 §4.5 and evaluates correctly. Do not create another TXT policy merely because type 99 exists.
In a synthetic example, a domain serves type 99 containing v=spf1 ip4:192.0.2.10 -all but has no SPF TXT record. A modern TXT-based evaluation does not obtain its policy from that type 99 value. Publishing an approved equivalent TXT policy addresses the missing standard publication format. The address is documentation-only and must not be copied into production.
Before removing type 99, check internal mail software, DNS automation, monitoring scripts and change procedures for legacy expectations. A local tool may still query it even though the standard does not require it. Update those dependencies deliberately, then remove the obsolete record under the organisation's change controls. This is a migration precaution, not a recommendation to preserve type 99 indefinitely.
Verify DNS and actual mail
Inspect authoritative TXT answers after publication and account for recursive caches. Test real messages from the retained sending services at trusted receivers, noting the SMTP identity used and the SPF result. A receiver reporting pass for a different vendor-controlled envelope domain does not prove the corrected domain's TXT policy was exercised.
Update runbooks to say TXT type 16 and capture the expected owner name. If the provider UI continues using an SPF label, document what it creates. This prevents the same problem from returning during a registrar transfer or DNS-provider migration.
Define the completion evidence
Retain the before-and-after DNS answers, sender-policy approval, inventory of retired legacy dependencies and representative message tests. The objective is one maintained SPF version 1 policy in the required format, with old tooling no longer presenting conflicting evidence.
Use the evidence for a decision
For the type99-only example, preserve separate query results for TXT and type99. Assuming a valid identity and no lookup error, a standards-conforming SPF check finds no TXT policy and returns none; it does not borrow type99. After an approved TXT change, require a sample using that exact identity before closing. This is expected protocol behavior, not a measured migration.