On 10 September 2026, email platform Brevo found that an attacker had abused its SAML SSO handling to reach 138 customer accounts, export contacts from 43 and send phishing from 6. Trezor, one of the affected senders, said in a 17 September update that 347,149 of its marketing contacts had been exported. Earlier that month, on 4 September, Trezor disclosed that its shipping provider ShipMonk still held order data for about 67,000 US customers from November 2019 to August 2021, even though ShipMonk had confirmed in writing that the data was deleted.
In both cases the brand learned what happened from the vendor. A canary address per vendor gives you your own signal, and it points at exactly one supplier.
What's affected
Any setup where several vendors hold the same people's email addresses. A typical company copies its customer list into an email platform, a CRM, a helpdesk, a shipping provider and an analytics tool. When phishing arrives that clearly used that list, you can't tell which copy leaked.
The exposure is worse for vendors you have already offboarded. Trezor's policy required deletion within 90 days of delivery, and Trezor says that "despite receiving this confirmation, the data was not deleted in their systems." Nothing on Trezor's side could have shown that before the breach.
A canary is a synthetic contact with an address that exists only in one vendor's system. Mail to that address means the vendor's copy was used, by the vendor, by your own account on that vendor, or by someone who took it.
How to check if you're exposed
- List vendors that hold personal email addresses. Your data processing agreement register or records of processing is the starting point.
- For each vendor, ask one question. If this vendor's copy of our list leaked today, what would tell us? If the answer is "the vendor," you have no independent signal.
- Confirm your mail platform can do this. In Exchange Online, Microsoft documents that plus addressing is on by default. Gmail's help documents plus tags such as
janedoe+school@gmail.com. Send a test message to a tagged address on your own domain before you rely on it.
What to do now
-
Create one canary address per vendor. Use a dedicated mailbox that receives nothing else, and add a random suffix so the address can't be guessed from the vendor name:
for v in esp crm helpdesk 3pl; do echo "canary-${v}-$(openssl rand -hex 3)@yourcompany.example" donePlus tags are easy to strip, so a leaked
canary+crmcan arrive at the base address with no tag. Separate aliases keep attribution even then. Record every address in a register with the vendor, the system, the date seeded and the contract retention period. -
Google Workspace: aliases plus a content compliance rule. In the Admin console, go to Directory, Users, open the canary account and use Add Alternate Emails. Google allows up to 30 aliases per user and says changes can take up to 24 hours. Then go to Apps, Google Workspace, Gmail, Compliance and add a Content compliance rule:
Email messages to affect: Inbound Expression: Advanced content match Location: Any envelope recipient Match type: Matches regex Regexp: ^canary-[a-z0-9-]+@yourcompany\.example$ Action: Modify message Prepend custom subject: [CANARY] Add custom headers: X-Canary-Hit: true Add more recipients: secops@yourcompany.example -
Microsoft 365: plus addressing plus a mail flow rule. If someone turned plus addressing off, Microsoft's syntax to turn it back on is:
Set-OrganizationConfig -DisablePlusAddressInRecipients $falseExchange Online plus addresses for a canary mailbox look like
canary+crm-7f3a@yourcompany.example. Then create a transport rule that matches the tag in the To header and sends your security team an incident report with the original message attached:New-TransportRule "Vendor canary hit" ` -HeaderMatchesMessageHeader "To" ` -HeaderMatchesPatterns "canary\+[a-z0-9-]+@yourcompany\.example" ` -PrependSubject "[CANARY] " ` -SetHeaderName "X-Canary-Hit" -SetHeaderValue "true" ` -GenerateIncidentReport "secops@yourcompany.example" ` -IncidentReportContent Sender,Recipients,Subject,AttachOriginalMail -
Seed a canary record in every system that holds customer data. Add one synthetic contact per vendor through the same path real data takes: an import, an API sync, a webhook. Use a clearly fictional name and fill only the fields the vendor needs. For synced vendors, put the canary in the source system.
-
Separate your own traffic from a real hit. A canary in your email platform will receive your own newsletters, and that is useful: in the Brevo case, phishing went out from real customer accounts. Compare every message to the canary against your campaign calendar. Anything you didn't send is a hit.
-
Treat a hit as an incident. Keep the original message with full headers; the Microsoft incident report can attach it. Note the time, the sender and which canaries fired. One canary points at one vendor. Several at once suggest a shared upstream source. Then notify the vendor in writing. Under GDPR Article 33(2), "the processor shall notify the controller without undue delay after becoming aware of a personal data breach," and Article 28(3)(h) requires a processor to make available the information needed to demonstrate compliance, so ask for export and API logs covering the canary record.
-
Keep canaries alive after offboarding. Article 28(3)(g) requires a processor to delete or return personal data at the end of the service. Once a vendor confirms deletion, its canary should go quiet forever. Mail to that address after the confirmation date shows the data was kept.
Why it matters
Vendor risk reviews mostly run on what vendors tell you: questionnaires, certificates, deletion letters. Trezor had a written deletion confirmation and a 90 day policy, and the data was still there.
A canary is a control you run yourself. It costs one mailbox and a little setup, it works without the vendor's cooperation, and it turns "we think the leak came from one of our suppliers" into a named supplier with timestamped evidence.
Try it yourself
Pick the vendor that holds your largest customer list. Create its canary address, seed one synthetic contact in its system, and send yourself a test from that platform to confirm the rule fires and the incident report lands. Add the address to your vendor register with today's date.
Click through it at your own pace, or open it full screen.
Quick check
Why use separate aliases instead of only plus tags?
Anyone who knows the convention can remove a plus tag and send to the base address, which loses the vendor attribution. A separate alias per vendor survives that.
My canary received an email from my own brand. Is that a leak?
Not necessarily. Check whether your team sent it. If the message is not on your campaign calendar, treat it as an account compromise at that vendor, which is what happened to the senders in the Brevo incident.
What does mail to an offboarded vendor's canary prove?
That someone used the vendor's copy of your data after the vendor should have deleted it. Keep the message with full headers as evidence for the deletion conversation.
Sources
- Brevo: Incident write-up, attacker gained access to client accounts
- Trezor: Security incident at Brevo, our third-party email provider
- Trezor: Recent customer data exposed in shipping provider incident
- Microsoft Learn: Plus addressing in Exchange Online
- Microsoft Learn: New-TransportRule
- Google Workspace: Add or delete an alternate email address (email alias)
- Google Workspace: Set up rules for advanced email content filtering
- Gmail Help: Send emails from a different address or alias
- GDPR Article 28: Processor
- GDPR Article 33: Notification of a personal data breach