Email Flow and Security Protocols

Business Cybersecurity
Written By Jonathan Kilby
AI Generated Image of envelopes stacked like a pyramid with lock icons to signify security.

Most small office/home office, a.k.a. SOHO, businesses utilize a 3rd party like Google’s Gmail to send and receive emails for their business. These tools do not provide a lot of customization or tuning of how emails can flow. This blog post is going to cover how a majority of medium to large scale companies’ email flows work and some security considerations.

What happens when you send an email?

This section will walk through the various aspects of how emails work. Starting from the basics and progressively getting into more technical details.

Simple Mail Transfer Protocol (SMTP)

This is the underlying foundation of how emails are sent and received. There are multiple steps that happen:

  • Connection Establishment

    • The typical TCP port that is used for SMTP is port 25

    • An email client, like Outlook or Gmail, opens the connection to the server

  • Handshake

    • There are two types of handshakes

      • HELO

        • The original SMTP command

        • Limited to single line response

        • Limited functionality

      • EHLO

        • Extended HELO that supports Extended SMTP (ESMTP), an enhanced version of SMTP

        • Multi-line response capabilities

        • Enhanced functionality

    • Most modern mail servers are using the EHLO handshake and ESMTP since these both allow the authentication, size limits, and more functionality

  • Mail Transfer

    • This is where the email magic happens, the email client sends the following commands

    • MAIL FROM

      • This command tells the server who is sending the email

    • RCPT TO

      • This command tells the server who is receiving the email

    • DATA

      • This command tells the server the content of the email

        • Things like the date, subject, email body, etc

  • Mail Transfer Agent (MTA)

    • This starts with the original SMTP server processing the email

    • If the RCPT TO is domain that the SMTP server houses, the email is sent to the recipient

    • If the RCPT TO is a domain outside of the SMTP server, it will query DNS to find the recipients mail server

  • Forwarding

    • This is the process of the original SMTP server sending the email to the recipients SMTP server via the same exact methods above

    • It can involve multiple MTAs if there are multiple servers it has to go through

  • Delivery

    • The recipients SMTP server receives the email and stores it until it is retrieved by an email client, such as Outlook or Gmail

  • Connection Closure

    • Once the email is successfully set, the original client sends the QUIT command to close the connection

Email Specific DNS Records

Mail Exchange (MX) Records

These are records that are located in your Domain Name System (DNS) servers. They tell sending SMTP servers where to your domain’s mail servers exist.

The majority of medium to large organizations’ MX record point to some form of Secure Email Gateway (SEG), such as Mimecast, Proofpoint, FortiMail, etc. Some might point directly to Microsoft Exchange (Cloud [MS365] or On-Prem [Exchange]), Google Workspace (Business Gmail), etc.

If you want to check what MX records exist for your company, there are plenty of free sites that help. My personal favorite is MXToolbox, https://mxtoolbox.com/MXLookup.aspx. They also offer a bunch of other tools in their “Super Tool” that help troubleshoot/query the majority of DNS record types.

Sender Policy Framework (SPF)

This is a specific type of TXT (Text) record that indicates what IP addresses are allowed to send emails on behalf of your domain.

Here is an example of an SPF record that we can disect:

v=spf1 ip4:192.0.2.0/24 include:_spf.google.com -all

  • v=spf1: Specifies the version of SPF being used.

  • ip4:192.0.2.0/24: Authorizes the specified IPv4 address range to send emails on behalf of the domain.

  • include:_spf.google.com: Authorizes servers listed in the SPF record of the specified domain (in this case, Google’s) to send emails on behalf of your domain.

  • -all: Indicates that emails from unauthorized servers should be rejected.

Some things to pay attention to:

  • DNS Lookup Limit: An SPF record can have a maximum of 10 DNS lookups. This includes mechanisms like include, a, mx, ptr, exists, ip4, and ip6123.

  • Character Limit: Each DNS TXT record, which includes SPF records, has a character limit of 255 characters per string. However, multiple strings can be concatenated to form a longer SPF record4.

  • Mechanism Limits: While there isn’t a specific limit on the number of ip4, ip6, or exists mechanisms, they all contribute to the overall 10 DNS lookup limit. Therefore, you need to manage these mechanisms carefully to stay within the limit.

Most large organizations utilize some form of SPF Delegation service, such as DMARC Analyzer, AutoSPF, PowerDMARC, or others to ensure their SPF records are compliant. The larger the organization becomes; the more 3rd parties are bought that send emails as if they are coming from the organization’s domain, quickly surpassing the limits of manually maintaining the SPF record.

The tools vary in how they handle the front end, but underneath the hood they all function relatively in the same manner.

They take your DNS Lookups, think include:_spf.google.com, and convert them the underlying IP4 or IP6 addresses instead of the DNS Lookup. They will ensure that your record does not go over the character limit. This is achieved via utilizing an include: at the end of the record that points to the next page of IP4 and IP6 addresses.

Here is a trivial example of how it works. Imagine the initial SPF record is _spf.example.com and it looks something like this:

v=spf1 ip4:192.0.2.1/32 ip4:192.0.2.2/32 ip4:192.0.2.3/32 include:_spf2.example.com -all

Since this record has the include:_spf2.example.com, it will consume a single DNS lookup and bring the IP4 and IP6 addresses over. Here is that second include:_spf2.example.com

v=spf1 ip4:192.0.2.4/32 ip4:192.0.2.5/32 ip4:192.0.2.6/32 -all

Domain Keys Identified Mail (DKIM)

DKIM is a form of public-key cryptography. The sending mail server holds the private key to generate a digital signature of the email. Then a public key is published in the domain’s DNS server as a TXT record. The combination of both of these allows the receiving server to verify the integrity of the email.

As an example let’s assume we have the following TX record: s1._domainkey.example.com with a value of v=DKIM1; g=*; h=sha256:sha1; k=rsa; n=notestohumans; p=Tm9ybWFsbHkgSSdkIGJlIFJTQSBlbmNyeXB0ZWQsIGJ1dCB0aGUgd3JpdGVyIGlzIGxhenkgYW5kIGp1c3QgQmFzZTY0J2QgbWUgaW5zdGVhZC4=; s=email; t=s

This table explains each element:

Element Meaning Required
v=DKIM1 v=version number. Default "v=DKIM1". There is only one DKIM version published so always DKIM1. Anything else is ignored No, but recommended
g=* g=granularity of the key. Defaults to "g=*" if not set. The intent of this element is to limit which signing addresses can legitimately use this selector, for example, when delegating a key to a 3rd party for special purposes. Wildcarding allows matching such as "user+*" or "*-offer". An empty "g=" never matches any addresses No
h=sha256:sha1 h=acceptable hash algorithms. Defaults to allow all algorithms. A colon separated list of hash algorithms that might be used No
k=rsa k=key type. Default "k=rsa" if not set. both signers and verifiers MUST support "rsa" key types, but can theoritically change to others No
n=notestohumans n=Notes to human readers. Not recommended to use, only intended to be used by amdins, not end users No, not recommended
p=Tm9yb......GVhZC4= p= Public-key data. base64 encoded version of the data defined by the "k=" tag Yes
s=email s= Service Type. Default is "s=*". Colon separated list of service types to which the record applies No
t=s t= Flags. Default "t=" meaning none set. "t=y" indicates domain is testing DKIM. "t=s" indicates the DKIM-Signature header fields using the "i=" tag MUST have the same domain value on the right-hand side of the "@" in the "i=" tag and the value of the "d=" tag. No, Recommended unless subdomaining is required

It puts the hashed values as a header in the email along with the fields it used to generate the signature, the algorithm used, and other fields. An example of the header would look something like this:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; c=relaxed; q=dns/txt; t=1725644732; x=1725731132; h=from:to:subject:date:header1:headerx; bh=SWYgeW91IGFyZSBjdXJpb3VzIGFuZCBmb3VuZCB0aGlzLiBMZWF2ZSBhIGNvbW1lbnQh; b=5d913195f8717b37431615fe16fe90e1f48b56d2df417b8ef5cdb86051ac5d88

The following table describes each element of the header:

Element Meaning Required
v=1 v=version number. There is only one DKIM version published so always 1 Yes
a=rsa-sha256 a=hashing/signing algorithm. There are a lot of options, but some older mail servers may only support rsa-sha or rsa-sha256 Yes
d=example.com d=signing domain. This tells the receiving mail server where to look for the public key Yes
s=s1 s=selector. This is the TXT record in the sending domains DNS server No
c=relaxed c=header canonicalization/body canonicalization. Default: "c=simple/simple". One value set as "c=relaxed" indicates "c=relaxed/simple". Can set "c=relaxed/relaxed". Simple means no changes can be made to headers. Relaxed means it can tolerate some minor changes such as case/whitespace in the header names. Simple for the body ignores all empty lines at the end. Relaxed for body will reduce all sequences of whitespace within a line to a single space character. Simple for the body is more secure. No
q=dns/txt q=colon separated list of query methods. Default "q=dns/txt". Format is "type[/options]". Current only valid option is "dns/txt" No
t=1725644732 t=Signature Timestamp. It is an unsigned integer that represents the number of seconds since EPOCH (00:00:00 on January 1, 1970). No, but recommended
x=1725731132 t=Signature Expiration. It is an unsigned integer that represents the number of seconds since EPOCH (00:00:00 on January 1, 1970). No, but recommended
h=from:....:headerx he= Signed header fields. Colon separated list of header field names presented to the signing algorithm. Must be the headers presented in the same order as provided to the signing algorithm. Yes
bh=SWYg....bnQh bh=Hash of canonicalized body as limited by the "l=" tag. It is a base64 respresentation of the hash. Yes
b=5d91....5d88 b=Base64 of signature data. Base64 of the signature Yes

The receiving mail server requests the public key from your domain’s DNS server. It uses the key and fields in the signature header to generate new signatures to compare with the original signatures. If everything matches, the receiving mail server will mark it as passing DKIM.

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

DMARC is an email authentication protocol that builds on SPF and DKIM to provide a more comprehensive way to protect email domains from unauthorized use, such as phishing and email spoofing. Here’s how it works:

  1. Policy Definition: Domain owners publish a DMARC policy in their DNS records. This policy specifies how to handle emails that fail SPF and DKIM checks. The policy can instruct receiving mail servers to reject, quarantine, or accept emails that fail these checks.

  2. Alignment: DMARC ensures that the domain in the “From” header matches (or aligns with) the domains authenticated by SPF and DKIM. This alignment can be strict (exact match) or relaxed (organizational domain match).

  3. Verification: When an email is received, the receiving mail server checks the DMARC policy of the sender’s domain. It verifies that the email passes SPF and/or DKIM checks and that the domains align as specified by the DMARC policy.

  4. Action: Based on the DMARC policy, the receiving server takes action on emails that fail the checks. This can include rejecting the email, quarantining it, or allowing it through with a warning.

  5. Reporting: DMARC provides a reporting mechanism that allows domain owners to receive feedback on emails that pass or fail DMARC checks. This helps them monitor and improve their email authentication practices.

A typical DMARC record might look like this:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-failures@example.com; adkim=s; aspf=s

  • v=DMARC1: Specifies the DMARC version.

  • p=reject: Policy for handling failed emails (reject, quarantine, or none).

  • rua: Aggregate reports email address.

  • ruf: Forensic reports email address.

  • adkim=s: DKIM alignment mode (s=strict or r=relaxed).

  • aspf=s: SPF alignment mode (s=strict or r=relaxed).

DMARC helps improve email security by ensuring that only legitimate emails are delivered and providing domain owners with valuable insights into email authentication issues.

Brand Indicators for Message Identification (BIMI)

BIMI is an email authentication standard that allows brands to display their logos in email clients, enhancing brand recognition and trust. Here’s how it works:

  1. Verified Mark Certificate (VMC): To use BIMI, a brand must obtain a Verified Mark Certificate, which verifies the ownership of the logo and domain.

  2. DNS Record: The brand publishes a BIMI record in their DNS. This record includes the URL of the brand’s logo, which must be in SVG format.

  3. Email Authentication: BIMI works in conjunction with DMARC. The email must pass DMARC authentication (including SPF and DKIM checks) for the logo to be displayed.

  4. Logo Display: When an email passes DMARC checks, the email client retrieves the logo from the URL specified in the BIMI record and displays it next to the email in the recipient’s inbox.

A typical BIMI record might look like this:

DNS TXT Record: default._bimi.example.com

v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem

  • v=BIMI1: Specifies the BIMI version.

  • l: URL of the brand’s logo in SVG format.

  • a: URL of the Verified Mark Certificate.

BIMI helps enhance email security and brand visibility by allowing recipients to quickly identify legitimate emails from trusted brands.

Conclusion

The journey of an email from sender to recipient involves a series of intricate steps and protocols. From the initial connection establishment using SMTP, through the handshake and mail transfer processes, to the final delivery and connection closure, each phase plays a crucial role in ensuring the successful transmission of emails. Additionally, understanding the importance of email-specific DNS records like MX, SPF, DKIM, and DMARC helps in enhancing email security and deliverability. By grasping these concepts, you can better appreciate the complexity and reliability of email communication in our digital age.

Comments are welcome. Keep them on topic and civil.

Jonathan Kilby