Skip to content
EML-027 Email Evidence

What if the message came through a mailing platform or customer-management system?

title: What if the message came through a mailing platform or customer-management system? subtitle: Third-party sending infrastructure may explain unfamiliar headers without identifying the customer or person who triggered the message. slug: what-if-the-message-came-through-a-mailing-platform-or-customer-management-system series: email-evidence section: sender-and-account-attribution card_type: question_card pathway_order: 12 section_order: 6 status: draft public_safe: true video_ready: true word_count: 609 estimated_read_time_seconds: 252 audiences: - investigator - supervisor - fraud and compliance practitioner tags: - email evidence - mailing platform - CRM - third party - automation sources: - title: 'RFC 5598: Internet Mail Architecture' url: https://www.rfc-editor.org/info/rfc5598/ - title: 'RFC 5322: Internet Message Format' url: https://www.rfc-editor.org/info/rfc5322/ - title: 'RFC 6376: DomainKeys Identified Mail (DKIM) Signatures' url: https://www.rfc-editor.org/info/rfc6376/ - title: 'RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)' url: https://www.rfc-editor.org/info/rfc9989/ - title: 'Microsoft Learn: Trace an email message in Exchange Online' url: https://learn.microsoft.com/en-us/exchange/monitoring/trace-an-email-message/trace-an-email-message

What if the message came through a mailing platform or customer-management system?

Third-party sending infrastructure may explain unfamiliar headers without identifying the customer or person who triggered the message.

Script

A message may display the name and address of a business while the header shows servers, domains and identifiers belonging to a third-party platform.

That is often normal.

Organisations use mailing platforms, customer-management systems, ticketing services, payment services and cloud applications to send email on their behalf.

The From address may show the organisation.

The Return-Path may belong to the platform so it can process bounces.

The DKIM signature may use the organisation’s domain, a delegated subdomain or the platform’s domain.

The Message-ID and Received chain may point towards shared provider infrastructure.

Those differences don’t automatically mean the address was spoofed.

They may show the difference between the organisation responsible for the communication and the service used to deliver it.

The investigation now has two levels.

First, identify the platform.

Look at the trusted Received chain, Return-Path, DKIM signing domain, Message-ID pattern and provider-specific headers.

The message may include campaign identifiers, customer IDs, template IDs, ticket numbers, event IDs or unique recipient references.

Preserve those values exactly. They may be more useful to the platform than a screenshot of the visible email.

Second, identify the customer account or process behind the message.

A large platform may send millions of emails through shared infrastructure. Identifying the platform’s IP address doesn’t identify which customer created your message.

The useful records may link the message to:

an organisation or tenant;

a campaign;

a CRM user;

an API key;

an application;

an automated workflow;

a contact record;

a template;

or an event such as an order, password reset or support ticket.

Ask the organisation whether it recognises the campaign or transaction.

Was the platform authorised?

Which staff or systems could trigger the message?

Was it generated automatically from a rule, schedule or customer action?

Was the content taken from a template?

Could several users access the same platform account?

Did an integration or compromised API credential send it without a person logging into the platform interface?

This matters for authorship.

A marketing message may have been approved by one person, configured by another and sent automatically to thousands of recipients later.

A customer-management email may be triggered when a record changes.

A support message may display an agent’s name while being assembled and delivered by the ticketing system.

The email can still be genuine and relevant. But “who wrote it?” may not have one simple answer.

Also preserve links and remote content.

Mailing platforms commonly rewrite links for click tracking and use remote images or tracking pixels. The visible destination may differ from the tracking address in the email.

Don’t click to test it. Preserve the underlying URL and use safe analysis.

Authentication results need context too.

A legitimate platform may pass DKIM and DMARC because the organisation authorised it.

A poorly configured but genuine campaign may fail.

A hostile user may abuse a legitimate platform account.

The platform name alone doesn’t decide whether the message was authorised or fraudulent.

The common mistake is to identify a well-known sending provider and stop.

The provider is only the delivery layer.

The next question is which customer account, campaign or automated process used it.

Another mistake is to assume that unfamiliar Return-Path or DKIM domains prove deception. Third-party mail systems often need their own technical domains to manage delivery.

A careful report might say:

“The message was delivered through this platform and contains these campaign and customer identifiers. Further records are needed to identify the tenant, user or automated process that triggered it.”

That keeps the evidence at the right level.

When a mailing platform or CRM is involved, follow the message past the shared server and into the customer account and workflow behind it.

Key takeaway

Identify the platform, then identify the customer account, campaign, user or API process behind the particular message.

Source notes

Keep moving

Where this question leads

These links explain why the next page may matter, rather than presenting an undifferentiated list.