SPF checks whether a server is authorised for the envelope-sender domain. It does not directly verify the visible From address or the person behind a message. DMARC adds alignment to the visible domain, while display-name impersonation, lookalike domains and compromised mailboxes can still produce messages with valid authentication.
SPF helps with a specific kind of forged sending identity. It cannot turn every message with a passing result into a trustworthy one.
That boundary matters because several forms of impersonation can look similar in an inbox while involving different technical identities.
SPF checks the envelope domain
SPF normally evaluates the SMTP envelope-sender domain, commonly shown as Return-Path after delivery. The visible From address is separate. DMARC checks whether a qualifying SPF or DKIM result aligns with that visible domain. Microsoft explains the authentication relationship.
For example, an unauthorised server claiming an envelope address at example.com can fail that domain's restrictive SPF policy. But a server using its own authorised envelope domain can pass SPF while putting accounts@example.com in the visible From field.
The second message has not authenticated example.com through SPF. It passed a check for another domain. This is why the domain beside a pass result matters.
Four different impersonation problems
| What the message does | What domain authentication can establish |
|---|---|
| Uses your domain as the envelope sender from an unauthorised server | SPF can return a failing result for that domain |
| Forges your visible From domain while authenticating an unrelated domain | DMARC can identify the lack of aligned authentication |
| Uses a familiar display name or a separately registered lookalike domain | Authentication can pass for the attacker's own domain |
| Sends through a compromised legitimate mailbox | Authentication can pass for the legitimate domain |
The receiver decides how to handle authentication failures. Publishing an enforcement policy does not control every receiving system.
A verified domain is not a verified person or request
A display name is text chosen by the sender. Valid SPF and DKIM for an unrelated address do not prove that the person named works for your supplier. Your DNS records also cannot control a different registrant's lookalike domain.
Microsoft separates spoofing controls from user and domain impersonation protection in its anti-phishing documentation. That distinction is useful when evaluating what an email security product actually covers.
A compromised real account creates another limit. Its messages may use the normal sending infrastructure and valid signatures. The Australian Cyber Security Centre describes compromised accounts as one route for business email compromise, including fraudulent payment requests.
Authentication cannot establish that a request to change bank details is legitimate. Account protection and an independent check of the request address risks that SPF does not examine.
SPF remains useful alongside DKIM and DMARC. It should be described as sender authorisation for a domain, not as complete protection against impersonation or invoice fraud. Our email authentication explanation sets out how the three checks fit together.
Sources and further reading
- Microsoft: How email authentication works
- Microsoft: Anti-phishing policies
- Australian Cyber Security Centre: Business email compromise
Sources reviewed 8 September 2026. Our editorial standards.