Why SPF, DKIM and DMARC Can All Pass on a Phishing Email

The case

A trusted-looking route carried an untrustworthy message

The recipient had an organisational mailbox configured to forward messages to a personal Outlook.com address. A message arrived at the personal address claiming that the organisational account would soon stop receiving email unless it was verified.

The message used urgency, threatened account deletion and directed the recipient to a cloud-hosted form. The form wording attempted to disguise a password request by describing an innocuous-looking field as the password used to sign in.

Recognisable sender domain

The visible sender used the organisation's real domain rather than an obvious lookalike.

Authentication passed

The receiving header recorded successful SPF, DKIM, DMARC and composite authentication.

Legitimate forwarding

A forwarding-loop marker identified the recipient's organisational mailbox as part of the delivery route.

Credential collection

The message ultimately attempted to move the recipient to an external form and obtain their password.

Evidence boundary

The header strongly supports submission through a genuine organisational Microsoft 365 environment and subsequent external forwarding. It does not prove who controlled the sending mailbox. Compromise, deliberate misuse and another authorised form of account access remain possibilities until the organisation investigates.

Interpret the results correctly

Authentication answers a routing question—not a trust question

Result	What a pass supports	What it does not prove
SPF	The sending service was permitted to send for the envelope-sender domain evaluated by the receiver.	That the visible author was genuine, the account was uncompromised or the content was safe.
DKIM	A valid domain signature covered selected message content and survived verification.	That the individual using the signing organisation's service was trustworthy.
DMARC	The visible From domain aligned with a passing SPF or DKIM identity under DMARC rules.	That the message was solicited, legitimate or free from credential theft.
Composite authentication	Microsoft's combined authentication assessment considered the sender sufficiently authenticated.	That every other spam, phishing, behavioural or account-risk signal was benign.
ARC	An authenticated chain can preserve earlier authentication results as a message passes through an intermediary such as a forwarding service.	That the original account holder intended to send the message.

The practical distinction

Authentication can confirm that the domain's mail system handled the message as authorised. It does not confirm that the account, user intent or requested action was trustworthy.

Reconstructing the route

The personal address need not have been known to the attacker

The forwarding marker supports a straightforward explanation for why the message appeared in a personal mailbox:

Likely delivery path

Organisational sender → Microsoft 365 → recipient's organisational mailbox → configured external forwarding → personal mailbox

The sender could have targeted only the organisational address. Legitimate forwarding then transferred the message to the personal address.

The absence of a visible copy in the organisational mailbox does not establish that the message bypassed it. Exchange Online forwarding can be configured either to retain a mailbox copy or to forward without retaining one. Deletion, filtering and mailbox-view differences are also possible, so the final explanation requires message tracing by the organisation.

Human-readable indicators

The message body still supplied strong warning signs

Artificial urgency

The recipient was told that processing would stop and the account could be deleted within hours.

Unexpected verification

The message demanded account verification despite arriving outside the normal account-management workflow.

External collection form

A third-party form was used instead of the organisation's established sign-in or account portal.

Disguised password request

The wording attempted to redefine another field as the recipient's sign-in password.

Poor language and branding

Awkward phrasing, vague ownership and a generic copyright sign-off conflicted with a genuine support process.

Unusual delivery context

The message reached a personal account while referring to an organisational mailbox, which deserved verification through a separate channel.

For recipients

Preserve the message and use a trusted reporting route

1

Do not follow the message instructions

Do not open the form, paste the address into a browser, reply to the sender or submit credentials. Reach the organisation through a bookmarked portal, published telephone number or known support contact.

2

Preserve useful evidence

Keep the original message and full internet headers. Forwarding only the visible body can remove the routing and authentication evidence needed for message tracing.

3

Report it privately

Send the original message to the organisation's IT or security team and use the mail provider's phishing-report function. UK recipients can also forward suspicious messages to the NCSC Suspicious Email Reporting Service.

4

Act quickly if anything was submitted

Tell the affected organisation immediately. Change the password through the real service, review multifactor-authentication methods and recent activity, and follow its incident instructions. A password change alone may not invalidate every active session.

For Microsoft 365 administrators

Treat authenticated phishing as a possible account incident

1

Trace the message

Use the original message, private identifiers and Microsoft 365 message-trace or investigation tools to establish the sender, recipients, submission path, delivery actions and campaign scope.

2

Investigate the sending identity

Review sign-ins, risk detections, authentication changes, mailbox audit activity, inbox rules, application consent, unusual sending and other evidence of account takeover or misuse.

3

Contain proportionately

If compromise is suspected, block access as appropriate, reset credentials, revoke active sessions and tokens, remove malicious persistence and protect evidence before it expires.

4

Find and remove related messages

Search for the sender, subject, destination, URL and other campaign indicators. Remove matching messages where the available licensing and investigation tools support it.

5

Report the destination

Report the credential-collection form to its hosting provider and the appropriate national reporting service. Keep the live address in restricted incident records rather than publishing it.

6

Review external forwarding

Identify who can automatically forward organisational mail externally, confirm a valid business need and assess whether copies, monitoring and data-protection controls are adequate.

7

Improve layered detection

Review anti-phishing policies, mailbox intelligence, user and domain impersonation protection, Safe Links where licensed, outbound-spam alerts and reporting workflows. Do not weaken authentication controls merely because authenticated phishing remains possible.

Evidence-led closure

Record what was established—and what remains uncertain

Message routeThe submission, forwarding and final delivery path have been confirmed through traceable evidence.

Campaign scopeRelated recipients, messages, links and sending activity have been identified and treated.

Account statusThe sending identity has been investigated, with compromise, authorised use or residual uncertainty recorded accurately.

Recipient exposureCredential submission, link access and subsequent sign-in activity have been assessed rather than assumed.

Forwarding controlExternal forwarding remains enabled only where the need, ownership, monitoring and information risk are understood.

Lessons learnedDetection, reporting and response changes have named owners and dates for validation.

RACF-CC alignment

The message crosses identity, monitoring and response

Identity and Access Management protects the sending account and authentication methods; Monitoring and Detection connects headers, sign-ins, mailbox activity and campaign evidence; Incident Response contains accounts and supports credential or session recovery; and Governance and Risk determines when external forwarding is justified and reviewed.

Do not turn one control into a promise it cannot keep

SPF, DKIM and DMARC remain essential anti-spoofing controls. Their limitation in this case is not a reason to remove them; it is a reason to combine them with identity protection, behavioural detection, safe reporting and rehearsed response.

Authoritative guidance

Sources and further action

Microsoft: SecOps guide for email authentication — interpretation of SPF, DKIM, DMARC, composite authentication and ARC.
Microsoft: Anti-spoofing protection FAQ — why anti-spoofing does not prevent every phishing technique, including compromised-account abuse.
Microsoft: Tune anti-phishing protection — investigation and protection guidance for delivered phishing.
Microsoft: Configure email forwarding for a mailbox — forwarding behaviour, retained-copy options and security considerations.
UK NCSC: Report a scam email — recipient reporting and recovery guidance.

Last checked: 29 September 2026. The case details have been deliberately generalised. No live phishing link, personal address, sender identity, institution, tenant identifier or message-tracing identifier has been published.