[ SPF ]

SPF ip4 and ip6: authorise addresses and ranges accurately

Authorise the actual outbound addresses without accidentally granting an entire network more permission than it needs.

By the EmailAuth research team · 4 min read

[ Key points ]

  • Use observed outbound addresses and justified network scope.
  • Check both address families and failover routes.
  • Compare the exact permission set before and after a change.
On this page
  1. Key points
  2. Choose the narrowest justified scope
  3. Worked example: boundary tests catch broad grants
  4. Check both network families and egress paths
  5. Understand the maintenance tradeoff
  6. Publish with a permission diff
  7. The practical takeaway
  8. Record the decision and its limits
  9. Takeaway
  10. By role
  11. Frequently asked questions
  12. Sources
  13. Glossary
  14. Related guides

The ip4 and ip6 SPF mechanisms compare the connecting address with a published address or CIDR network. They are straightforward when you control stable outbound servers, but a small prefix error can grant permission to far more infrastructure than intended.

Use the address the recipient actually sees. A server's private interface address, a website address and a cloud account's general network range are not substitutes for the outbound SMTP source.

Choose the narrowest justified scope

ip4:192.0.2.70 identifies one IPv4 address because the omitted prefix defaults to /32. ip6:2001:db8::70 similarly defaults to /128. A /24 IPv4 prefix represents 256 addresses, while a /64 IPv6 prefix covers an enormous address space. Network size is not a reason to authorise it; control and operational need are.

RFC 7208 section 5.6 defines the matching and prefix rules. Use complete addresses and proper CIDR notation. An abbreviated value such as 192.0.2. is not a valid replacement for 192.0.2.0/24.

Worked example: boundary tests catch broad grants

Consider the synthetic policy v=spf1 ip4:192.0.2.64/28 ip6:2001:db8:1::/64 -all. The IPv4 range runs from 192.0.2.64 through 192.0.2.79. A connecting address of 192.0.2.70 matches; 192.0.2.80 does not and reaches -all if nothing else matches.

The IPv6 address 2001:db8:1::25 matches the /64. The address 2001:db8:2::25 does not. These reserved documentation addresses are for reasoning about the policy, not live senders.

For a real proposed range, create the same boundary tests and list who controls every included segment. If the only approved sender is one host, compare the permission set with a single-address mechanism before approving the broader prefix.

Check both network families and egress paths

A native IPv6 source requires an IPv6 permission. RFC 7208 RFC 7208 §5 separately requires IPv4-mapped IPv6 addresses to be checked as IPv4; this does not make an ip4 range cover native IPv6. A system that begins using IPv6 may suddenly reach the policy ending even though its IPv4 messages continue to pass. Obtain received-message evidence or outbound infrastructure records for both families actually used.

Also account for NAT, failover gateways, regional relays and scheduled jobs. A test from a single active node may miss a standby route. Do not solve uncertainty by authorising a whole hosting provider. Establish the supported egress set and ownership instead.

Understand the maintenance tradeoff

Under RFC 7208 §4.6.4, ip4 and ip6 do not consume the ten DNS-query-causing-term budget during mechanism evaluation. The receiver still has to obtain the SPF record, and policy size and correctness still matter. A record with hundreds of copied ranges is not automatically maintainable merely because those terms do not count toward that limit.

When a provider recommends an include, replacing it with a snapshot of IP addresses makes you responsible for future changes. Record how changes will be detected, who will approve them and how obsolete addresses will be removed. Stale permissions can both disrupt legitimate mail and retain access for infrastructure you no longer use.

Publish with a permission diff

Keep the old record and explain the exact ranges being added and removed. Validate the entire proposed SPF record, test known sender addresses and nearby unauthorised addresses, and verify the published TXT answer. Then send representative messages through normal and failover paths.

If an address is unexpectedly outside the approved range, investigate the route before widening it. An unexpected egress may reveal a configuration error or an unapproved sender rather than a missing permission.

The practical takeaway

An address mechanism is explicit only when its ownership and boundaries are explicit. Use observed egress, test range edges and treat future address changes as part of the authorisation lifecycle.

Record the decision and its limits

For the /28 fixture, record 192.0.2.63 as outside, .64 and .79 as inside, and .80 as outside. SPF prefix matching includes all addresses in the block, not only the conventional host-address subset. If only .70 is justified, compare /32 with /28: the latter grants 16 addresses, not one. These are calculated membership examples, not executed SPF tests.

[ Takeaway ]

Use observed outbound addresses and justified network scope. Check both address families and failover routes. Compare the exact permission set before and after a change.

[ By role ]

What this means for you

Choose your role for practical next steps.

IT / Mail Admin

Test the addresses recipients see.

Local interface configuration does not always reveal actual SMTP egress.

Next steps

  1. Capture NAT and relay paths.
  2. Test CIDR boundaries.
  3. Verify IPv6 explicitly.

CISO / SecOps

Review the size of each grant.

A broad network may include systems with different owners or trust levels.

Next steps

  1. Require range ownership evidence.
  2. Prefer justified narrow grants.
  3. Audit retired address permissions.

Founder / Non-technical

Fund address ownership, not one-off DNS edits.

A stable sender inventory reduces disruption when infrastructure changes.

Next steps

  1. Name owners for outbound routes.
  2. Include failover in readiness checks.
  3. Retire obsolete infrastructure permissions.

[ FAQs ]

Frequently asked questions

What is the default ip4 prefix?

An omitted prefix means /32, a single IPv4 address.

RFC 7208 §5.6

What is the default ip6 prefix?

An omitted prefix means /128, a single IPv6 address.

RFC 7208 §5.6

Does ip4 cover a server using IPv6?

Not for a native IPv6 source. IPv4-mapped IPv6 addresses are checked as IPv4 under RFC 7208; authorise approved native IPv6 egress separately.

RFC 7208 §5

Do ip4 and ip6 consume the ten-term limit?

They are not DNS-query-causing terms under that limit. DNS retrieval, record size and other constraints still apply.

RFC 7208 §4.6.4

Should I authorise my server private address?

For Internet delivery, use the connecting address observed by the recipient, which may be a NAT or relay address. SPF evaluates the connection IP, not a presumed local interface address.

RFC 7208 §4.1

Is a /24 safer because it covers failover?

Only if every included address is justified. Verify actual failover egress instead of granting a broad range speculatively.

Can I copy all provider ranges once?

That creates a maintenance obligation. Provider changes can make the copy stale or overbroad.

What should a range test include?

Test authorised hosts, the first and last addresses in the intended range, addresses just outside it and the corresponding IPv6 paths.

[ Sources ]

Sources

  1. RFC 7208

    Sections §4.1 · §4.6.4 · §5 · §5.6 · §2.4

[ Glossary ]

Glossary

SPF
Evaluation of a connecting IP against the policy for the relevant SMTP identity.

RFC 7208 §4.1

CIDR prefix
The number of high-order address bits compared for an ip4 or ip6 mechanism; omitted lengths mean /32 and /128 respectively.

RFC 7208 §5.6

Enterprise provenance

Why top financial institutions and governments retired their email security dashboards.

Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.

EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard,, with human-in-the-loop auditability.

Governments Large enterprises Tier-1 financial institutions

SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption

Knowledge Base