SimplyEmail

Email authentication

Domain authentication is more strictly enforced by Google and Yahoo. Anyone sending through this platform should ensure the following:

  1. You are sending from a domain that belongs to you or your organization. If you do not have a domain you can use, we recommend purchasing one as soon as possible.
  2. You authenticate your domain using DKIM, SPF, and DMARC, the three methods discussed in this document.
  3. You are following best practices with obtaining permission and respecting unsubscribes.

If you're sending email using your own domain name, email authentication is vital. Think of it like a digital signature for your domain, put in place to protect your brand, identity, content, and reputation. It makes it harder for people to fake that they're sending emails from you or your brand, and more likely that your legitimate emails will reach your subscribers' inboxes.

This article explains the different types of email authentication and how they affect the mail that you send. To set up email authentication, contact your administrator.

Authentication methods

There are three major methods used in email authentication, all based on DNS TXT records:

To meet industry requirements for the delivery of mail, both DKIM and DMARC are required. Including an SPF record is also strongly recommended as an additional deliverability benefit.

DKIM

DKIM verifies that an email's content hasn't been tampered with before it reaches the recipient. It does so by generating a code, called a hash, that represents various elements in an email, like its content and FROM field. That hash is then encrypted using a private key, and is added to the email's header at send time by the outbound mail server.

When an inbound mail server receives the email, it checks the email's header to see if DKIM is present. If so, it generates its own hash of the matching email elements (content, FROM field, etc). The server then looks up the domain supplied in the DKIM signature, and queries that domain's DNS for the public key needed to decrypt the hash. If the decrypted hash from the email header matches the server's hash of the appropriate fields in the received email, then the email passes DKIM.

Our application hashes fields in the header and body of emails, which not only helps to confirm that an email is from who it says it's from, but that the content has not been altered since it was sent.

How email clients treat emails without DKIM

If you haven't authenticated your sending domain with DKIM, some email clients will flag your emails as coming from a different server. This can potentially cause them to be blocked, or lead subscribers to believe they're receiving spam.

For example, in Outlook 2016, your email will display in the recipient's inbox as being "sent by" someone else. In the image below, while the FROM address shows correctly as sally@designco, the email is flagged as coming from one of our servers (cmail2.com).

Outlook 2016, showing the notification "This message appears to be junk mail", as well as a different "sent by" address

In this case, the email has also been sent to the junk folder, although the lack of DKIM authentication isn't necessarily the cause. There are many reasons other than authentication as to why an email could end up in the spam or junk folder, and conversely, unauthenticated email can still make it to the inbox.

After DKIM authentication is added to the sending domain, only the FROM address is shown in Outlook 2016, as shown in the image below.

Outlook 2016 shows only the original email address for an authenticated email

Gmail operates in a similar way, except it uses the word "via" to indicate an email isn't DKIM authenticated, as shown in the image below.

Gmail showing an unauthenticated email, indicated by the word "via"

With DKIM authentication added, "via" and the sending server are no longer shown in Gmail, as shown in the image below.

Gmail shows only the original email address for an authenticated email

SPF

SPF authorizes specific outbound mail server IPs to send on a domain's behalf. By default, we supply an SPF record for you, authorizing the domains through which we send email (the domains used in the Return-Path address that machines read).

Setting SPF for your sending domain

Emails sent with the default SPF settings can still pass DMARC, so long as you set up DKIM.

However, it is an optional but recommended step to include our servers in an SPF record for your domain. See the full instructions.

DMARC

DMARC is a policy framework intended to prevent phishers, spammers, and other illegitimate actors from forging a sending domain and posing as someone else. This kind of impersonation is known as spoofing.

So long as a receiving email server supports it, DMARC gives the owner of a sending domain some control over what happens when that server receives a spoofed email — either do nothing (none), block it (reject), or send it to spam/junk (quarantine).

An email passes DMARC if:

  • It passes DKIM or SPF.
  • The domain used in the FROM address matches the domain used in the DKIM or SPF records.

Even if an email passes DMARC, this isn't a guarantee it will end up in the inbox. An email will still be subject to other checks, like scanning for spammy content, or sender reputation checks, before it reaches its final destination.

Before you look into DMARC, first set up and verify that DKIM and domain-aligned SPF are working as expected.