I received a strange job invitation claiming to be from Bolt and investigated whether it was phishing. The message came from [email protected], and SPF, DKIM, and DMARC all passed. The Received headers also appeared to show legitimate Odoo mail infrastructure.
That made me suspect the sender created an Odoo instance or database named bolt-job-invitation and used Odoo Helpdesk to send the message. In other words, they may not be spoofing Bolt's domain directly; they may be using a legitimate Odoo-hosted address while impersonating Bolt through the tenant name and message content.
Several details seem suspicious: all links point to bolt-job-invitation.odoo.com rather than Bolt's apparent corporate and careers domain, bolt.eu; the supposed recruitment message is formatted as an Odoo Helpdesk ticket called helpdesk.ticket-12; it claims to have found my profile without identifying a specific role, team, location, or relevant experience; and the footer includes an unrelated-looking @aniimate.net address. I also could not find any public connection between the sender's name and Bolt.
My current assessment is that this is likely brand-impersonation phishing sent through legitimate SaaS infrastructure. Passing SPF, DKIM, and DMARC would only show that Odoo was authorized to send mail for the Odoo-hosted domain. It would not prove that the sender is affiliated with Bolt.
Would you classify this as a true positive for phishing? Is my interpretation of the authentication and domain information correct, or is there anything important I may be overlooking? I'd especially appreciate input from people who work in email security, phishing analysis, or Odoo administration.
1 Answer
Yes, this is a legitimate example of brand impersonation through an abused SaaS platform. The sender can pass normal email-authentication checks because Odoo really did send the message, but that only validates the Odoo tenant and its authorization to send. It does not establish any relationship with Bolt. Similar attacks can be even more convincing when the abused service and the impersonated brand share the same domain, because users who are trained to check the sender address may still see something that appears to be from the real company.
That distinction is helpful. If the service itself is also the brand being impersonated, checking only the sender domain can create a false sense of safety. I’ll include that scenario in future awareness guidance.