It takes a village to improve the trustworthiness of email delivery

Email remains a critical tool for most businesses, regardless of the extent to which it may be disrupted by services such as Slack. Users of email services often make one or more implicit assumptions about the trust in the delivery of email:

1. “The email I receive was sent by the sender/From address I see in the email”, i.e. spoofing is hard.
2. “I expect that an email that impersonates a sender will be easy to spot”, i.e. phishing won’t catch me.

While these are assumptions that users should be able to make in a perfect world, they are sadly invalid.

In this article, I’ll explain why email system administrators and IT security teams need to do their part to improve the trustworthiness of email delivery. I’ll provide some examples and lessons learned from what we have done at Anonyome Labs, as well as some of the open source tools we use to validate our email server security configurations. The article directly addresses interrelated issues such as the integrity and confidentiality of email messages and whether those messages obey published privacy policies or contain malware.

Threat Model

Consider this threat model for email delivery, from the perspective of the receiver of the email.

The successful mitigation of these threats relies on the combination of two activities:

1. The owner of the email domain for the claimed sender should configure message authenticity for their domain.
2. The owner of the email servers that receives the email should check for the presence of message authenticity information in incoming messages and validate that information per the published policy.

Applying The Industry Standards

The first email authenticity standard to configure is Sender Policy Framework (SPF). SPF ensures that only authorized hosts can send email on behalf of a domain. Use of SPF prevents unauthorized sending of email by external bad actors and well-intentioned employees who may have signed up for an online service that needs to send email on behalf of your company, e.g. a customer support platform. SPF is configured in DNS to identify which mail servers are permitted to send email on behalf of a domain. 

As an example, here are SPF related DNS entries from the MySudo email service’s domain, sudomail.com: 

sudomail.com.   TXT  "v=spf1 mx -all"

sudomail.com.   MX   10 mx2.sudomail.com.

sudomail.com.   MX   10 mx1.sudomail.com.

 Translation: For the sudomail.com domain, permit sending email from hosts listed in the MX record, and no others. The hosts in the MX record are mx1.sudomail.com and mx2.sudomail.com.

The second standard cryptographically binds the email message to the sending domain. This standard is called DomainKeys Identified Mail Signatures (DKIM). A digital signature is formed over parts of outgoing messages using a private key configured in the software of the sending mail server. The corresponding public key is published in DNS to allow a receiving mail server to validate the signature. DKIM protects against an administrator or hacker sending unauthorized email from the email server host if they lack access to the DKIM private key.

 Building on the example above, here is a DNS entry for DKIM configuration:

 mail._domainkey.sudomail.com.   TXT      "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9hbMj0ki8N4KJXEVvcKQex7InXdRYv8k+TneR2nY2VHxRCc+dtGiSLL27tzlVk4HLLeL7cb34uEPbMPmv7YDaPPDbpnLpJSEWd1d17lupXAywpAsb43yT0e5Gs1RaH2wvuABEnQlHYpIEh9Mp9/HF1+GXvDikw6IVrDL2dNMspANyjZSEdbVMivSO/FNwo1mFlWPV2fsAqlKaETBMxBWUf+0LemJ2SF6mtLT0V30H0lMGJlcHt+NCdvmYMFgnM3yRh2ada6Wz26odzjwlmkb60GtkMwp7Ba4i2mMkFRNA6fq1H80/t9czlFdiaHC2rOeqQ8Y/enXq+Ybiix/UR4h5wIDAQAB"

Translation: The public key for verifying signatures for the sudomail domain is (starts with MIIBIJ… and ends with ….IDAQAB).

The final standard is Domain-based Message Authentication, Reporting, and Conformance (DMARC). DMARC allows a sending domain to instruct a receiving domain how to validate email messages, process messages that violate policy and report back to the sending domain. DMARC checking takes the results from SPF and DKIM validation as inputs and caused the receiving domain to perform one or more of these actions:

• Quarantine or reject emails that fail SPF or DKIM checks
• Report on the results of DMARC policy evaluations.

Building again on the example above for the sudomail.com domain, here’s the DNS entry for the DMARC policy:

 _dmarc.sudomail.com.   TXT             v=DMARC1; p=reject; sp=reject; aspf=s; adkim=s; pct=100; fo=1; ruf=mailto:[email protected] 

Translation: Reject (not quarantine) messages that fail checks for this domain or its sub-domains; perform strict checking for both SPF and DKIM; apply this policy to 100% of messages; generate reports if any checks fail and send reports to [email protected].

When an email is sent from a domain with DMARC, SPF and DKIM setup correctly, here’s an example of what the email message headers might look like. These can be seen from view source / view message headers from many email clients.

The DKIM signature header is sent with the message, providing the digital signature and how it was created – DKIM key used, algorithm and the mail headers over which the signature is calculated.

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;

      d=sudomail.com; s=mail; h=Content-Type:MIME-Version:Subject:Message-ID:To:

      From:Date; bh=JKY7RN/b+KApZmYBNje59kEBqTr0vJp6KKGywk7RowQ=; b=SAVWL/r/k+um5GQ

      3TKcpUgERX2FB4jn5VW7F/kdYYNq4kDmWRpsShyi5d53wwUZ/zwcxZsFZg4CUHQ8No39FKNudA/0q

      +afXV6TEmpH0vZ2Q5fx6dD/EhdF5MGlXVYIB6Z/YWzhIADkAaZFRCbhpf/H+ILOwo5tT6HblAL0FW

      Ahsme94nf1x0YsuWy6bgBwl0D2/IKrrbvpx/mbfuJjEo8g4yezGZUqUWWbuO0SfYBj5Crtnlowivs

      SCT0FpdGvZz4mbY59zxgsVbJgZ/pXDSicdqF1ZAvzc8KONP50Mv32/bCdkoK1oMyE5V93TgoDLaUZ

      nse9DIVI1Hx0CjXnt/A==;

 The Authentication-Results header is inserted by the receiving mail server after performing checks. This example shows that DMARC check has passed, because the SPF and DKIM checks have both passed:

Authentication-Results: spf=pass (sender IP is 54.215.232.175)

smtp.mailfrom=sudomail.com; anonyome.com; dkim=pass (signature was verified)

header.d=sudomail.com;anonyome.com; dmarc=pass action=none

header.from=sudomail.com;compauth=pass reason=100

The Received-SPF header is also inserted by the receiving mail server and provides more detail on why the SPF check passed:

Received-SPF: Pass (protection.outlook.com: domain of sudomail.com designates

 54.215.232.175 as permitted sender) receiver=protection.outlook.com;

 client-ip=54.215.232.175; helo=mx2.service.anonyome.com;

Crafting the DNS entries for DMARC, SPF and DKIM may feel daunting at first. Thankfully, some organizations with expertise in this area make available tools to help you generate the required DNS entries and validate entries once they have been added to DNS. A couple that I like are provided by dmarcian and MxToolbox.

Lessons Learned

From configuring SPF, DKIM and DMARC at Anonyome, we learned several lessons.

Start small… but start!

Configuring SPF, DKIM and DMARC for the first time can be daunting. There are many ways to start small to minimize the impact if you don’t get it quite right the first time, such as: 

• Starting with a less frequently used domain you own;
• Configuring reporting only without quarantining or blocking the flow of email;
• Configuring individual forensic reports; and/or
• Initially taking relaxed vs strict stances on identifier alignment. 

While you are developing and refining your policies, ensure the DNS entries being created have short TTLs, e.g. 10-15 minutes. This will make it quicker to propagate changes, or worst case, delete them entirely if you need to start over.

At Anonyome, we started with non-intrusive policies and tightened them up over time. The DMARC Record Wizard can be used to walk through these choices and build a DMARC policy.

Protect your less used domains as well

Setting up empty SPF records and corresponding DMARC policy for domains that you don’t expect to send email from can lower the risk that a bad actor can impersonate your domain when sending spoofed email. DMARC reports showing SPF failures might be an early indication that your domain is of interest to a bad actor. 

Don’t forget about sub-domains

If you don’t expect to send email from a sub-domain, e.g. dmz.yourdomain.com, ensure the policies reflect that stance.

Simplify DMARC reporting

If you operate multiple email domains it might be desirable to forward DMARC reports to a single, primary domain. An additional DNS record is required in that domain to indicate that an email server is authorized to send DMARC reports for a secondary domain to the primary domain. The DMARC Inspector tool will indicate if the DNS record in the primary domain is missing, and how to fix.

Follow guidance from your service providers

You may use service providers such as CRM or Customer Support services who you want to send email on behalf of your company. For example, Anonyome uses Zendesk to manage support for MySudo users. Zendesk provides articles on how to setup SPF and DKIM. Hosted email services such as Office 365 provide similar guidance.

If you use service providers such as a web hosting provider who you want to send email on behalf of your company, consider using a different email domain or subdomain or your main domain to minimize the impact if that service provider’s email service was ever compromised.

Aspire to a zero-tolerance policy for untrusted email

A DMARC policy that directs a receiving mail server to still deliver untrustworthy email to end users does not prevent phishing - CISOs know that users will fetch suspected SPAM from the Junk folder and click on links. Aspire to a policy that takes these possibilities away from users – configure strict identifier alignment and reject mail that fails a DMARC check, whether the SPF or DKIM checks fails. You won’t start with policies as protective as this but remember that a strict DMARC policy is the destination.

Review your policies periodically

As with any security policy or configuration, SPF, DKIM and DMARC settings should be reviewed periodically to ensure that they continue to meet your needs. For example, when you switch service providers, you may need to remove one section from an SPF record. If that is not done, you have left another set of email servers that could be used to masquerade as your domain.

DMARC isn’t a universal panacea

DMARC policy enforcement does nothing to protect users from unsolicited emails from well configured, non-impersonating mail domains. As such, it remains important to train your users on how to detect phishing email and what steps to follow when they think they are being phished. 

All Working Together

With SPF, DKIM and DMARC correctly configured, the validation of incoming messages happens as shown in this diagram. The sequence for an impersonated message is shown.

1. A bad actor sends an email message purporting to be from mybank.com to [email protected].
2. The sending email server forwards the impersonated message to anonyome.com mail server, either because the sending email server is incorrectly or maliciously configured as an open relay.
3. The receiving email server looks up DNS records for mybank.com to assist with message validation.
4. The receiving email server checks that message originated from an authorized server (SPF) and signed the message with the expected private key (DKIM). Results of these validations are assessed in the context of mybank.com’s published DMARC policy, also retrieved from mybank.com’s DNS.
5. If the level of message validation is permitted by the DMARC policy, the message is delivered to the user. If the DMARC policy specifies quarantining failed messages, those messages may appear in the receiving user’s Junk folder or have their subject tagged with “[SPAM]”. If the DMARC policy specifies rejecting failed messages, those messages are discarded and not delivered to the user.
6. A DMARC report may be delivered to a mybank.com email address, if specified in the DMARC policy and the validation status of the received email.

Some phishing email will likely still arrive at your users’ inbox, so what is described in this article doesn’t address all spoofed email scenarios. This would be the case if the phishing email was sent from a domain without DMARC policy or from a lookalike domain with correctly setup SPF, DKIM and DMARC records in DNS.

Conclusion

Improving the trustworthiness of email delivery requires action by the community of professionals who operate email services. Based on available analysis from dmarc.org and others, the rate of adoption of DMARC is slow and perhaps even reaching a plateau, so there’s never been a more important time to take action. As more organizations implement standards such as SPF, DKIM and DMARC, the herd immunity effect will better protect all our people. 

I hope this article has given you the inspiration to make some improvements and information about the tools and techniques based on Anonyome’s own use of these standards.