What Unaligned SPF Passes Reveal About Your Email Forwarders

A DMARC report full of SPF passes can look reassuring until its authenticated domains differ from the visible business addresses. Forwarding is often the reason: shared inboxes in Sydney, Melbourne and Brisbane may relay customer mail through another sending service.

SPF validates the envelope sender, while DMARC also checks whether that validated domain aligns with the visible From address. A large unaligned SPF population describes changed delivery infrastructure. It does not, by itself, establish how many messages were malicious or which users were affected.

That distinction matters for Australian teams using Microsoft 365 and Google Workspace. A DMARC report with a high volume of unaligned SPF passes is best treated as a map of mail flow, with source addresses, domains, timing and message logs providing the evidence.

The priority is to identify legitimate forwarding services, investigate lookalike domains or compromised mailboxes, and restore aligned authentication. The goal is a report that explains normal operations and exposes unusual activity, rather than a spotless total obtained by hiding legitimate senders.

Why SPF and DMARC results differ

SPF can pass when the connecting server is authorised by the envelope domain's DNS records. DMARC demands more: the SPF or DKIM domain must align with the visible From domain. This comparison helps stop an unrelated authorised server from borrowing a visible address.

In a forwarding pattern, SPF validates for the forwarding provider while DKIM fails after the message is rewritten. Some platforms add their own signature, which can be valid but unaligned. The report may show an SPF pass, a DKIM failure and an overall DMARC pass. Reading only the final label hides the route travelled.

Forwarding, mailing lists, and spoofing

Legitimate causes include forwarding, help-desk copies, mailing lists, scanned invoices and old aliases retained after migration. An attacker can create a similar pattern with a lookalike domain. Examine the authenticated domain, source infrastructure, message purpose and business context in either case.

Authentication is not a guarantee of safety: a compromised account can send messages that pass SPF and DKIM. For another warning sign, this missing SPF phishing review explains how a familiar domain without SPF records can support convincing impersonation. Forwarding evidence should trigger investigation, not condemnation.

Correlating reports with message logs

Begin with a narrow period and one receiver, then match source IPs, authenticated domains, visible From domains and timestamps against SMTP and security logs. The platform's guide to cross-checking DMARC reports shows how to relate XML records to delivery events without treating totals as proof of compromise.

Group by source IP and authenticated domain, not display name. One looping workflow can generate hundreds of reports, while traffic from many unrelated hosts deserves attention. A single email may be reported by several recipients. Check whether an outbound relay, ticketing system or filter rewrites the envelope sender, then inspect headers.

Prioritise the actual risk

Separate likely benign traffic from targeted impersonation, then consider impact. A known shared-inbox relay sending appointment reminders differs from an unknown host using a brand-name variant to request payroll changes or account details.

Preserve evidence before changing DNS or policies. Record headers, inspect attachments and links, check for sign-in anomalies, and enforce multifactor authentication on affected accounts. Quarantine unfamiliar traffic while retaining legitimate mail flow. A DMARC report supports decisions; it should not be the sole evidence used to declare an incident.

Restore alignment without breaking mail

List every service that sends on the organisation's behalf, including forwarders, scanners and list platforms. Configure DKIM signing where the message leaves, and align the visible From domain with the signer. Where supported, Authenticated Relay Chain can carry validation across the new hop.

Do not add every forwarder to SPF indiscriminately. SPF governs the envelope domain, includes consume part of the ten-lookup limit, and cannot authenticate an arbitrary visible address. Remove stale entries before adding providers. While correcting these paths, keep DMARC at p=none, then use quarantine and reject only after testing confirms legitimate mail still arrives.

Australian compliance and business context

Email authenticity supports more than filtering. Under the Privacy Act 1988 and Australian Privacy Principles, forwarded records containing personal information still need appropriate access, security and retention controls. Commercial electronic messages also engage the Spam Act 2003, including relevant consent, sender identification and unsubscribing requirements.

High-reputation .com.au, .gov.au, .health.au and .edu.au addresses carry an implicit trust advantage. Impersonation of an Australian agency, clinic, school or supplier can cause financial and reputational damage even when a receiver accepts the message. Domain monitoring should include partner domains, not only addresses owned by your organisation.

Measure progress and prevent regression

Establish a baseline of report volume, aligned passes, failures and unaligned passes by source and domain. Recalculate it after DNS changes, provider migrations and workflow updates. Trusted Sender Score supports bulk domain checks, reputation lookups and API integration, letting security teams automate these checks rather than maintain a spreadsheet.

Document each approved forwarding service, its owner and expected sending pattern. Remove records when a service is retired, and treat a new source, sharp volume change or mismatched domain as a review signal. The report then becomes a reliable operational record: normal forwarding is accounted for, aligned authentication dominates and unexplained activity remains visible.