Forged Unsubscribe Headers Named the Victim's Domain

The message arrived at a single mailbox inside a commercial construction contractor around lunchtime on a Friday, and IRONSCALES quarantined it roughly twelve seconds later. For those twelve seconds it was, by every reading a mail client or a hurried analyst performs, mail from the contractor itself. The display name carried the company name. The subject announced that a company document was available. The body rendered a share notification that named the company a third time. And then, in the place almost nobody looks during triage, the attacker had done something genuinely unusual: it hand-typed the bulk-mail plumbing that a corporate mailing system emits, and aimed every piece of it at the victim's own apex domain.

Compliance Furniture, Hand-Carved

Three headers carried the forgery. A List-Unsubscribe header held a mailto address at the contractor's own apex domain, with an unsubscribe subject line prefilled. A List-Unsubscribe-Post header declared the one-click value defined in RFC 8058, the standard that lets a mailbox provider surface a native unsubscribe button. A Feedback-ID header carried a value in the conventional sender and mailer form, and the mailer segment was, again, the contractor's own apex domain.

None of that belonged to the sending domain, which was a Japanese advertising firm's. And sitting in the same header block was an X-Mailer value claiming a desktop Microsoft Outlook build.

That combination is the tell, and it is worth sitting with. A desktop mail client does not emit a one-click unsubscribe declaration. It does not emit a Feedback-ID. Those values are generated by bulk-sending platforms, which is precisely why triage playbooks read them as reassuring: their presence implies a sending platform, a list, an operational team, a reputation to protect. Here they sat beside a header asserting the opposite kind of software entirely. No real sending stack produces that pairing. A person typed it.

Authentication That Belonged to Another Company

Nothing in the transport was spoofed, which is the second half of the story. The From header and the envelope both named a mailbox at a Japanese advertising firm, and the WHOIS registrant for that domain is a real advertising company. SPF passed at the receiving edge because the message genuinely left through the firm's own authorized outbound relay. DMARC then passed on that alignment, under the firm's own policy of none. No DKIM result appears anywhere in the authentication set, so this post makes no claim about one either way.

An earlier hop explains how. The message was injected into the advertising firm's own mail server over authenticated SMTP from a rented cloud host in the Tokyo region, meaning the attacker held working credentials for a mailbox that company owns. The firm is a compromised bystander here, not the adversary, and its clean authentication record is what made the message deliverable. The pattern is valid cloud account abuse (T1078.004) feeding compromised infrastructure. The 2024 Verizon Data Breach Investigations Report puts stolen credentials in 38% of breaches, the single most common initial action, and this is the downstream consequence: somebody else's stolen password becomes your inbound reputation problem.

The Field DMARC Never Reads

Here is the structural point, and it is the reason a mature email security program can do everything right and still take this message. DMARC, as defined in RFC 7489, evaluates exactly one identity: the domain in the From header, aligned against SPF or DKIM. The contractor's domain was never asserted in that field. It appeared in the display name, in the subject, in the body copy, in the forged unsubscribe mailbox and in the Feedback-ID. Not one of those is an authenticated identity.

So the contractor's own policy had nothing to inspect. Publishing a reject policy stops mail that claims your domain in a field a verifier checks. It does no work at all against mail that claims your domain in five fields that no verifier checks. That is not an argument against getting to enforcement, and monitoring your own DMARC posture remains table stakes. It is an argument for knowing the shape of the hole enforcement leaves behind, and for reading a self-referential unsubscribe address as the anomaly it is.

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

A Web Page Delivered As A Body

The craft continued below the headers. The body was not an email template but a complete standalone HTML document, roughly a hundred thousand characters, with a page title about a contract proposal, two remote Google font stylesheets, accessibility skip-links, a fixed banner container, a sticky header and a full-viewport flex layout. Inside that scaffolding sat a Microsoft-styled share modal naming the contractor, a spreadsheet chip labelled as a tax-assessment file named for that day's date, an open button, and a personalised line addressed to the recipient's own mailbox that misspelled solely as solenly.

Behind the modal, set as a blurred background image, sat one large embedded picture: a genuine screenshot of a stranger's spreadsheet session, an unrelated third party's open document recycled as fake preview art. Whether the victim's webmail renderer ever displayed any of that is unknown, since fixed positioning, generated-content backgrounds and remote font references are exactly what mail sanitisers strip. Treat the construction as attacker effort, not as what appeared on screen.

The single link, an instance of link-based phishing and user execution, resolved to a verification-style page planted on the website of a small painting contractor, a years-old small-business site that had been quietly compromised. That page served a fake human-verification interstitial, the familiar checkbox and the line about checking your browser before access. The scanner never got past it, which is why the URL verdict stopped at partial. Nothing in the record shows what sits behind the gate, so nothing here asserts that a credential form was observed.

What Actually Caught It

Authentication and sending-domain reputation contributed nothing to detection, because both were clean. Themis reached 89% confidence on the combination that remained: the link flagged malicious and cited by its own display text, language and structure analysis of the page, community reputation matching previously reported phishing, and the mismatch between the display name and the actual sender, which independently fired an impersonation rule for a company name appearing in a display name. The 2024 DBIR clocks the median time to click a phishing link at 21 seconds. Quarantine landed in about twelve.

The lesson is narrow. Unsubscribe compliance, a Feedback-ID and a mailer string are free text. When they name your own organization inside a message that authenticated for a company you have never heard of, they are costume, and the fact that they were sewn by hand shows in the contradiction between them. CISA phishing guidance and the NIST definition both stress the identity claim over the delivery mechanism, and that is the right instinct: compare every domain a message names against the one it proved.

Indicators of Compromise

MITRE ATT&CK Mapping

Attacks that never touch your domain in an authenticated field are the ones your own policy cannot answer, which is why detection has to weigh the identity a message claims against the identity it proved. That is the gap credential-harvesting protection built on behavioural signal is meant to cover, and in this case it closed in twelve seconds.