What a Repeated SPF Failure from One IP Range Reveals

A consistent SPF failure from a single IP range usually points to a defined configuration problem rather than random abuse. The sending system is reaching recipients, but the source address is not authorised by the domain’s published Sender Policy Framework record.

This pattern can appear when a business changes email providers, adds a cloud relay, moves mail servers, or routes messages through a security gateway without updating DNS. It may also affect legitimate mail sent from a forgotten subdomain, backup server, or regional office.

For Australian organisations, this matters across Microsoft 365 tenants, Google Workspace accounts, .com.au domains, and hosted mail services used by firms in Sydney, Melbourne, Brisbane and regional areas. A repeatable signal makes the issue easier to investigate because the same network source can be traced through message headers and delivery logs.

What SPF checks at delivery time

SPF allows a domain owner to publish the IP addresses and authorised services permitted to send mail for that domain. When a receiving mail server gets a message, it compares the envelope-from domain with the connecting IP address and evaluates the domain’s TXT record.

A hard SPF fail generally means the record explicitly excludes that address, often with -all. A softfail, commonly shown as ~all, indicates that the source is probably unauthorised but should not automatically be rejected. The distinction affects filtering, DMARC enforcement and the sender’s reputation.

Why one range can fail repeatedly

A common cause is an incomplete SPF record after a provider migration. For example, a business may have moved from a local Australian hosting company to Microsoft 365 while leaving the old authorised IP range in place. Mail from the new provider then fails every time, even though the messages are genuine.

The reverse can also happen when an old relay remains active after it has been removed from the DNS record. A specific range may belong to a marketing platform, ticketing system, CRM, backup mail exchanger or secure email gateway. If that service still sends using the organisation’s domain, its traffic will produce a steady failure pattern.

Network changes that create false assumptions

Cloud platforms frequently use broad or changing address pools. An administrator may authorise one published range while the provider later sends from another. IPv6 can create a similar issue when the SPF record covers IPv4 addresses but omits the provider’s IPv6 mechanism.

A mail server behind NAT may also appear to recipients as a different public address from the one documented internally. This is especially important when a business uses an office connection, NBN service, colocation facility or managed firewall. The server may be correctly configured on the private network while its public egress address is missing from DNS.

What message headers can confirm

The Received headers identify the connecting host and address, while Return-Path shows the envelope-from domain used for SPF. These details should be compared with the visible From address, because SPF can pass for one domain while the user sees another.

A stable failure from one range, combined with a consistent HELO name or relay hostname, usually indicates a fixed outbound path. Domain owners can then compare that path with their hosting provider’s documentation, mail flow rules and SPF mechanisms such as ip4, ip6, a, mx and include.

How DKIM and DMARC refine the diagnosis

SPF failure does not automatically prove that a message is malicious. Forwarding services, mailing lists and some security gateways can alter the connecting source, causing SPF to fail even when the original sender was authorised. DKIM can preserve message authentication if the signature survives transit.

DMARC evaluates alignment between the visible From domain and either SPF or DKIM. If DMARC passes through aligned DKIM, a legitimate message may still reach the inbox despite an SPF problem. If both checks fail, enforcement policies such as p=quarantine or p=reject can cause delivery failures and expose spoofing attempts.

Correcting the authorised sender list

Start by identifying the owner of the failing IP range and confirming whether it should send mail for the domain. Remove obsolete mechanisms, add the correct provider include or address range, and avoid creating multiple SPF TXT records. SPF requires a single valid policy, and DNS lookup limits can cause failures when too many nested includes are used.

Changes should be tested against transactional messages, staff mail, invoices, newsletters and automated alerts. A correction that fixes Microsoft 365 traffic may leave a CRM or website contact form unauthorised. Reviewing the domain’s legal notices can also clarify how external checking services handle domain and trust information.

Monitoring the pattern over time

A single DNS lookup gives only a snapshot. Repeated checks can show whether the failing range disappears after propagation, continues during a provider migration, or returns at regular intervals from an overlooked application. This helps distinguish a stale record from an active unauthorised sender.

Trust monitoring is useful when a business needs early warning rather than a post-incident review. Notifications based on a falling domain trust score can reveal authentication drift, and these real-time alerts can support security teams managing several Australian domains or customer environments.

When the range may indicate abuse

If the IP range belongs to an unknown provider, an unauthorised reseller or a network with poor reputation, the issue may involve compromised credentials, a hijacked application or deliberate spoofing. The repeated source is valuable evidence because it can be correlated with timestamps, recipient addresses, authentication results and unusual sending volumes.

Domain owners should preserve relevant headers and review mailboxes, API keys, forwarding rules and service accounts. Checking SPF, DKIM, DMARC, domain reputation and anti-spoofing signals together provides a clearer assessment than relying on SPF alone. A single persistent range often reveals where the mail path diverges from the organisation’s intended architecture.