The Platform Labelled It an Invoice, Then a High Risk

On September 7, 2026, one mailbox at an international performance-marketing agency received a message that the platform delivering it had already described, in writing, three separate times. None of the three descriptions matched what was inside the message. All three arrived in the inbox alongside it, in plain text, and not one control in the path was built to read them.

The mail came from Xero's transactional invoicing address. It used Xero's genuine invoice template. It authenticated cleanly at the recipient's mail exchanger under the strictest policy a domain can publish. And it carried a recruitment pitch that asserted the Nike brand, with a single link to a domain the platform record later marked malicious.

Statement One: The Metadata Named the Content Class

The message carried three separate delivery tags from the platform's email service provider: one marking the live sending environment, one reading xero_web_invoice_email, and one reading invoices-invoice. That is the sending platform's own classification of what it believed it was shipping, emitted for its own routing and reporting, and left in the message on the way out.

The classification said invoice notification. The body was a job offer to a marketing professional.

This is not an inference drawn from tone or wording. It is a machine-readable label, generated by the sender, sitting a few header lines above content that flatly contradicts it. Nothing downstream compared the two, because nothing downstream is asked to.

Statement Two: The Sender Graded Its Own Traffic

The second self-assessment was blunter. The message shipped out of a sending address pool whose human-readable name, carried in the header X-Mailgun-Sending-Ip-Pool-Name, is 'High Risk Pool'. The pool identifier and the sending address behind it are both in the indicator table below, and that sending address is the same one the platform's SPF record authorizes.

Sender segmentation is ordinary hygiene at scale: a provider isolates traffic it doubts so one bad account cannot spoil deliverability for the good ones. But the label is a judgement, it had already been reached about this account before the message left, and it then travelled to the recipient as a string a human could read at a glance. It is a deliverability control, not an enforcement control, so it slowed nothing down.

Statement Three: The Platform Served the Brand It Was Used to Fake

The template's logo row did not load an image from attacker infrastructure. It loaded one from the platform's own asset host, at the endpoint shape hxxps://in[.]xero[.]com/logo?id=. The alt text on that row was the uploaded asset's filename, and the filename names the impersonated brand outright.

Decoding the identifier in that image request returns the same sending-organisation identifier the message carries in its own delivery variables. That is what ties the served logo to the account that sent the invoice: the impersonated brand's logo had been uploaded into the sending organisation's branding settings, and was then served on request by a domain no reputation engine has any reason to score.

It is also part of why the platform's own brand-impersonation detector recorded nothing. Impersonation logic hunts for resemblance. There was no resemblance here to find: the sending domain belonged to an accounting platform, the asserted brand was simply an unrelated company, and the logo came from a host on the sender's own infrastructure.

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

An Invoice Record With Nothing To Invoice

The body was Xero's real template rather than a rebuild, down to its table scaffolding, its brand text colour, and its own commented section markers delimiting each row. Those markers are the tell, because the rows they delimit rendered empty. No invoice number. No amount. No due date. No attachment. No button to view an invoice. There was no prior message in the thread either.

Only one region of the template held anything at all: the free-text note-to-customer field. That field carried the whole lure, including the flattery that the recipient's track record in paid media stood out enough to warrant a personal approach rather than a circulated listing, a promise that a short introductory call would be booked automatically as part of applying, and the apply link. The template was a hollow shell used as an envelope; the operator was not selling anything and did not need to.

Why Every Reputation Control Had Nothing To Say

The authentication result was total. DKIM passed on the platform's invoicing subdomain, SPF passed for the platform-generated bounce path, and DMARC passed with the domain publishing reject for itself and for its subdomains, evaluated at the recipient's own mail exchanger with no gateway artifact anywhere. Per the DMARCbis specification, that outcome confirms the domain authorized the service sending on its behalf, which is the only question anything in the path was actually asked. The platform, meanwhile, had already volunteered three answers to a different one.

Everything else was neutralised by design rather than by concealment. The invoicing domain cannot be blocklisted without breaking legitimate invoices, and it was not a stranger to this organisation. Click tracking was switched off on this stream, so the raw attacker URL arrived unwrapped. The apply domain was registered 37 days before the message arrived, past the young-domain window many rules use, and it is not a lookalike: it is a plain descriptive keyword domain that names the brand in the open. The reply address pointed at a mailbox on an unrelated third-party domain that appears nowhere in the visible message, a supporting oddity rather than the story.

Who held the sending organisation is unresolved. The more likely reading is that the operator provisioned it: the money fields were left empty, the branding was set to an unrelated company, no parent message exists, and the platform had already routed the account into that risk pool. None of that is proof, and a compromised paying customer of the platform would leave a broadly similar record.

Score the Envelope Against the Letter

The lesson is not that authentication is weak. It is that a free, machine-readable, sender-generated signal arrived inside this message and no control consumed it. Compare a platform's declared message type against the content class of the body. Treat a reply domain absent from the visible body as a first-class signal. Read CISA's phishing guidance and NIST's definition of phishing as descriptions of intent, not of infrastructure. The 2026 Verizon Data Breach Investigations Report puts the human element in 62% of breaches and phishing at 16% of initial access vectors, and gateway telemetry contributed to that report shows phishing as roughly 80% of what gateways block in a median month. What gets through is what looks structurally legitimate.

That is the gap our Adaptive AI is built to close, by scoring relationship, content and metadata coherence together instead of asking each layer a separate yes-or-no question. Where mail terminates at Google, Google Workspace augmentation is where that comparison belongs, in front of a native check that had already returned a clean pass. In this incident one mailbox was affected and no mitigation was recorded. There is no evidence of compromise at Xero, at its delivery provider, or at the impersonated brand.

Indicators of Compromise

MITRE ATT&CK Mapping