The Bounce Was Real. The Message Inside It Was the Phish.

The bounce was real. Every authentication check on it passed, and that is exactly why it deserved a second look.

An electrical engineer at a Canadian engineering firm received a message with the subject "undeliverable mail." It came from a university's mailer-daemon, carried a null Return-Path, and told the usual story: an external mailbox provider had refused delivery with a 550 5.7.1 "likely unsolicited mail" error. Below that, it reproduced the rejected message in full.

The engineer did not recognise the sender and reported it. A human analyst later resolved the incident as malicious, and the message was quarantined.

Passes That Describe the Wrong Message

The current-hop results were spotless. SPF passed from a Microsoft outbound address. DKIM passed twice, once for the university's domain and once for a second Exchange Online tenant domain that re-signed the notice on its way through. DMARC passed. Compauth passed with reason 100. Exchange scored it SCL 1.

Both signatures carried the same body hash. So the bounce text was not altered between the university's mail system and the engineer's tenant. This is not a tampering story, and nobody should read it as one.

Here is the catch. Every one of those passes evaluates the system that generated the notice. The university's mail system built a legitimate non-delivery report, signed it, and sent it. Authentication confirmed that, accurately.

It confirmed nothing about the message quoted inside.

The Verdict Was Pasted Into the Body

Scroll to "Bounced message" and the picture inverts. The quoted original's own headers record how it fared when it first hit a Microsoft frontend:

• Received-SPF: Fail, because the claimed sending domain did not designate the connecting host
• Authentication-Results: spf=fail dkim=none dmarc=fail (p=none)
• a HELO of [127.0.0.1], a loopback literal supplied by the client
• Microsoft's own X-Forefront stamp: country code AE and a PTR record that does not exist
• From and To set to the same mailbox, on a domain that was spoofed

That is the real verdict on the attacker's message. It failed SPF, failed DMARC and was never signed. The only reason anyone can read it is that a bounce reproduces headers verbatim. The domain's DMARC policy was p=none, so nothing stopped the original from being accepted.

One more detail trips up careful readers. The quoted block also contains an ARC entry showing a pass. That entry was added when the university's system evaluated the copy that Microsoft had already relayed, not the attacker's first delivery. A pass inside a quote is still a quote.

What the Quoted Message Was

The reproduced original carried a subject about a secure document shared through OneDrive, while its body was a voicemail notification card with a "Call Back" button. Subject and body disagreed about what the message even was.

It reached the engineer as text/plain. The quoted HTML arrived as raw source text, with no rendered button and no clickable link. The links array held only two Google help-page URLs, both clean. Nothing in the record shows a live click path to this victim, and we are not claiming one.

We also cannot explain how the notice reached this mailbox. The second DKIM signature shows it passed through another Exchange Online tenant. Which rule, forward or connector sent it onward is not visible in the record. Deliberate targeting is not established, and neither is anything about that tenant, which was the spoofed domain's tenant and may be as much a bystander as the university.

See Your Risk: Calculate how many threats your SEG is missing

Mapping the Mechanics

• T1566.002, Phishing: Spearphishing Link. The quoted lure was built around a call-to-action anchor, though in this delivery it was only source text.
• T1036, Masquerading. The attacker borrowed the credibility of a genuine non-delivery report, a message class mail systems and people both treat as plumbing.

The sending host's ownership is not established beyond the SPF failure and Microsoft's stamp. The bouncing university and the relaying tenant are bystanders, and neither appears here as an indicator.

Read the Authentication Where the Attacker Lives

The 2026 Verizon Data Breach Investigations Report puts the human element in 62% of breaches and phishing as the initial access vector in 16%. Attackers keep hunting for wrappers that make a lure look like something nobody needs to read closely. NIST defines phishing by deception, not format, and a bounce is a format people trust by reflex.

IRONSCALES platform data shows the same pattern across 36,000+ security professionals across 18,000+ organizations: the cases that matter are rarely the ones that fail a check. IRONSCALES Adaptive AI weighs sender history and content context, not the authentication verdict alone, and here the recipient's report plus a human malicious verdict is what closed the case.

For your team:

• Teach analysts two places to read authentication in a bounce. The envelope headers describe the bouncing system. The headers inside the body describe the message it quotes. Check SPF and DKIM results on the right one before drawing a conclusion.
• Treat a notice about mail you did not send as a question. A bounce goes to an envelope sender that anyone can forge. The CISA phishing guidance is clear that reporting suspicious mail early breaks the attack cycle, and "I never wrote to that address" is a report worth making.
• Do not let a passing compauth value settle triage. Compauth reason 100 told us the carrier was authentic. The Microsoft Digital Defense Report 2024 is a useful reminder of how much attacker activity now rides on legitimate cloud infrastructure.
• Close the p=none gap on domains you own. A spoofed message that fails DMARC under p=none is delivered anyway.

Authentication answered the question it was built for. This case asked a different one.