Skip to content
EML-045 Email Evidence

Worked example: a message generated by a CRM or mailing platform

title: 'Worked example: a message generated by a CRM or mailing platform' subtitle: The email is genuine, but the person named in From may not have written or sent the individual message. slug: worked-example-message-generated-by-a-crm-or-mailing-platform series: email-evidence section: worked-examples card_type: worked_example pathway_order: 47 section_order: 3 status: draft public_safe: true video_ready: true word_count: 474 estimated_read_time_seconds: 196 audiences: - investigator - supervisor - fraud and compliance practitioner tags: - email evidence - worked example - CRM - mailing platform - automation sources: - title: 'Microsoft Learn: Email entity page in Defender for Office 365' url: https://learn.microsoft.com/en-us/defender-office-365/mdo-email-entity-page - title: 'Microsoft Learn: Message trace in the Microsoft Defender portal' url: https://learn.microsoft.com/en-ca/defender-office-365/message-trace-defender-portal - title: 'Google Workspace Admin Help: Troubleshoot message delivery with Email Log Search' url: https://support.google.com/a/answer/7513679?hl=en-GB

Worked example: a message generated by a CRM or mailing platform

The email is genuine, but the person named in From may not have written or sent the individual message.

Script

A customer receives an email appearing to come from a named account manager.

The message contains information about their real account and says that a service has been cancelled.

The account manager says they didn’t write or send it.

The header shows that the message travelled through a well-known customer-management platform.

That doesn’t automatically mean the email is false.

The organisation may have authorised the platform to send through its domain.

DKIM and DMARC may pass.

The From address may show the account manager because the platform was configured to personalise messages using the assigned staff member’s details.

The first question is whether the platform and organisation recognise the message.

Preserve the original email, complete header, Message-ID and any platform-specific identifiers.

Look for campaign IDs, template IDs, customer IDs, event IDs, tracking identifiers and a platform-controlled Return-Path.

The organisation checks its CRM and finds a workflow.

When an account status changes to “cancelled”, the system sends an email using a template.

The named account manager appears automatically in the From display and signature.

The message was triggered when another staff member changed the customer record.

No person typed the final message or pressed Send.

What does the evidence show?

The platform generated and delivered a genuine organisational communication.

The named account manager wasn’t necessarily the author or operator.

The useful attribution sits in the workflow history.

Which customer record changed?

Which user or integration made the change?

Which template version was active?

Was the workflow correctly configured?

Did an API, batch process or human user trigger the status update?

Could the action have been accidental or unauthorised?

The sending server’s IP address won’t normally answer those questions.

It belongs to shared platform infrastructure.

Provider and platform logs need to link the specific Message-ID or campaign identifier to the customer tenant, workflow and triggering event.

Suppose the audit history shows that an automated billing integration changed the account status after a failed payment.

The workflow then sent the cancellation email exactly as configured.

The account manager’s denial is true.

The email is also genuine.

The issue is a business-process or system decision, not spoofing or account compromise.

Now change the conclusion.

“The email was generated by the organisation’s authorised CRM after this recorded account event. The named account manager’s details were inserted automatically from the customer record.”

That explains both sides.

The message came from the organisation.

The individual named in it didn’t personally compose it.

The common mistake is to choose between only two possibilities:

the named person sent it;

or the email was fake.

Automation creates a third possibility.

A genuine system can send a real message using a person’s identity without that person taking an individual action.

The investigative route is to follow the platform identifiers into the tenant, workflow, template and trigger.

That is where the responsibility and explanation usually sit.

Key takeaway

Identify the customer account, workflow, template and trigger behind the platform rather than stopping at the shared sending server.

Scenario at a glance

  • Displayed sender: named employee.
  • Delivery route: authorised CRM or mailing platform.
  • Authentication: may pass for the organisation’s domain.
  • Platform evidence: campaign, template, customer and event identifiers.
  • Trigger: customer record change, API event or automated workflow.
  • Human role: may sit in configuration or earlier data entry rather than pressing Send.
  • Correct conclusion: genuine organisational message, automatically generated.

Source notes

Keep moving

Where this question leads

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