Email Fields

Overview

The email fields describe properties of electronic mail (email) messages as observed in telemetry or event data. They represent logical components of an email object, including sender and recipient information, message routing, and content-related metadata. These fields support consistent modeling of email-related events across different log sources and security platforms.

Design and Usage

The email entity provides a standardized structure for representing email message attributes that may originate from mail servers, gateways, or endpoint telemetry. It enables normalization of diverse vendor data into a coherent schema, capturing both message-level details (such as headers, identifiers, and message size) and contextual attributes (such as directionality and originating IP). As a top-level entity, email should be modeled independently of transport or network-layer entities, while maintaining references to related actors or systems through linking identifiers when available.

Common Use Cases

  • Correlating sender, recipient, and message identifiers across security telemetry to detect phishing or data exfiltration activity.
  • Analyzing attachment metadata for malware detection or suspicious file transfer analysis.
  • Mapping inbound and outbound message flows to determine lateral or cross-domain communication within an organization.
  • Enriching message-level data for content inspection, policy enforcement, or compliance logging.

Implementation Notes

As a top-level entity, email defines a self-contained conceptual object representing an email message. It should be modeled independently of vendor-specific schema variations, supporting hierarchical or relational mappings to entities such as user, network, or file when applicable. email fields may appear in conjunction with related entities to clarify event semantics and maintain relational integrity within normalized telemetry. If an associated network or file entity is implied but not explicitly defined, corresponding fields should be included to ensure directional and contextual consistency.

field field_type description example_values

email_attachment_file_name

keyword

The file name(s) of an attachment.

attachment.exe

email_attachment_file_size

long

The size in bytes of the attachments.

1024

email_bcc

keyword

The email address of BCC recipient/email.

corp_user@corp.local

email_cc

keyword

The email address of CC recipient/email.

corp_user@corp.local

email_delivered_to

keyword

The Delivered-To email header field.

corp_user@corp.local

email_direction

keyword

Indicates the direction of the observed email flow. Must be either inbound, outbound or lateral, this should be mapped to these values if vendors provide network direction differently.

inbound, outbound, lateral

email_from

keyword

Per RFC 5322, specifies the address responsible for the actual transmission/sender of the message.

corp_user@corp.local

email_message_id

keyword

The globally-unique message identifier.

CAD78=PvAb+iLQ6x+221MGa-22@mail.gmail.com

email_raw_header

keyword

The email authentication header.

email_reply_to

keyword

The address that replies should be delivered to based on the value in the RFC 5322 Reply-To: header.

corp_user@corp.local

email_size

long

The size of an email in bytes.

234

email_subject

keyword

The email subject.

RE: FWD: Testing

email_to

keyword

The email address of recipient/email.

corp_user@corp.local

email_uid

keyword

The email unique identifier internally used by an email software to track a message.

123456789A

email_x_originating_ip

keyword

The X-Originating-IP header identifying the email's originating IP address(es).

192.168.2.3

email_xmailer

keyword

Tool that created and sent the email.

spambot