Three Email Authentication Protocols to Keep Users Safe - The 124 Society

Three Email Authentication Protocols to Keep Users Safe

SMTP (Simple Mail Transfer Protocol) was designed when security was not top of mind, and eventually, this weakness was exploited. Without some form of security mechanism, email messages are easily leveraged to carry out many different attacks, including spam, phishing, spear phishing, brand impersonation, malware, account takeover, extortion, and more.

Today, email is considered to be the number one threat vector used by bad actors. In fact, over 90% of cyber attacks start with an email message being sent to a victim. Email authentication protocols verify the identity of the sender of an email message to make sure that the message came from who it claims to be from. If the sender is not authenticated, your system can act upon the email message in different ways, potentially thwarting an attack.

Here are three popular email authentication protocols.

(DKIM) DomainKeys Identified Mail

DKIM signing uses a public/private key pair that can be user generated or generated automatically, depending on the security technology or appliance you are using. The public key is published into a DNS TXT record along with a corresponding DKIM selector. A DKIM selector is an arbitrary name/value that assists the recipient’s system in locating the DNS record and public key.

Example DKIM Record: [selectorname]._domainkey.[domain].com TXT v=DKIM1; p=[Public Key] 6000

The private key is held in an outbound MTA (Mail Transfer Agent). When a user sends an email message, it is signed with the private key and inserts the digital signature into the header along with the DKIM selector, and DKIM tags.

Required DKIM Tags

(v=) DKIM version being used.

(a=) Cryptographic algorithm used to generate the keys.

(d=) Domain that DKIM has been applied on.

(s=) DKIM selector name.

(h=) Headers that are used in the signing algorithm to generate a hash in the “b=” tag.

(bh=)Message body hash.

(b=) The DKIM signature which is the cryptographic signature of the headers included in the “h=” tag.

Optional DKIM Tags

(t=) Timestamp that the message is sent.

(x=) Expiration of the DKIM signature.

The recipient’s MTA extracts the digital signature, sender’s domain, selector, and then uses this data to look up the corresponding DNS record. At this point, it checks to see if the public/private keys match. If it matches, the email message is then thought of as being authentic. Security policy applied to the system will then act upon those results.

You can test your DKIM configuration by sending test emails from your domain to a gmail address, or another like service, that automatically checks for DKIM authentication.

(SPF) Sender Policy Framework

SPF uses a DNS TXT record that includes a list of outbound email server IP Addresses that are allowed to send email for a particular domain.

Example SPF Record: v=spf1 ip4=[ip_address_email_server_1] ip4=[ip_address_email_server_2] include:[example_domain.com] -all

SPF Tags

(v=spf1) Version of SPF.

(ip4=) IPv4 address of email server that is allowed to send email on the behalf of the domain.

(ip6=) IPv6 address of email server that is allowed to send email on the behalf of the domain.

(include:) Third party domains that are authorized to send mail on the behalf of the domain.

(-all) Signals that IP addresses not listed in the record are not authorized to send email messages and should be rejected.

(~all) Signals that IP addresses not listed in the record are not authorized and email messages should be marked as spam but not rejected.

(+all) Signals that any server not mentioned in the record should be able to send email messages successfully.

To find the SPF record, the receiving mail server uses the domain name in the return path email address. The return path email address is the address that is used for bounced email messages and is not the same thing as the “from” email address. The “from” email address is often spoofed by nefarious actors using many methods. When the SPF record is located, the receiving mail server checks for the IP addresses and makes sure that the sender is allowed. After this, the email message will either be delivered or marked as spam and blocked.

(DMARC) Domain Based Message Authentication, Reporting, and Conformance

DMARC leverages existing DKIM and SPF applications. Similar to the other email authentication protocols, DMARC utilizes a DNS record. This DNS record includes a domain’s policy showing how to treat the results of DKIM and SPF successful or unsuccessful authentication.

Example DMARC Record: v=DMARC1; p=reject; rua=mailto:user1@exampledomain.com; ruf=mailto:user2@exampledomain.com; fo=0:1:D:S;

Required DMARC Tags

(v=) Version of DMARC.

(p=) The policy: None, Quarantine, or Reject.

Optional DMARC Tags

(rua=) Addresses for aggregate reporting.

(ruf=) Addresses for forensic/failure reports.

(pct=) Percentage of email messages to be filtered.

(fo=) Specify the type of failure reports you will receive.

(0:) Generate a DMARC failure/forensic report if SPF and DKIM both fail to pass and be in DMARC alignment.

(1:) Generate a DMARC failure/forensic report if either SPF or DKIM fail to pass and be in DMAARC alignment.

(d:) Generate a DKIM failure report if DKIM signature validation fails.

(s:) Generate an SPF failure report if SPF fails.

Note: You can specify receiving all of the above reports by adding fo=0:1:D:S into your record.

(aspf=) SPF alignment mode: Relaxed (r) or Strict (s).

(adkim=) DKIM alignment mode: Relaxed (r) or Strict (s).

(rf=) Forensic report format.

(ri=) Reporting interval in seconds for aggregate reporting.

(sp=) DMARC policy for all subdomains.

Example: v=DMARC1; p=none; rua=mailto:user1@exampledomain.com; ruf=mailto:user2@exampledomain.com; sp=reject;

In order for DMARC authentication to be successful, either DKIM, SPF, or both should pass successfully depending on how DMARC is configured. This is called DMARC Alignment.

RFCs For Reference

dkim: https://www.rfc-editor.org/rfc/rfc6376
spf: https://www.rfc-editor.org/rfc/rfc7208
dmarc: https://www.rfc-editor.org/rfc/rfc7489