Could an automated system have generated the message?¶
title: Could an automated system have generated the message? subtitle: Email can be created and sent by applications, workflows, APIs and scheduled processes without a person composing each message. slug: could-an-automated-system-have-generated-the-message series: email-evidence section: evidential-limits-and-corroboration card_type: question_card pathway_order: 39 section_order: 5 status: draft public_safe: true video_ready: true word_count: 568 estimated_read_time_seconds: 235 audiences: - investigator - supervisor - fraud and compliance practitioner tags: - email evidence - automation - API - workflow - authorship sources: - title: 'Microsoft Learn: user sendMail' url: https://learn.microsoft.com/en-us/graph/api/user-sendmail?view=graph-rest-1.0 - title: 'Microsoft Learn: Microsoft Graph permissions reference' url: https://learn.microsoft.com/en-us/graph/permissions-reference - title: 'Google for Developers: Gmail users.messages.send' url: https://developers.google.com/workspace/gmail/api/reference/rest/v1/users.messages/send - title: 'Google for Developers: Create and send email messages' url: https://developers.google.com/workspace/gmail/api/guides/sending
Could an automated system have generated the message?¶
Email can be created and sent by applications, workflows, APIs and scheduled processes without a person composing each message.
Script¶
An email may look personal even though no person sat down and typed that particular message.
Applications, workflows and APIs can create and send email automatically.
That includes:
password resets;
purchase confirmations;
fraud alerts;
calendar notifications;
customer-service updates;
marketing campaigns;
scheduled reports;
monitoring alerts;
and messages triggered by changes in another system.
A customer-management platform may combine a template with data from a customer record.
A workflow may send when an invoice reaches a particular stage.
An application may use an API to send as a user or shared mailbox.
A scheduled process may generate a report and email it to a distribution list.
A human may have designed, approved or triggered the process earlier, but not composed each individual message at the moment it was sent.
This changes the attribution question.
The email may genuinely come through the organisation’s provider.
SPF, DKIM and DMARC may pass.
The message may appear in Sent Items.
The visible From address may belong to a real employee or team.
None of that proves that the named person personally wrote or pressed Send on that particular email.
Look for indicators of automation.
The Message-ID, Return-Path, DKIM domain and Received chain may point towards a platform.
Provider-specific headers may contain campaign, template, workflow, event, transaction or application identifiers.
The content may follow a repeated structure.
Timestamps may align with a schedule or system event.
Several recipients may receive near-identical messages.
The message may use a no-reply address or a reply address routed into a ticketing system.
But don’t rely only on appearance.
A person can use a template.
An automated message can be written in conversational language and display an employee’s name.
The useful evidence sits behind the message.
Ask which service submitted it.
Was an API, application credential or service account used?
Which tenant or customer account owned the process?
Which workflow, campaign or template produced it?
What event triggered the message?
Was there a user action immediately before the trigger?
Who created or edited the workflow?
Could several staff members operate it?
Did the system run under an application permission rather than a signed-in user?
Modern email APIs allow software to create and send messages. Some application permissions can allow an approved app to send through specified organisational mailboxes without a person interactively signed in at that moment.
That doesn’t make the message unauthorised.
It means authorship and responsibility may sit at several levels.
One person may write the template.
Another may configure the recipients.
A customer event may trigger the workflow.
An application may assemble the final text.
A service account may submit it.
The email provider may deliver it.
The common mistake is:
“The email came from this account, so the account holder typed it.”
Another is:
“It was automated, so nobody is responsible for it.”
Automation moves the decision point. It doesn’t necessarily remove human involvement.
A careful conclusion might say:
“The message was generated and sent by this application using this mailbox or API permission after this recorded event.”
You can then ask who configured, authorised, changed or triggered the process.
Preserve application logs, audit records, workflow history, template versions, API identifiers, campaign data and the business record that generated the event.
An automated message can be genuine, malicious, mistaken or unauthorised.
The email header may identify the sending system.
To understand the human role, follow the process back to the account, configuration and trigger behind it.
Key takeaway
A genuine account and valid authentication may identify the authorised system, while the real decision point sits in a workflow, API call or earlier human action.
Related questions¶
- Can an email identify the person who wrote it?
- What if the message came through a mailing platform or customer-management system?
- What account-access records may exist?
- Does successful DKIM prove the named sender wrote it?
Source notes¶
- Microsoft Learn: user sendMail
- Microsoft Learn: Microsoft Graph permissions reference
- Google for Developers: Gmail users.messages.send
- Google for Developers: Create and send email messages