Email checks explained

Does SPF Prevent Email Spoofing?

By EmailmetryReviewed 2 min read

SPF checks the return-address domain, which can differ from the address readers see. DMARC connects authentication to that visible address.

SPF helps stop unauthorised servers from using a domain as the return address for email. It does not, by itself, prove that the From address shown to the recipient is authentic.

That difference allows a forged message to pass SPF.

A pass can belong to the attacker’s domain

Imagine a message that displays billing@yourcompany.example in its From field but uses a return address at attacker.example.

The attacker can authorise their own sending server in the SPF record for attacker.example. SPF then passes for that domain. It has not authenticated yourcompany.example.

This is why an SPF pass alone is insufficient evidence that the visible sender is legitimate. Microsoft’s explanation of email authentication

An SPF pass can belong to a different domain

A forged email displays yourcompany.example but passes SPF for attacker.example, which does not authenticate the visible sender.
This example passes SPF for the attacker's own return-address domain. That unrelated pass does not authenticate the visible From domain or provide DMARC alignment.
Read the diagram as text
  1. Visible From address: billing@yourcompany.example.
  2. Return address: bounce@attacker.example.
  3. The attacker authorises their own server, so SPF can pass for attacker.example.
  4. That pass does not authenticate yourcompany.example. DMARC checks the relationship to the visible From domain.

DMARC connects authentication to the visible address

DMARC requires a passing SPF result or a valid DKIM signature to use a domain aligned with the visible From address.

In the example above, an SPF pass for the attacker’s unrelated domain would not satisfy that requirement. DMARC also lets a domain owner publish a policy asking receivers to quarantine or reject messages that fail. Receivers decide how to apply that policy.

Some impersonation uses an authenticated domain

An attacker can register a lookalike domain and authenticate it correctly. They can also put a familiar person’s name in the display-name field while using an unrelated address.

A compromised account can send mail through the real organisation’s authorised systems. Such a message may pass authentication and still contain a fraudulent payment request. Microsoft treats these impersonation threats separately in its anti-phishing protections, and the Australian Cyber Security Centre describes them in its business email compromise advice.

Check the policy protecting your domain

Use the DMARC checker to inspect the policy published for your domain. A monitoring policy does not request rejection; moving to rejection requires checking that legitimate services authenticate with the right domain.

The alignment guide explains why an SPF pass for an unrelated return address is insufficient. Domain policy helps with exact-domain forgery, while lookalike domains and compromised accounts need other controls.

Does SPF flattening change this?

Flattening reduces SPF lookup requirements by replacing supported references with explicit IP addresses or ranges. It does not change which domain SPF checks.

A record that stays within the lookup limit can complete its authentication check. That still does not prove that a payment instruction is genuine or that the person named in the message sent it.

Sources and further reading

Sources reviewed 12 September 2026.