How SPF, DMARC and DKIM work in Email.cloud

Products

• Email Security.cloud

Issue/Introduction

This article describes how Email Security.cloud handles SPF, DKIM and DMARC, coupled with the respective override options within the portal, which can alter an active result into a different outcome.

Environment

Email Security.Cloud

Resolution

Here is a breakdown of SPF, DKIM and DMARC:

 

SPF (Sender Policy Framework):

What it is: SPF is an email authentication protocol that allows the owner of a domain to specify which mail servers they use to send mail from that domain.

How it works:  Sender publish SPF record in the Domain Name System (DNS). This record lists which IP addresses are authorized to send email on behalf of that domain.

During an SPF check, email providers verify the SPF record by looking up the domain name listed in the “envelope from” address in the DNS. If the IP address sending email on behalf of the “envelope from” domain isn’t listed in that SPF record, the message fails SPF authentication.

Note: Absence of SPF record will result in SPF related actions as defined in the ESS service to not be followed through, since these only apply against an active record with a fail action "-all" flag. For the means of alignment as it relates to DMARC, absence of SPF will result in SPF alignment to be treated as fail.  

DKIM (DomainKeys Identified Mail):

What it is: DomainKeys Identified Mail (DKIM) is a protocol that allows an organization to take responsibility for transmitting a message in a way that can be verified by mailbox providers. This verification is made possible through cryptographic authentication.

Note: Absence of DKIM record as it relates to DMARC for the means of record alignment, will result in DKIM alignment to be treated as a fail.  

         How it works: 

Step 1: Identifying what message elements to sign with DKIM

First, a sender decides which elements of the email they want to include in the signing process. They can decide to include the whole message (header and body) or just focus on one or more fields of the email header. The elements they decide to include in their DKIM signing process must remain unchanged in transit, or the DKIM signature will fail authentication.

The elements included in the DKIM signing process must remain unchanged in transit.
For example, if an email is forwarded from Yahoo to Gmail, Yahoo may add a line of text at the top of the email (e.g. “forwarded by Yahoo mail”). At that point, the body of the email has been changed and, if the body was included in the DKIM signing process, the DKIM authentication will fail for the forwarded email.

However, if only an element of the header, such as the “from” field was included in the DKIM signature, and the message was forwarded from Yahoo to Gmail, the DKIM authentication would pass, since the part of the message that was changed was not signed by DKIM.

Step 2: The encryption process

The sender will configure their email platform to automatically create a hash of the parts of the email they want signed. The hashing process converts readable text into a unique textual string. Here’s what that looks like (using the MD5 hashing process):

From: John Doe <[email protected]>
Subject: Demo Email

Maps to the following unique hash string:  233970af6624f7287720282fbabf92b6

Before sending the email, that hash string is encrypted using a private key. The private key is assigned to a unique combination of domain and selector, allowing you to have multiple legitimate private keys for the same domain (which is important for email governance and security purposes). Only the sender has access to the private key. This results in a header being added to the email, as shown in the example below.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=example.com; s=demokey; t=0000000000;
 [email protected];
 bh=XYZABC123456abcXYZABC123456abcXYZABC123456abc=;
 h=From:Subject;
 b=AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLLMMMMNNNNOOOOPPPP
  QQQQRRRRSSSSTTTTUUUUVVVVWWWWXXXXYYYYZZZZ000011112222333344445555
  6666777788889999aaaabbbbccccddddeeeeffffgggghhhhiiiijjjjkkkkllll
  mmmmnnnn0000oooo1111pppp2222qqqq3333rrrr4444ssss5555tttt6666uuuu
  vvvv7777wwww8888xxxx9999yyyyzzzzAAAABBBBCCCCDDDDEEEEFFFFGGGGHHHH;

After the encryption process is complete, the email is sent.

Tags:

• v=1: This indicates the version of DKIM specification being used, which is 1.
• a=rsa-sha256: This tells us that RSA (Rivest-Shamir-Adleman) is used for the public/private key pair, and SHA-256 is used for the hashing. It defines the algorithm used to generate the signature.
• c=relaxed/relaxed: This represents the canonicalization algorithm(s) used for signing the message. The first "relaxed" refers to the header canonicalization algorithm, and the second refers to the body canonicalization algorithm. "Relaxed" means that whitespace will be normalized and header field names are not case-sensitive.
• d=example.com: The "d" tag indicates the signing domain. It tells us that the domain "example.com" takes responsibility for the message and is a key used to validate the signature.
• s=demokey: This tag indicates the selector, which is a kind of pointer that tells the receiving server where to find the public key in the DNS records of the sender’s domain to decrypt the hash value in the header and verify the message.
• t=0000000000: This represents the timestamp when the signature was created. It's usually expressed in the number of seconds since 00:00:00 Coordinated Universal Time (UTC), January 1, 1970.
• [email protected]: This is the identity of the user or agent on behalf of which this message is signed.
• bh=XYZABC123456abcXYZABC123456abcXYZABC123456abc=: The "bh" tag holds the hash of the body of the message. It's used to verify that the body of the message has not been altered in transit.
• h=From:Subject: This tells us which header fields were used to create the DKIM signature. In this case, the "From" and "Subject" fields were used.
• b=AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLLMMMMNNNNOOOOPPPP...: This is the actual digital signature of the contents (headers and body) of the mail message. The receiving mail server will use this string to validate the integrity of the message using the sender's public key.

Step 3: Validating the DKIM signature with a public key

The MTA receiving the email sees that it has a DKIM signature, which reveals which “domain/selector” combination signed the encryption process. To validate the signature, the MTA will run a DNS query to find the public key for that domain/selector combination.

This public key has the unique characteristic that it is the only match for the private key that signed the email, also known as a “keypair match.” The keypair match enables the MTA to decrypt the DKIM signature back to the original hash string.

MTA then takes the elements of the email signed by DKIM and generates its own hash of these elements. Finally, the MTA compares the hash it generated with the decrypted hash from the DKIM signature. If they match, we know that

• • The DKIM domain really does “own” the email, otherwise the decryption process wouldn’t have worked in the first place
  • The elements of the email signed by DKIM were not changed in transit (if they were changed, the hashes would not match).

 

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

What it is: DMARC ensures that legitimate email is properly authenticating against established DKIM and SPF standards, and that fraudulent activity appearing to come from domains under the organization’s control is blocked. Two key values of DMARC are domain alignment and reporting.

How it works: DMARC’s alignment feature prevents spoofing of the “body from” address by:

• • Matching the “body from” domain name with the “envelope from” domain name used during an SPF check, and
  • Matching the “body from” domain name with the “d=domain name” in the DKIM signature.

To pass DMARC, a message must pass [SPF authentication and pass SPF alignment] and/or [pass DKIM authentication and pass DKIM alignment]. A message will fail DMARC if the message fails both (1) [SPF or SPF alignment] and (2) [DKIM or DKIM alignment].

SPF and DKIM alignment results - 4 combinations
SPF Auth	SPF Align	Result SPF		DKIM Auth	DKIM Align	Result DKIM
Pass	Fail	Fail		Pass	Fail	Fail
Pass	Pass	Pass		Pass	Pass	Pass
Fail	Pass	Fail		Fail	Pass	Fail
Fail	Fail	Fail		Fail	Fail	Fail

Once we have either a Pass or Fail from SPF and DKIM records, we will then sum the results. DMARC just needs one Pass to issue a Pass.

DMARC results: Result SPF + Result DKIM
SPF Fail   + DKIM Pass	Pass
SPF Pass + DKIM Pass	Pass
SPF Pass + DKIM Fail	Pass
SPF Fail   + DKIM Fail	Fail