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.

Email Authentication Controls

Sender Policy Framework (SPF)

SPF is an email authentication protocol that allows domain owners to specify which mail servers (IP addresses or third-party providers) are authorized to send email on behalf of their domain.

Example of an SPF Record:

v=spf1 ip4:64.45.163.0/24 v=spf1 include:_spf.google.com include:sendgrid.net -all

• It is published as a DNS TXT record for the domain.

• Specifies allowed IP addresses and trusted third-party senders, e.g., Google and Sendgrid.

• The receiving SMTP server:

  • Looks up the sending domain's SPF record.

  • Compares the sending SMTP client’s IP address/domain with the authorized IPs or domains.

  • Passes or fails SPF validation.

• SPF Mechanisms - pass or fail the SPF check based on this evaluation:

  •  -all  Hard Fail - only listed IPs or domains are authorized; reject all others.

  • ~all Soft Fail - not authorized but accepted as suspicious (may go to spam).

  • +all Allow all servers, IPs, or domains. 

  • ?all Neutral - no policy specified.

Strengths:

• SPF records make it harder for attackers to imitate domains, reducing the likelihood of this phishing attack.

• Emails from domains without published SPF records may bounce or be marked as spam. Over time, this can hurt a domain's reputation and, thus, its ability to successfully deliver emails.

• If SPF and DMARC are correctly configured, DMARC policies will specify how to deal with emails that fail SPF checks, reducing spam and phishing attacks, and notify IT administrators who can respond accordingly to improve their security posture.

Limitations:

• SPF only checks the envelope sender (Mail From) address, not the From header users see.

• Attackers can manipulate the From header while passing SPF if they control the sending IP/Domain.

• Attackers can register lookalike domains with valid SPF records.

DomainKeys Identified Mail (DKIM)

DKIM is a cryptographic email authentication mechanism that ensures the integrity of email content and verifies that the message originated from an authorized domain.

The owner of the domain (and mailing system/service) generates a cryptographic private-public key pair.

The public key (DKIM Record) is published as a DNS TXT record: 

google._domainkey.example.com IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."

Just after the email is transferred to the MTA (from the MSA), it:

• Assembles the final headers (Date, From, To, Subject, Message-ID, etc).

• Creates hashes of the headers and body.

• Signs these hashes using the private key.

• Inserts the resulting DKIM-Signature header.

On the receiving MTA server:

• The server retrieves the public key via a DNS TXT query.

• Validates the signature.

• Confirms whether the headers and body remained unmodified in transit.

• If the email was modified, DKIM verification failed, and the receiving MTA determines what to do based on the DMARC policies.

The email below displays a few of the headers to look for during phishing email analysis. In the sample below, two DKIM-Signature headers are present and provide information on the signature generated for authentication. Multiple DKIM-Signature headers are allowed; focus on the one closest to the source during analysis.

Strengths

• DKIM assists with verifying the integrity of email body content.

• Validates the signing domain ownership.

• Survives email forwarding (if message is unaltered).

Limitations

• DKIM can be bypassed if used alone without DMARC.

• Attackers can register lookalike domains with valid DKIM records.

• It does not verify the visible From address (DKIM itself does not enforce identity alignment; it requires SPF).

Domain-based Message Authentication, Reporting & Conformance (DMARC)

DMARC builds on SPF and DKIM by enforcing alignment between the visible From: header and the authenticated domains validated by SPF and DKIM.

DMARC policy determines if authentication and integrity failures result in the email being marked as spam, blocked/rejected, or delivered to the intended recipient. The policies are established using machine-readable commands.

Like SPF and DKIM, DMARC policies are published as DNS TXT records for the respective domain. DMARC record example:

_dmarc.example.com IN TXT "v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:dmarc_reports@company.com"

Below is a breakdown of the available DMARC settings:

• v=DMARC1 Specifies that the domain has a TXT record with a DMARC policy and should be interpreted as such by mail servers.

• p=none Monitor only, no enforcement (emails can fail SPF and DKIM and still be delivered).

• p=quarantine Treat failed messages as suspicious and potentially spam.

• p=reject Block failed messages entirely.

• adkims=s DKIM strict alignments (domains must match exactly).

• adkims=r Relaxed domain DKIM checks (subdomains permitted).

• aspf=s Strict SPF alignment (domains must match exactly).

• aspf=r Relaxed SPF checks (subdomains permitted).

DMARC policies can contain instructions to send reports about emails that pass or fail DKIM or SPF. These reports provide administrators with the information they need to adjust their DMARC policies. For example, if legitimate emails fail SPF and DKIM checks, DMARC policies need to be adjusted accordingly.

v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:dmarc_reports@company.com;

• rua=: Aggregrate reports send as XML summaries.

• ruf=: Forensic reports with individual failed message samples (optional).

Strengths

• Prevents exact domain spoofing.

• Domains owners have visibility into spoofing attempts.

• Allows gradual policy enforcement based on the DMARC reports.

Limitations

• DMARC does not prevent lookalike domain attacks.

• Requires both SPF/DKIM to be correctly configured for maximum benefit and effect.

• Complex to fully deploy at enterprise scale (especially with third-party email providers).

Security Note: Publish SPF and DMARC records even for non-sending domains to prevent abuse.

References & Resources

Header Image: Photo by Brett Jordan on Unsplash 

RFC 5322: Internet Message Format

RFC 5321:  Simple Mail Transfer Protocol

RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1

RFC 6376: DomainKeys Identified Mail (DKIM) Signatures

RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)