Your Own MX Signed the Phish. Then DKIM Failed.

The delivered copy of this phishing email carries a DKIM signature in the victim's own domain name. Not a spoofed one. A real one, applied by a server the victim pays for.

It failed. The final authentication line reads dkim=fail (signature did not verify) header.d= next to compauth=fail reason=001. Read literally, the delivered headers accuse a South African motor-dealership group of a DKIM failure on a message the group never sent.

The attacker did nothing clever to arrange that. The dealership's own mail plumbing did it.

The MX that signs whatever it forwards

The group's main domain still points its MX at a hosted cPanel and Exim server, which accepts mail from the internet and redirects it into Microsoft 365. The headers spell the arrangement out. X-Get-Message-Sender-Via records : redirect/forwarder owner @ -> @.onmicrosoft.com, and X-Authenticated-Sender names that same staff mailbox as the authenticated sender of the message.

At that hop, the host applied its own outbound signing policy. DKIM-Signature v=1; a=rsa-sha256; d=; s=default was added to a phishing message the host had accepted from a third party seconds earlier, directly alongside the attacker's own signature from a Google-hosted signing domain.

DKIM is an assertion that a domain takes responsibility for a message. The legacy host made that assertion on the victim's behalf, about content the victim had never seen.

The message was then re-relayed and modified again on the way to the mailbox, which is exactly what breaks a signature. The receiving hop logged the verification failure for the dealership's own signing domain, plus a separate dkim=fail (body hash did not verify) for the sending tenant's signature. Note which domain DMARC was actually evaluating: the delivered line reads dmarc=none action=none header.from=. The dealership's domain was never the domain under DMARC evaluation here. It was simply the name on a failing signature.

Why this is worse than a broken header

We have documented the inverse of this case: a recipient-side link rewriter that modified a message body in transit and broke a legitimate sender's valid signature. That failure mode points outward. Someone else's good mail looks worse than it is.

This one points inward. The recipient's own infrastructure created a signature in the recipient's own name over attacker content, and that self-made signature is the one that fails in the delivered headers.

The consequence is a reasoning trap. If your MX signs and re-relays inbound mail, a DMARC report naming your own domain as the DKIM failure is not automatically evidence that someone is spoofing you. It can be your own plumbing marking its own homework wrong. A team that reads it as external abuse hunts a campaign that does not exist while the real message sits in a staff inbox.

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

The same bytes, spam at one hop and trusted at the next

The message crossed a Sophos email gateway three separate times and passed through two different Microsoft 365 tenants, leaving two distinct cross-tenant header-stripping markers behind it.

Microsoft scored it more than once, differently each time. One X-Forefront-Antispam-Report shows the connecting IP as the gateway host with SCL:9, SFV:SPM and CAT:OSPM. The next shows the connecting IP as the legacy host with SCL:-1, SFV:SKN and CAT:NONE. Skip-not-spam. Trusted sender.

Nothing about the message changed between those verdicts. What changed was whose identity the hop was evaluating. Each layer graded the relay in front of it rather than the content behind it.

The gateway's own scoring agreed with the permissive reading: X-LASED-SpamProbability 0.085099, X-LASED-Spam NonSpam, X-LASED-Impersonation False. Its sender-history headers show the sending domain as effectively unseen.

This is the structural limit of a secure email gateway (SEG) in a hybrid path. It scores hops, connecting IPs and relay reputations. Per the 2026 Verizon Data Breach Investigations Report, phishing is the initial access vector in 16% of breaches, credentials appear in 39% across the full kill chain, and the gateway attack mix runs 80% plain phishing against only 3% business email compromise (BEC). Plain credential phishing is the volume problem, and it is what a reputation-first control handles worst. IRONSCALES platform data across 36,000+ security professionals in 18,000+ organizations puts the baseline at 67.5 phishing emails per 100 mailboxes each month.

Adaptive AI scores the message and the mailbox relationship instead of the last hop. That is the only reading that stays stable across four relays and two tenants.

The lure argued against itself

The pretext was a trademark complaint, told twice with reworded subjects: a compliance warning about unapproved logo usage on 2026-06-02, then an official enforcement notice to a second mailbox at the same tenant roughly twelve weeks later. A Resent-From header shows it was also relayed between two of the group's own dealership domains.

The kit built a convincing shell: a case-reference pill repeated in a details table, a flag counter reading three, a findings list of exactly three generic items, a three-step timeline, and a two-day scan window that correctly matched the arrival date. The case reference is an invention.

Then the merge fields gave it away. This is a complaint about a Facebook business page, and the kit names an email address as the affected asset in two separate places. The recipient's own mailbox is printed four times in the visible body. The business name renders with a stray greeting word concatenated onto the dealership's trading name, so the company name on screen is not one the dealership uses.

The body claims it was sent from support@meta[.]com while the real From domain is an abused education-sector Google Workspace account, and the display name is the only place the brand appears. That is display-name-only impersonation, MITRE T1566.002. There are zero external images: the wordmark is styled text and the avatar is drawn with CSS shapes, so there is no tracking pixel and nothing for image-based detection to fetch. One blue Submit Appeal button is the only control in the message.

That link resolved to a Cloudflare Workers subdomain on a /meta.help path, with an independent scanner verdict of malicious and a captured screenshot. Free serverless hosting as throwaway phishing infrastructure is a pattern we have torn down before, so here it is supporting detail, not the story.

The interesting part is what that link had become by delivery. It is not a raw attacker URL. It is the recipient gateway's own rewrite wrapper, and the wrapper's hash parameter is byte-identical to this message's own gateway email ID in its headers. So the delivered message wears two pieces of the victim's stack: a DKIM signature in the victim's domain name, and a rewrite by the victim's gateway.

Indicators

What to check on your own mail path

Establish what your MX actually does to inbound mail before you trust your own authentication telemetry. If a legacy host fronts your domain and redirects into M365, confirm whether it applies an outbound DKIM policy to mail it merely forwards. A signature in your own domain over someone else's content is worse than no signature: it turns a clean external verdict into a failure that looks like yours. Managed DMARC monitoring separates self-inflicted failures from real abuse in the report stream.

Stop reading hop verdicts as message verdicts. When the same bytes read as spam from one relay and trusted from the next, neither number is about the email. Both are about the relay.

And treat a clean first hop as meaningless. The Microsoft Digital Defense Report 2024 documents the shift toward abusing legitimate services and valid accounts precisely because authentication then passes. CISA phishing guidance and the NIST definition of phishing both frame the attack around the deception, not the transport. SPF and DKIM prove someone controlled a sending account. Here someone did, and used it to accuse a car dealership of a trademark violation that never happened.