What if the message came through a mailing platform or customer-management system?¶
Third-party infrastructure can legitimately send for an organisation. The header may identify the platform, but shared servers do not identify the customer account, workflow or person that triggered this message.
Delivery and customer control are separate layers¶
From may show the organisation while Return-Path, Message-ID, Received fields and DKIM use platform domains. Campaign, tenant, template, ticket, transaction and recipient IDs can connect the message to a customer account more precisely than the platform's shared IP address.
Authentication can pass for an authorised platform, fail through poor configuration or pass while a hostile user abuses a legitimate platform account.
Follow identifiers into the workflow¶
Preserve provider-specific headers, links and remote-content identifiers without clicking them. Establish tenant, campaign, CRM user, API key or application identity, template version and triggering business event. Determine who configured, approved or changed the workflow and whether it ran automatically.
Authorship may be distributed across template writer, operator and application. A bounded conclusion identifies platform and customer process first, leaving human responsibility to the account, audit and configuration evidence.
The point to remember
Identify the sending platform, then follow message identifiers to the tenant, campaign, application and trigger behind it.
