Did you know that in February of 2024, both Google and Yahoo will implement new protections to prevent spam from ending up in their user’s inboxes? Email fraud and phishing attacks are on the rise, and the major email providers want to prevent these emails from ending up in their users' inboxes.

If your business does not meet the requirements for authenticating emails, your messages could end up in your sales prospects’ or customers' spam filters. This blog post will explore how email works, the history of different email authentication checks, how they work, and how you can ensure the new changes will not impact your email.

Don’t have the time to read this entire blog post and understand the inner workings of email authentication? You can use Relay Hawk’s email authentication check tool to see if your email passes three security authentication checks. Be sure to test all email sources because each can have different results.

How email works

Before diving into email authentication, let’s cover the basics of how email works. One key component is that there are two different email addresses to identify the sender in an email. There is a From and an Envelope Sender.

• From: Email clients use this email to display the From address.
• Envelope Sender or Return-Path: Email servers use this email to identify where to send email bounces.

The following sections will explain why these two different sender email addresses matter. Note that the Envelope Sender/Return-Path is not the same as the Reply-To email address.

These are the steps to send an email from your email client.

1. You click send in your email client (e.g. GMail, Outlook, Apple Mail).
2. Your email client connects to your email server.
3. The sending email server connects with the receiving email server and transmits the email.
4. The receiver’s email client accesses the emails from the receiving email service provider.

The sender’s addresses look like the following:

Return-Path: sally.johnson@fictionaltas.com
From: Sally Johnson <sally.johnson@fictionaltas.com>

In this example, you can see that the email address in the Return-Path and From match one another.

What about emails sent from your TAS Platform (e.g. Startel, Amtelco)? The TAS platforms typically connect to an SMTP Relay Service such as SendGrid, MailGun, and SMTP.com. You may even run your own SMTP Relay Server, such as MDaemon or G-Lock. These are the steps for your TAS Platforms to send emails to an SMTP Relay.

1. The TAS platform creates a message to send.
2. The TAS platform connects to the Email Service Provider.
3. The sending email server connects with the receiving email server and transmits the email.
4. The receiver’s email client accesses the emails from the receiving email server.

The sender’s addresses look like the following:

Return-Path: em-12321ladfaff@fictionaltas.sendgrid.com
From: Fictional TAS Dispatch <dispatch@fictionaltas.com>

In this example, you can see that the email address in the Return-Path and From address do not match. Email Service Providers (ESPs) such as Sendgrid define a different email for receiving email servers to send bounces. This way, the ESP can track bounces and ensure they do not send more emails to these addresses.

Note: If your TAS Platform sends email through GSuite or Microsoft 365, you should consider changing this to an SMTP relay because they limit the number of emails you can send daily.

What about emails sent from your marketing tools (e.g. HubSpot, ConstantContact, MailChimp)? The marketing platforms typically run their email servers, and the following are the steps for your marketing tool to send emails.

1. You click “send email” in your marketing tool.
2. The marketing tool’s email server connects with the receiving email server and transmits the email.
3. The receiver’s email client accesses the emails from the receiving email service provider.

Return-Path: em-adf12als@fictionaltas.hubspot.com
From: Owner Name <owner@fictionaltas.com>

In this example, you can see that the email address in the Return-Path and From address do not match. Marketing providers such as Hubspot define a different email for receiving email servers to send bounces. This way, the marketing provider can track bounces and ensure they do not send more emails to these addresses.

Note: Some email service providers such as SendGrid allow you to customize the domain of the return-path. Others, such as Constant Contact, do not allow you to customize the domain of the return-path. If you configure a custom domain in the ESP for the Return-Path, you must configure the SPF record yourself.

Why do we have SPF?

In the illustration above, you can see that a hacker’s email server sends an email from the same domain as a legitimate email server. How is the receiving email server supposed to know whether or not the email server is legitimate?

The Internet Engineering Task Force (IETF) published the Sender Policy Framework (SPF) standard in 2004. IETF published RFC 7208 to reduce spam and phishing attacks by validating that the Return-Path domain permits emails sent from the sender's IP address.

How does SPF work?

When the sending email server connects to the receiving one, the sender will declare it is sending email from fictionaltas.com, represented in the Return-Path header. An ESP may use a different domain than your domain, such as fictionaltas.hubspot.com.

The receiving email server will then check to see if the sending email server’s IP address is on a list of IP addresses defined in the domain's SPF DNS record. Thus, a domain must configure the SPF records to permit senders to send from their domain. An SPF record is a TXT DNS record that can be found by querying the domain’s TXT record.

$ dig +short TXT fictionaltas.com
"v=spf1 include:_spf.google.com include:sendgrid.net ~all"

In this example, you can see that fictionaltas.com has configured Google and Sendgrid to send on its behalf. The ~all tells the receiving email server that if it receives an email from a server that does not have an IP address that is on the SPF list, then the email should be scrutinized but not outright rejected.

Many email service providers are now sending emails from a domain they control (e.g. fictionaltas.sendgrid.com) so that they can manage the email records for the Mail Exchange and SPF for you. This requires less configuration for your domain’s administrator.

Why do we have DKIM?

In the illustration above, you can see a slight difference from the previous example in SPF. In this example, you can see that the attacker configured the Return-Path address to be attacker.com, which will accurately match an SPF record they set up. Thus, SPF does not prevent someone from impersonating an email with a From address they are not permitted to send on behalf of.

The IETF published the DomainKeys Identified Mail (DKIM) standard RFC 6376 in 2011 to cryptographically prove that the email server sending the email is associated with the “From” address.

DKIM can also cryptographically prove that a man in the middle has not altered other parts of the message (e.g. subject, body). For example, if an email server forwards emails on behalf of a domain, the email server in the middle cannot manipulate the email. If they do manipulate it, it will fail the DKIM check.

How does DKIM work?

DKIM works by cryptography signing the contents of an email. The sending email server signs the contents of the email with a private key. When signing the email, the server adds a DKIM selector, telling the receiving server how to validate the email. The email administrator must add the DKIM selector to a TXT record on the domain. The DNS record includes the public key, which the receiving email server uses to validate the email's signature.

You can look up the DKIM selector of a given domain by querying the {selector_name}._domainkey.{domain}. Here is an example for querying the SendGrid’s DKIM selector (s1) on fictionaltas.com

$ dig +short TXT s1._domainkey.fictionaltas.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuP7eGjcf4oVZwohlbM6PdJxKytdxoPl2INR2dz3VJu0GdF8hUBMl67iV/BsH9gFHezh7OFbNr2chXj1gsFy/PEPo++uC0T0HJdM1p9GdY6/WDIzz8Xbf5Ldl1LOqr2yVUPpsD4uzh7yJpNeTQO0RlWgKrV5qNF2DPi8icJzF0UBBvVeb0E7V8UBUa3y4437ut" "rCVqdyTNdHZDvQWoj1Lx8S8gur+Gh58pppo0mVtlWzpnNNAXo3t7oJJuVWhwQ9yeyXy24bbrl2WG0wzPLgAxUyOG28UNZE1jsDQw5X1xU+DayqrdatK/pYCP8/V4SOJIKw+/4UFXFTQ1c1KQ5XuRQIDAQAB"

Why do we have DMARC?

In the illustration above, you can see that a legitimate email server signs the email, and the hacker’s email server does not. How does the receiving email server know if the email is supposed to be signed?

The IETF published the Domain-based Message Authentication, Reporting, and Conformance (DMARC) standard (RFC 7489) in 2015 to inform the receiving email server whether to expect SPF checks to pass and whether DKIM signatures should be present.

How does DMARC work?

DMARC tells a receiving email server how to authenticate an email. Should email be required to pass an SPF check? Should the email be required to pass a DKIM check?

You specify your DMARC policy by configuring a TXT record for _dmarc.{yourdomain}. Here is an example DMARC record for fictitionaltas.com.

$ dig +short TXT _dmarc.fictitionaltas.com
"v=DMARC1; p=none; rua=mailto:3b37a916-8112@dmarc.relayhawk.com"

The RFC references the key/values within the DMARC record as tags. DMARC policies commonly use the following tags: adkim, aspf, p, pct, and rua.

The p tag is the policy tag and tells the receiving mail server how to handle emails that do not meet the requirements of the DMARC policy. The email administrator can configure the policy to none, quarantine, or reject. The quarantine tells the receiving mail server to put the email in the “spam” folder, but it is up to the receiving mail server to determine where to place the email.

The pct tag tells the receiving mail server what percentage of emails to apply the DMARC policy. If an email fails an SPF and DKIM check, the administrator configures the DMARC policy to quarantine and the pct to 50, then there is a 50% chance that the receiving email server will mark the email as quarantine. Email administrators commonly use the pct tag when implementing DMARC, so they can increase the percentage of emails applying an SPF policy. Thus, if there is a configuration issue, it does not break email by sending 100% of email to spam.

The adkim and aspf tags indicate whether DKIM and SPF alignment is required.

The aspf tag tells the receiving server whether or not SPF must be aligned. For SPF to be aligned, the Return-Path and From domains must be equal.

The adkim tag tells the receiving server whether or not DKIM must be aligned. For DKIM to be aligned, the domain’s DKIM signature (d= field) must match the email’s From domain.

The rua tag tells the receiving server where to send the aggregated reports. The reports are, by default, sent once a day.

Note: The RFC mentions additional tags, but email administrators do not frequently use them. Furthermore, an administrator can configure failure reports with the fo and rf tags, but most email servers do not support sending failure reports.

A note on policy none (p=none)

An email administrator can configure SPF, DKIM, and DMARC, but if the administrator has configured DMARC with a policy of none, then the domain is not gaining the full benefits of DMARC.

It is common for an email administrator to configure their DMARC policy to have a policy of none. This is a monitor-only mode and does not provide any security that you expect from implementing DMARC. A policy configured to none is only acceptable when first configuring DMARC and monitoring the reports sent to the addresses specified in the rua tag. After your emails pass SPF and DKIM checks, you should configure your policy to either quarantine or reject.

How do I know if my email is configured properly?

You can use Relay Hawk’s free email authentication tool to see if your email administrator has properly configured your email. You want to receive a checkmark for SPF, DKIM, and DMARC. The tool will also provide you with recommendations to improve your email security.

Email source checklist

You should test each email source because each is configured differently and can have different security check outcomes. Here is a list of email sources to help you brainstorm where emails may originate from:

• Primary email (e.g. GMail, Microsoft 365)
• Marketing Tools (e.g. HubSpot, MailChimp, Constant Contact)
• TAS Platform (e.g. Amtelco, Startel, Pinnacle)
• Billing Software (e.g. TASBiller, TBS)
• Voice Mail (e.g. CenturiSoft)

What does this not secure?

SPF, DKIM, and DMARC are great ways to secure your domain. However, it is not a silver bullet for securing email.

If you use a shared IP for sending emails, the IP may end up in a blocklist. You should consider purchasing a dedicated IP from your ESP.

If your email server receives a phishing email from another domain you do not control, SPF, DKIM, and DMARC cannot help this. The sender’s email administrator must set up SPF, DMARC, and DKIM for their domain.

If you receive a phishing email that looks like an employee sent it, but an attacker sent it from a look-alike domain – a look-alike domain is a domain like fictionaltas.info that looks like fictionaltas.com – then the email can pass SPF, DKIM, and DMARC checks because the attacker is in control of that domain. Relay Hawk customers have witnessed attacks like this, and you can read more about it on our blog, Protect Your Call Center from This Targeted Phishing Email.

If an email account for your email provider is compromised, the attacker can use the credentials to send emails on your behalf. These emails will pass SPF, DKIM, and DMARC checks because the account is legitimate, but the credentials are compromised.

Conclusion

Authenticating your domains improves the security of your domain by preventing malicious users from sending emails on your behalf. It also enhances deliverability by assuring the email providers that emails originating from your domain are genuinely from your domain.

If you would like to learn more about protecting your answering service or call center, Relay Hawk is here to help. Relay Hawk goes beyond the typical compliance checks and dives into security issues that are only present in your business. We perform attack surface monitoring, vulnerability assessments, penetration testing, and best practices reviews like email security audits.

Request more information about Relay Hawk.