Deliverability 101

Deliverability vs Delivery

First, let’s talk about what deliverability is, by comparing it to delivery.

Delivery
The basic process of sending mail from a sender’s server to a receiver’s server.

Deliverability
This is more granular and provides perspective on where the mail actually ends up on the receiver’s server - the spam folder, a specific folder in the inbox, etc. - assuming it is not black holed or bounced. 

Many factors influence deliverability, including domain reputation, authentication, list collection and maintenance, sending cadence, campaign content, subject line, and many other elements. That is why most of the time, deliverability does not boil down to just one change. It is the consistent, continual commitment to following best practices over time that ensures good deliverability and subscriber engagement.

Key Takeaways

Domain Reputation and Authentication

In recent years, domain reputation has become even more influential on overall deliverability than it used to be, and as a result, it is incredibly important to get this right. That is why, when first beginning your email marketing adventure, one of the first things you should do is to make sure the branding on your private domain is consistent with what is on your website, on advertisements, and social platforms.

Moreover, in October 2023, Google and Yahoo announced new authentication requirements for all marketers sending to more than 5k recipients per day. Other large providers quickly followed suit, and Email Service Providers (ESPs) were scrambling to meet the expectations before the April 2024 deadline. Mailkit was able to breathe easy during this time - this was already required in order to send mail via Mailkit. That said, let’s talk about what records are required and what they do for you.

There are multiple DNS records that you must set up on your domain, and for all the ones we are discussing, the ideal TTL is at least 3600 (1 hour). Anything shorter can and often does cause temporary DNS failures, specifically for Microsoft domains. The specific records we require are DKIM, and DMARC. DMARC functions based on input from SPF (which Mailkit handles for you) and DKIM, so you must always first set up DKIM before implementing DMARC.

SPF

SPF (Sender Policy Framework) is a TXT DNS record set up on a sending domain or subdomain level, in which you define your list of approved message sources, represented as IPs and servers that are permitted to send mail on behalf of your domain.

At Mailkit, there are two options for setting up SPF. The first is that you do nothing, and we use our domains for all mail. For example, the Return-Path would look something like localpart@customer.mkt-synd/mkt-ags/txnmail.com depending on the type of mail being sent.

The second option is to use subdomain delegation for the subdomains mkt.domain.com and mktxn.domain.com (where domain.com is your domain or subdomain), which will result in aligned SPF. This would be a CNAME record with the value dist.mailkit.com. Both options are completely acceptable, but only subdomain delegation will result in aligned SPF.

An SPF record will always start with v=spf1 and end with either ~all, -all, ?all, or +all. In between these two mechanisms will be the list of IPs or servers, using such mechanisms as "include", "a", "mx", "ptr", "exists" (all of which will count as a lookup), or "ip4", and "ip6" (which do not count as lookups). A lookup will (except in the case of “a” and “mx”) appear as a server name (spf.mailkit.eu) rather than an IP range (217.11.236.80/28).

As an example, I am including two SPF records below. The first record has 2 lookups - one for spf.mailkit.eu, and one for spf.protection.outlook.com. This means that it takes one more query to look up the list of IP ranges behind these domains, hence lookup. The second record is only IP ranges, so it has 0 lookups:

• v=spf1 include:spf.mailkit.eu include:spf.protection.outlook.com ~all
• v=spf1 ip4:217.11.236.80/28 ip4:185.136.200.0/22 ~all

There are limits on SPF records, such as the permitted number of lookups and void lookups.

If the number of lookups on an SPF record is greater than 10, the record will be considered invalid, and SPF will fail. To reduce the number of lookups, use the actual IP ranges rather than the aliases.

If the number of void lookups on an SPF record exceeds 2, the authentication check will return a permerror. What this essentially means is, you cannot have more than two authentication failures present in your SPF record.

Another thing to note is that forwarding mail breaks SPF. This is why it is especially important to have DKIM set up for a domain, so at least one will pass and align, allowing DMARC to pass.

DKIM

DKIM (Domain Keys Identified Mail) is an authentication method that uses asymmetric (or public/private) key cryptography to authenticate email senders and verify message integrity, making sure mail is not altered in transit. This process involves generating a public/private key pairing, and then publishing your public key so it is accessible to Mailbox Providers (MBPs), and storing your private key on your own servers and using it to sign emails. When you use Mailkit, this is done for you, and all you have to do is set up your DKIM DNS records.

When setting up your DNS records, DKIM records are type TXT (but some providers might use CNAME delegation, depending on the configuration - more on that in a moment), and they exist in the _domainkey. space for a domain. You will also need to know the selector for the DKIM record, and the DKIM key value. Both will be determined by the hosting provider for your domain, or the ESP you are using to send mail. Note: A key length of 2048-bit should be the minimum for security purposes.

If you are using a provider like Mailkit that employs CNAME delegation, the configuration will be slightly different. Providers use a CNAME record essentially as an alias (which does not change) that points to a TXT record with the full DKIM key (which can change) on their servers.

For example, a CNAME record in Mailkit might look like this, where k1-1234 is the selector, mailkit.com is the domain, and k1-1234-5678.dkim.mailkit.eu is the CNAME value:

k1-1234._domainkey.mailkit.com    IN CNAME    k1-1234-5678.dkim.mailkit.eu

If you were to then query for what value is behind k1-1234-5678.dkim.mailkit.eu, you would see the full DKIM key in a TXT record:

k1-1234-5678.dkim.mailkit.eu     IN TXT       “v=DKIM1;k=rsa;p=1M2a3i4L5k....”

It is also recommended to have multiple DKIM keys, as this facilitates DKIM key rotation. DKIM key rotation is a security measure used by ESPs which allows them to change the DKIM key that is used to sign outgoing emails. This is important because DKIM keys will need to be periodically updated or changed for security purposes, and if there is only one DKIM key, there could be deliverability issues during the time it takes for the DKIM’s DNS to propagate.

One key difference between SPF and DKIM behavior during forwarding is, while forwarding email can break DKIM, this will depend on the receiving and intermediary server behavior.

DMARC

DMARC (Domain-based Messaging, Authentication, and Reporting Conformance) is a record that builds on top of SPF and DKIM, signaling to MBPs how they should handle mail that fails SPF and DKIM checks. Note: we are using the word should for a reason - there are many cases where MBPs will override the policy in the DMARC record. Keep this in mind as we describe the policies below.

The DMARC record has many tag options, provided as key-value pairs, but only some of them are required. Each key-value pair is separated by semicolons (;). Here is an example of the most simplistic DMARC record we would recommend:

v=DMARC1;p=none;rua=mailto:dmarc-rua@mailkit.com,mailto:example@domain.com

The v= tag is the version, and it is always DMARC1. This must be the first tag in the record.
The p= tag is the DMARC policy, and there are three possible values:

• p=none: signals to receivers that nothing should happen to the mail (not bounced nor placed in spam) when it fails authentication. In this scenario, the benefit of DMARC is the reporting aspect, so make sure you are including an address for the rua= tag.
• p=quarantine: signals that non-conforming mail from your sending domain should be placed in the spam folder.
• p=reject: mail that fails authentication checks should be outright bounced back to the sender.

When the DMARC record is configured with a rua= tag, receivers generate aggregate DMARC reports for the sender, which is arguably the greatest benefit of DMARC. These reports provide visibility into your various mail streams, such as what IPs are sending mail on behalf of your domain, whether they pass or fail the SPF, DKIM, and DMARC checks, and so on.

If you use the Mailkit rua= address listed above, these reports are available in the app under Deliverability Report. If you would like to use multiple addresses in the rua tag, they must be separated by a comma (,) and prepended by​​​​​​​ mailto: (as in the example above).

There are also forensic reports that utilize the​​​​​​​ ruf= tag, but since these reports do not comply with GDPR, you should not use them in your DMARC record.

Don’t be deterred by the technical nature of this guide. Part 1 is the most technical part that we will be covering. Stay tuned for Part 2 when we discuss List Collection and List Maintenance!