TL;DR A plain-text email posing as a Mailgun account notice arrived with about 70 pre-written headers claiming an Exchange spam confidence level of 1, internal authentication, passing ARC seals, and a domain 1,140 days old. Every one of those verdicts sat below the only genuine hop and was written by the sender. The sender's own mail provider spoke truthfully: SPF softfail, DKIM body hash failure, DMARC fail. The ARC seal decoded to a random float, and the forged Exchange host was Microsoft's sample domain. Automated detection quarantined both waves.
Severity: High Credential Harvesting Header Forgery Brand Impersonation MITRE: T1566.002 MITRE: T1684.001 MITRE: T1036.005 MITRE: T1583.006 MITRE: T1204.001

The email arrived with its own verdicts already attached. An Exchange spam stamp reading SCL:1. A line saying the sender authenticated as Internal. A passing composite authentication result. An ARC seal marked pass.

All of it was written by the attacker.

The message was a plain-text note from "MailGun" telling a digital advertising company's employee to confirm an account to avoid losing access. Subject: a ten-digit number. The lure was thin. The header block was the real effort, roughly 70 lines of pre-written conclusions, all sitting below the only hop a defender could trust.

The one honest hop

The message entered through an authenticated SMTP submission to a hosting provider's mail server, which relayed it to Google, where the recipient's mailbox lived. That relay was the last place anyone evaluated the message, and Google's verdict was unambiguous: DKIM body hash did not verify, SPF softfail, DMARC fail, and the ARC chain was not contiguous.

Everything else in the header block claimed the opposite. Nothing that claimed it was evaluated by any receiver.

The spoofed From domain belongs to a real, long-established retail brand. Its SPF softfail and a DKIM signature whose value literally ends in three dots say the domain was spoofed. Nothing here suggests the brand was compromised, and it is a bystander in this story.

What the kit pre-wrote

Four forgeries stand out, and each one is checkable.

An Exchange antispam stamp from a sample domain. The X-Forefront-Antispam-Report carried SCL:1, SFV:NSPM and a host and PTR of mail.contoso[.]com. Contoso is Microsoft's documentation placeholder organization. No real tenant stamped this. A companion header claimed AuthAs Internal from an Exchange host also named under contoso. A second Authentication-Results block claimed compauth=pass reason=100 and dmarc=bestguesspass, which contradicts the real DMARC failure recorded by Google.

An ARC seal sealed with a random number. The planted ARC set at instance 3 claimed cv=pass for the spoofed domain. Its b= value base64-decodes to 0.49584384000973525, a Math.random()-style float. A real seal is a cryptographic signature. This one is a decimal. A separate planted instance claimed a Gmail DMARC pass for an address that appears nowhere else in the message and is not established as a sender.

Reputation telemetry. Headers announced a domain created in 2021, 1,140 days old, a "high" list quality and a 19% open rate. WHOIS says the domain was registered in 2008. The telemetry was invented to flatter the sender, and a single lookup contradicts it.

An impossible hop. An X-Received line named a server at 541.428.412.821. IPv4 octets stop at 255.

Add five conflicting mail-client claims in one message (Mailbird, Outlook, Apple Mail, Thunderbird, plus a MIME version string naming Thunderbird) and the picture is a kit that was assembled from copied header templates, not a mail system.

Why this works on the wrong reader

This is not an attempt to beat DMARC. The message fails DMARC, and the record shows it. The forged headers are aimed at a different consumer: a script, a triage workflow or a person skimming raw headers who reads from the top down and stops when the values look good.

The intent to read as clean is inference. The evidence does not show any product or analyst being fooled, and this post does not claim one was. What the evidence does show is that the headers were written to look like a clean report, and that a receiver which checked rather than read recorded failure at every step.

That distinction matters because the 2026 Verizon Data Breach Investigations Report finds 62% of breaches involve the human element, and 16% begin with phishing as initial access. Humans and scripts that trust displayed values are exactly the surface a forged verdict header targets. The same report's email gateway mix (Figure 54) puts 80% of blocked attacks at plain phishing. Most of it looks ordinary. The headers are where the disguise lives.

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

The trust boundary is a line you draw

The rule that defeats this kit is short. Find the first Received header written by a server you control. Everything above it is yours. Everything below it is attacker text, whatever it claims to be.

Apply that rule here and the entire pre-written block disappears. The compauth, the SCL, the ARC passes and the sender reputation all sit below the boundary. What remains above it is a DKIM body hash failure, an SPF softfail and a DMARC fail, the same signals DMARC and SPF were built to produce.

Detection does not depend on any of it. IRONSCALES Themis, the agentic AI virtual SOC analyst described at IRONSCALES agents, rated the message with 90 confidence, labelled the recipient a VIP, and flagged a first-time sender and a malicious verdict on the only link. The same mailbox received a second wave with a different numeric subject, and automated detection quarantined both deliveries. The pre-written verdicts changed nothing about the outcome.

What to change on Monday

  1. Stop displaying forged-prone headers as evidence. In analyst tooling and any LLM triage prompt, strip or label every header below your edge as unverified sender text.
  2. Trust stamps by origin, not by name. An X-MS-Exchange-Organization-* header is meaningful only when your own tenant added it.
  3. Check one fact per claim. A domain age claim takes one WHOIS lookup to refute, an ARC seal takes one decode, an IP takes one glance at the octets.
  4. Treat a contradiction as the signal. A message that says SCL 1 and internal while the receiver says DMARC fail is not mixed evidence. It is a confession.

Authentication outcomes that your infrastructure computed are worth acting on. Verdicts the sender computed for you are worth reading only as a description of what the sender hoped you would believe. For background on the technique class, see MITRE ATT&CK T1566.002, and CISA's phishing guidance and the NIST definition of phishing. The FBI's 2024 IC3 report shows what the downstream cost of credential-themed lures looks like.

Indicators

TypeIndicatorContext
URLhxxps://5499044558989-hsd6fsh4exa9h8bf[.]z03[.]azurefd[.]net/Only link in the message, flagged malicious
IP103[.]125[.]146[.]40Client that made the authenticated submission
HeaderX-Forefront-Antispam-Report: ...SCL:1;SRV:BULK;SFV:NSPM;H:mail.contoso[.]com...Forged Exchange antispam verdict
HeaderARC-Seal i=3 ... cv=pass; b=MC40OTU4NDM4NDAwMDk3MzUyNQ==Forged seal, decodes to 0.49584384000973525
HeaderX-Received: by 541.428.412.821Impossible IP octets
HeaderX-Domain-Age-Days: 1140Contradicted by WHOIS
Subject1401411790 and MailGun_0314628301Numeric subjects across the two waves

Nearly everything in this table was written by the sender. Only the IP and the link are real infrastructure.

Email Attack of the Day is a daily series from IRONSCALES spotlighting real phishing attacks caught by Adaptive AI and our community of 35,000+ security professionals. Each post breaks down a real attack. What it looked like, why it worked, and what to do about it.

Related attacks

Attack What happened
SafeLinks Wrapped the Phishing URL With the Recipient's Name on ItMicrosoft SafeLinks rewrote a phishing URL and embedded the recipient's email address into the redirect chain.
A Voicemail That Never Rang: How Attackers Chained Three ESPs to Launder Email AuthenticationAttackers chained SendGrid, Mailchimp, and ActiveCampaign Pages to deliver a voicemail-themed credential harvester that passed SPF and DKIM while...
How ARC Re-Signing and an IP Allow-List Turned Three Authentication Failures Into SCL -1A phishing email claiming to be a OneDrive share from an outlook.com address originated from a county government mail server.
The Fireflies Meeting Recap That Never Happened: Dual-Brand Impersonation via Amazon SESA phishing campaign combined Fireflies.ai meeting recap templates with Microsoft Teams branding to target a financial controller.
The Law Firm Name That Used Invisible Characters to Pass AuthenticationA phishing email impersonating Alston & Bird LLP used homoglyph characters in the display name and rode Google Drive sharing infrastructure to pass SPF.

Explore More Articles

Say goodbye to Phishing, BEC, and QR code attacks. Our Adaptive AI automatically learns and evolves to keep your employees safe from email attacks.