Skip to content

Latest commit

 

History

History
73 lines (52 loc) · 5.42 KB

email-server-security.md

File metadata and controls

73 lines (52 loc) · 5.42 KB

Modern email servers employ several protection mechanisms to authenticate themselves and ensure the secure handling of messages. These mechanisms help prevent email spoofing, phishing, and unauthorized access, ensuring that emails are delivered securely and that their origins can be trusted. Here are the major mechanisms:

  1. Sender Policy Framework (SPF)
  • Purpose: SPF helps prevent email spoofing by allowing domain owners to specify which IP addresses or servers are authorized to send emails on behalf of their domain.
    • How It Works:
      • The domain owner publishes an SPF record in the DNS (Domain Name System).
      • When an email server receives an email, it checks the SPF record to verify that the email was sent from an authorized IP address.
      • If the sending server is not authorized, the email can be rejected or marked as suspicious.
  1. DomainKeys Identified Mail (DKIM)
  • Purpose: DKIM adds a digital signature to the email header, allowing the recipient to verify that the email was indeed sent by the claimed domain and that the content has not been altered in transit.
    • How It Works:
      • The sending mail server signs outgoing emails with a private key.
      • The corresponding public key is published in the sender's DNS records.
      • The recipient's server retrieves the public key and uses it to verify the signature.
      • A valid DKIM signature ensures that the email was sent by the claimed domain and has not been tampered with.
  1. Domain-based Message Authentication, Reporting, and Conformance (DMARC)
  • Purpose: DMARC builds on SPF and DKIM to provide a comprehensive policy for email authentication and handling. It helps prevent phishing and email spoofing by allowing domain owners to specify how emails that fail SPF or DKIM checks should be handled.
    • How It Works:
      • Domain owners publish a DMARC policy in their DNS records, specifying actions like "none" (monitoring), "quarantine," or "reject" for emails that fail SPF/DKIM checks.
      • The DMARC policy also includes options for sending reports back to the domain owner about emails that pass or fail these checks.
      • DMARC ensures alignment between the "From" header in the email and the domain validated by SPF/DKIM, adding another layer of security.
  1. Transport Layer Security (TLS)
  • Purpose: TLS ensures that the communication between email servers is encrypted, protecting the content of the emails from being intercepted or tampered with during transit.
    • How It Works:
      • When two email servers communicate, they negotiate the use of TLS to encrypt the session.
      • TLS certificates are used to authenticate the servers to each other, ensuring that the communication is secure.
      • This is particularly important for protecting the confidentiality and integrity of emails as they are transmitted over the internet.
  1. Authenticated Received Chain (ARC)
  • Purpose: ARC addresses the challenges that arise when an email passes through multiple intermediaries (like forwarding services), which can cause SPF or DKIM to fail. ARC allows intermediaries to sign their actions, preserving the original authentication results.
    • How It Works:
      • Each intermediary that handles the email adds its own ARC header, signing the results of SPF, DKIM, and DMARC checks it received.
      • The final recipient can verify the ARC chain to determine if the email’s authentication checks were intact throughout its journey, even if it was forwarded.
  1. Message Transfer Agent Strict Transport Security (MTA-STS)
  • Purpose: MTA-STS enforces the use of TLS encryption between email servers and prevents downgrade attacks where a malicious actor tries to force an email server to fall back to unencrypted communication.
    • How It Works:
      • The receiving domain publishes an MTA-STS policy via DNS, indicating that incoming emails should only be accepted over TLS-encrypted connections.
      • Sending servers check this policy and refuse to deliver emails if they cannot establish a secure TLS connection.
  1. DNS-Based Authentication of Named Entities (DANE)
  • Purpose: DANE ensures that the certificates used for TLS encryption in email server communication are valid and trusted, preventing man-in-the-middle attacks.
    • How It Works:
      • DANE relies on DNSSEC (DNS Security Extensions) to publish TLSA records in DNS.
      • These TLSA records specify the certificates that should be used when establishing a TLS connection with the email server.
      • The sending server checks these records before initiating a TLS session, ensuring that the encryption is trusted.
  1. STARTTLS
  • Purpose: STARTTLS is a command used to upgrade an existing plain-text connection to a secure, encrypted connection using TLS. It is widely supported by email servers to protect emails in transit.
    • How It Works:
      • During the initial connection between two email servers, STARTTLS is issued to initiate a TLS handshake.
      • If both servers support TLS, the connection is encrypted, ensuring secure email transmission.

Summary:

  • SPF, DKIM, and DMARC work together to authenticate the origin of emails and prevent spoofing and phishing.

  • TLS, MTA-STS, and DANE ensure secure transmission of emails, protecting them from interception and tampering.

  • ARC helps maintain authentication results even when emails are forwarded or pass through intermediaries.

These mechanisms collectively enhance the security and trustworthiness of modern email communication, protecting both the servers and the messages they handle.