Electronic Mail (email)

It is a communication method that delivers messages across a digital network; it refers to both the delivery system and individual messages sent and received.

Email systems use various servers to deliver messages through a store-and-forward model.

Email System Core Components

1. Mail User Agent (MUA): 

   • Client software used to send and receive emails.

   • Examples: Microsoft Outlook, Apple Mail, Thunderbird, Gmail web interface (web browser).

   • Interacts with the mail server via SMTP, IMAP, or POP3.

2. Mail Submission Agent (MSA):

   • Subcomponent that handles outgoing emails from clients before handing them off to the MTA.

   • Often uses SMTP on port 587 (authenticated submission).

3. Mail Transfer Agent (MTA):

   • Server software that sends, routes, and relays emails between servers.

   • Responsible for delivering email to the recipient’s mail server.

   • Examples: Postfix, Exim, Sendmail, Microsoft Exchange Transport, Mailgun, Amazon SES.

4. Mail Delivery Agent (MDA):

   • Accepts mail from the MTA and delivers it into the recipient's mailbox.

   • Examples: Procmail, Maildir, Exchange Mailbox Transport.

5. Directory Services:

   • Used for authentication and address resolution.

   • Examples: Active Directory, Microsoft Entra ID, LDAP.

6. Security Layers:

   • Spam filters, antivirus engines, Secure Email Gateways (SEG), encryption layers, and authentication (SPF, DKIM, DMARC).

Email Messaging Event Sequence

The following sequence assumes that a user is sending an email from their organization (or email service, e.g., Gmail) to another organization (or email service, e.g., Yahoo Mail).

If a user sends an email to another person within their organization, steps 2 and 3 are skipped. In this case, the sending and receiving MTA servers are the same, and thus, the email is stored until the receiving user’s MUA retrieves it from the MTA.

1. User Sends an Email

   • A user composes an email using their MUA.

   • The MUA connects to its respective MSA.

   • The sender authenticates the user (username/password, OAuth, etc.)

   • The MSA forwards the email to the organization’s MTA for outbound delivery.

2. DKIM Signature

   • The MTA receives the email from the MSA with all headers fully formed and before DNS lookup:

     • Canonicalizes the email headers/body.

     • Hashes the selected headers and body.

     • Uses the sender domain’s private DKIM key to generate the signature.

     • Inserts the DKIM-Signature header into the message.

3. DNS Lookup

   • The source MTA attempts to locate the recipient’s mail server.

   • It queries the DNS record for the recipient domain’s Mail Exchange (MX) records.

   • The MX record specifies:

     • The hostname(s) of the recipient mail server.

     • Priority, if multiple servers exist.

   • The MTA resolves the recipient's mail server IP via DNS A or AAAA records.

4. SMTP Relay

   • The sending MTA establishes a connection to the recipient’s MTA.

   • SMTP handshaking occurs:

     • HELO or EHLO commands (SMTP commands to open communication).

     • Sender and recipient email addresses are exchanged.

     • Data transfer begins (headers, body, attachment).

   • The message is queued for delivery at the recipient server.

5. Recipient Delivery

   • The recipient’s MTA passes the email to the MDA.

   • The MDA stores the email in the appropriate mailbox.

6. Recipient Accesses the Email

   • The recipient opens their MUA.

   • The MUA retrieves the recipient’s email from the MDA via:

     • IMAP (recommended; allows server-side storage and synchronization).

     • POP3 (downloads and usually deletes email from the server)

Email Protocols

Several protocols facilitate sending, delivery, retrieval, and synchronization of emails.

The three core protocols involved are:

Simple Mail Transfer Protocol

• SMTP is the primary protocol used to send email messages.

• SMTP transfers emails from user MUAs to the MSA usually on port 587 (for authenticated submission).

• The MSA performs its authentication process and forwards the email to the MTA, which performs DNS lookups to locate the recipient server.

• The source MTA uses SMTP (usually port 25 for server-to-server transmission) to deliver the email to the recipient MTA.

• SMTP can support secure transmission using STARTTLS or implicit SSL/TLS on port 465 (SMTPS), but this is not mandatory unless enforced by policy.

• Security Note: SMTP was not initially designed for security; encryption, authentication, and anti-spoofing measures (SPF, DKIM, DMARC) are implemented as extensions.

Internet Message Access Protocol

• IMAP allows users (via their MUAs) to retrieve from and synchronize their email messages with the mail server.

• After SMTP delivers the email to the recipient’s mail server, that server stores the email message.

• The recipient user’s MUA connects to the MDA using IMAP port 143 (unencrypted) or 993 (encrypted).

• In summary, IMAP enables real-time synchronization between the mail server and multiple client MUA devices (laptop, smartphone, tablet, etc.), allowing users to access the same email account while keeping the folder structure, un/read status, and message flags consistent.

• Security Note: IMAP is preferred in most enterprise environments because it supports synchronization and leaves a master copy of emails on the server for backup, compliance, and monitoring.

Post Office Protocol Version 3 (POP3)

• POP3 allows users (via MUAs) to download email messages from the mail server to their local device.

• The MUA connects to the mail server on port 110 or 995 (for encrypted POP3 over SSL/TLS).

• Unlike IMAP, POP3 typically downloads messages and then deletes them from the server, meaning emails are only accessible on the device they were downloaded to (unless configured to “leave copy on server”).

• POP3 does not support server-side folder structure or multi-device synchronization.

Security Note: Due to its limitations, POP3 is obsolete mainly in modern enterprise environments, but it may appear in legacy systems or personal setups. 

Local Part

• The local part comes before the @ symbol and specifies the final destination mailbox within the recipient's domain.

• It can represent an individual user (e.g., john.smith@company.com), departmental addresses (e.g., support@company.com), or aliases.

• Valid characters include letters, numbers, periods, hyphens, underscores, and certain special characters, though some are discouraged for compatibility reasons.

• The local part is case-sensitive in theory, but most modern mail systems treat it as case-insensitive.

Security Note: Attackers may attempt to exploit slight variations in the local part (e.g., john.smi1th@company.com) for spear-phishing or social engineering.

Domain

• The domain part appears after the @ symbol and identifies the mail server responsible for accepting and routing the message.

• Domains are typically Fully Qualified Domain Names (FQDNs), such as company.com.

• In some rare, legacy cases, email addresses may reference IP addresses directly (e.g., user@[192.0.2.1]), but this is uncommon in modern systems.

• The domain is resolved via DNS MX (Mail Exchange) records, which direct the sending server to the appropriate receiving mail server.

• The domain portion also defines the DNS namespace where email security records are published for authentication protocols such as SPF, DKIM, and DMARC.

• Security Note: 

  • Top-Level Domains (TLDs) - attackers often register malicious lookalike domains with different TLDs to bypass security controls.

  • Security teams should monitor for domains using visually similar characters or alternative TLDs to impersonate legitimate organizations.

Email Message Components

Every email has three primary parts - SMTP Envelope, Header, and Body.

SMTP Envelope

• This refers to the metadata exchanged between sending and receiving MTAs during SMTP transactions.

• The purpose of the SMTP Envelope:

  • Routing contains information that mail servers use to determine how to route the email to its destination.

  • Delivery Tracking - helps track the email's journey and identify any delivery issues.

  • Non-Delivery Reports (NDRs) - includes the return-path, used for notifications in cases where the email cannot be delivered.

• It contains delivery-specific addresses:

  • MAIL FROM - the return path or envelope sender (used for bounce handling).

  • RCPT TO - the intended recipient.

• This envelope information can differ from the From and To headers seen by the end user. 

• The envelope is recreated at each SMTP hop; it is not part of the final message stored in the recipient’s mailbox.

• Security Note: SPF validation is based on the envelope sender (MAIL FROM), not the From header.

Email Header

The header contains both mandatory and optional fields describing the email message and its journey. These fields are visible to the email client and used by security tools for filtering and analysis.

Common Header Fields

• Date - Date and time the message was sent (mandatory).

• From - The sender's email address is displayed to the recipient (mandatory).

• To -  Recipient's email address (mandatory).

• Subject - Summary of email content.

• Carbon Copy (Cc) - Additional recipients; visible to all.

• Blind Carbon Copy (Bcc) -  Additional recipients; hidden from others.

• Reply-To - Overrides the default reply address.

• Return-Path - Indicates where bounce messages (non-delivery reports) are sent.

• Message-ID - Unique identifier assigned by the originating MTA; should be globally unique. It may indicate the domain or IP address of the email source. Duplicate Message-IDs should not exist within the email gateway; if present, a malicious email campaign may be underway.

Authentication Headers

• DKIM-Signature

  • Contains the cryptographic signature generated by the sender's MTA using the private DKIM key. It includes:

    • Signed headers (e.g., From, Subject, Date).

    • Canonicalization methods.

    • Hash of the message body.

    • Selector and domain info for DNS public key lookup.

  • Authentication-Results: This section displays the results of email authentication checks (SPF, DKIM, and DMARC). It is critical for forensic analysis and filtering decisions.

Additional Headers 

• ‘X’ Type Headers -

  • Custom headers added by security tools, anti-spam filters, or MTAs for additional metadata, e.g., X-Spam-Score and X-Sender-IP.

  • X-Sender IP - typically indicates the IP address of the server from which the email originated and is added by either the MUA or MSA.

• Received Headers -

  •  Shows the full SMTP relay path; the MTAs the email traversed before reaching its destination.

  • They are added in reverse chronological order.

  • Read bottom to top; the first (lowest) entry represents the originating server.

  • Higher entries (near the recipient) are typically more trustworthy for analysis.

Security Note: Received headers can be spoofed for earlier hops; analysts should prioritize headers added by trusted internal MTAs when investigating phishing attempts.

Email Body

• The email body contains the message content visible to the recipient.

• It may include plain text, HTML-formatted text, embedded images, links, multimedia, or file attachments.

• Multipurpose Internet Mail Extensions (MIME) format structures different content types within the email body.

• If the email consists only of headers (e.g., delivery status notifications), the body may be entirely empty.

Security Note: Attachments and embedded links are common delivery mechanisms for phishing payloads and malware. Security solutions often scan MIME parts for malicious content.