An application can pass SPF on one delivery attempt and fail on another when its mail leaves through different address families. If an inventory lists only IPv4 egress, an IPv6 route may be legitimate but unauthorised by the policy actually evaluated. Diagnose the connecting address before broadening the record.
The objective is precise coverage: authorise the IPv6 sources your organisation or provider actually uses, while preserving existing IPv4 behaviour and keeping unrelated addresses outside the policy.
Find the real IPv6 sending paths
Collect representative trusted receiver results and outbound MTA logs. Record the connecting IP, envelope domain, HELO hostname, sender service and timestamp. Group observations by both domain identity and address family. A web server's AAAA record is not proof that the same address sends mail, and an inbound MX destination is not automatically an outbound source.
Include fallback relays and regional routes. A single successful message cannot show that every route is covered. Ask infrastructure owners whether IPv6 is enabled on primary servers, failover systems and hosted delivery paths, then compare those answers with observed connections.
Use the correct mechanisms
SPF has distinct ip4 and ip6 mechanisms under RFC 7208 §5.6. ip4 authorises IPv4 addresses; it does not automatically cover IPv6 equivalents. An ip6 mechanism without a prefix length identifies one address, equivalent to /128. Broader prefixes authorise the matching network, so use only the range justified by your actual sending design.
The a and mx mechanisms can involve address-family-specific lookups: IPv6 evaluation uses AAAA addresses where applicable. That does not make them a substitute for inventory. A future AAAA change can alter the hosts those mechanisms authorise. Provider includes may cover both families, but inspect the supported policy rather than assuming all includes do.
RFC 7208 §5 also addresses IPv4-mapped IPv6 handling by evaluators. When a tool represents an IPv4 connection in mapped form, do not respond by adding arbitrary IPv6 ranges without checking the evaluator's handling and the underlying connection.
Test a narrowly scoped addition
Synthetic policy: v=spf1 ip4:192.0.2.10 ip6:2001:db8:1234::10 -all. Both addresses are reserved for documentation. A controlled evaluator should return pass for either listed source using the evaluated domain and fail for unmatched sources, assuming no DNS or syntax error intervenes.
The IPv6 term above authorises one address. Replacing it with ip6:2001:db8:1234::/48 substantially expands the set. Do not choose a broad prefix simply because it resembles an allocation shown in an infrastructure dashboard. Establish which part of the allocation is used and controlled for outbound mail.
Stage the production change
Confirm the proposed addresses with the service owner and current provider guidance. Preserve the previous policy, obtain the appropriate approval and validate the complete record before publication. Under RFC 7208 §4.6.4, explicit IP mechanisms do not themselves consume SPF's DNS-lookup term budget, but the rest of the record still needs evaluation.
Test an IPv4 route, an IPv6 route and an unmatched source under your control. At real receivers, retain the actual connecting IP and evaluated identity so a test that silently used IPv4 is not reported as an IPv6 success. Account for cached DNS answers when comparing observations immediately after the change.
Maintain the boundary
Add SPF review to IPv6 rollout and network-renumbering procedures. Where addresses rotate or a provider manages a large pool, prefer its supported authentication configuration rather than copying transient observations into a permanent allowlist. A sample IP shows that a source was used; it does not necessarily define the provider's full authorised range.
Close the review with evidence that both families work for the intended identities and that the chosen ranges are justified. IPv6 coverage should be an inventory improvement, not an excuse to authorise an entire network without ownership.
Record the next decision
In the synthetic policy, the IPv6 address 2001:db8:1234::10 is covered as /128, while 2001:db8:1234::11 is not. Switching to /48 would also cover the latter and many more addresses. Record which scope the service owner actually authorizes and the real receiver-observed family; successful IPv4 mail is not evidence of IPv6 coverage. No live test was executed.