Best Practices Deliverability 101

Setting Expectations

The best way to maintain deliverability is to get started by setting expectations. Many problems with email deliverability arise due to a disconnect between what the recipient is expecting to receive and what the marketer has planned to send. No matter how many best practices you follow, you will see spam folder placement due to this disconnect.

If your ESP allows you to have a preference center, make heavy use of it. If not, you can use a welcome series to set expectations for new subscribers and give them a chance to opt in or opt out of additional mailings you have planned.

The specifics of your programs will vary based on your industry, so keep in mind your customers’ purchase and engagement habits when you’re scheduling out new content. If you subscribers are expecting to see email from you once a week, don’t automatically add them in to your “special offers” which are also sent once weekly. You’re now sending double the expected mail to them.

We see this kind of list creep frequently. Over time, subscribers who started with one email from your company per week now receive up to five emails per week due to the number of new initiatives added over the years. Run a review at least annually to ensure that your content isn’t so targeted as to inundate your subscribers with excessive emails. You’ll also want to make sure to include the profile center link in every email to easily allow subscribers to choose which additional initiatives and how much email they wish to receive from you.

Randomly selecting from the list of subscribers receiving multiple initiatives and performing a count for how many emails those subscribers are seeing can be a wake-up call for how much mail you’re really sending to each subscriber. This is especially important for subscribers who are starting to become less engaged with you, as list fatigue causes otherwise very actively engaged subscribers to stop engaging with your emails.

Keep account of how much mail and what content you’re sending to subscribers to make sure that your expectations are aligned with theirs to help avoid email deliverability problems that can arise, even when you’re following best practices.

Quick Tip Best Practices Deliverability 101

Quick Tip: Core Subscribers

Deliverability is a function of engagement over time, so something has been going amiss for at least a couple of weeks by the time you notice a drop in inbox rates. It’s imperative to react quickly to minimize any additional reputation damage while you dig into the root of the problem. One of the tactics I recommend is to maintain a list of subscribers that are your most active subscribers. This is easy to do before you run into problems and should be refreshed monthly.

To create this list of core subscribers, you’ll want to run a report showing which subscribers have engaged with your email multiple times. Limit your search to the last three months. Focus on recent opens and clicks, and prioritize subscribers who regularly open and/or click your messages. These subscribers drive up your engagement metrics dramatically.

As soon as you start to see a drop in deliverability, open, or click rates, you’ll want to change your list to your core subscribers plus about 20% more less engaged subscribers for the next few sends. For example, if you have 10,000 core subscribers your total send volume will be 12,000 for the next two to three sends. Slowly add in subscribers who haven’t engaged recently, so your next send might be 14,000 subscribers and include subscribers who haven’t opened or clicked in four to five months.

There will come a point when you’ll see a dramatic drop in your open and click rates for your sends. Once that happens, remove the last batch you added and create a re-engagement campaign for any addresses of that age and older, or suppress all older addresses from all subsequent sends.

While this won’t get you to the root of the issue, it will allow you to continue marketing while you work on finding the root cause and creating a plan to address it. If you need some help with setting up processes for immediate remediation tactics or with getting to the root cause, you can contact me through the Contact form or email me at

Deliverability 101 Best Practices

Sender Authentication or Alphabet Soup?

Sender authentication is a cornerstone of good deliverability. Sender auth is an advanced topic, but even beginners need to know enough about it to have a conversation about it because it is foundational to your deliverability. There are a few different forms of sender auth and what you need to know is the basics of how they work. Sender authentication methods are used to track your reputation, increase your company’s security, customer confidence, and reduce phishing and fraud.

When you send email, there is a lot of work happening behind the scenes and a lot of information recorded that you don’t usually see. I’ll share full headers and explain them in a future post, but what you need to know for now is those are the “envelope” for your email. Sender authentication methods validate different parts of the envelope to boost confidence that the email your recipient gets is the same content you sent and is really from you.

It’s about to get confusing, but we’ll have future posts that get more in-depth on each form of sender authentication. I’ve linked to the RFCs (Requests for Comments, or the rules that the internet operates by) that relate to each type of sender authentication for intermediate and advanced learning. If you’re just getting into email and deliverability, skip those for now. They’re very technical and can be confusing even for experts.

DNS usage in Sender Authentication

First, you need to understand some basics about DNS, or Domain Name Service. DNS has multiple different types of records that allows computers to “talk” to each other. While there are many more types of records, these are the ones you need to know for conversations about sender authentication to make sense:

  • TXT (text) records provide basic information about your domain.
  • A (address) records translate your IP (internet protocol) address. (which is made of all numbers) into words like
  • MX (Mail eXchange) records say where to deliver email to you.
  • CNAME (canonical name) records let you set an alias. This may not apply to you unless your ESP handles your DNS records for you. We won’t be talking about them in detail here, but I’m including them in case they come up in conversation.

SPF, or Sender Policy Framework

SPF stands for Sender Policy Framework and is defined in RFC7208. SPF authenticates your sending IP address using a TXT (or text) record, which is comparable to your street address on a physical envelope. SPF checks your “envelope from” not your friendly from. Your envelope from goes by many names but the most common are Return-path or bounce address. We’ll get into the technical terms for these different from addresses in more advanced posts. Your envelope from is not usually displayed to your recipients. Your friendly from is the address you set up in your email client or ESP’s UI to display to your customers.

Image of full headers showing examples of envelope from and friendly from. Text-only headers available at Envelope from is in the Return-path and in the Received header with label envelope-from. Friendly from is labeled From: Example Business.

You may have a shared IP address, meaning other senders also use the same IP, a single dedicated IP, multiple dedicated IPs, or multiple vendors. All of these IPs need to be included in your SPF record and may be labeled as A, MX, ip4, ip6, or includes based on how they are formatted and grouped together. (There are additional types, but we’ll get into those when we look at SPF more in-depth.) If your SPF record is improperly formatted or does not include all of your originating IPs, SPF will fail which will cause your email to be placed in the spam folder or rejected.

DKIM, or DomainKeys Identified Mail logo

DKIM stands for DomainKeys Identified Mail and is defined in several RFCs, which can be found linked in the Documents section on the DKIM website. The DomainKeys Identified Mail (DKIM) Services Overview (RFC5585) establishes the protocol and gives an overview of the service. DKIM is comparable to the envelope you put physical mail in. It creates an encrypted “wrapper” around your content and headers like your subject line and From address.

In the full email headers, your mail server will include some information about which headers are included, the hash for the encryption, a selector (indicates different parts of your mailstream), and the domain or subdomain that is authenticating the message. In the image showing the from addresses, you can see which headers are being included by looking at the list after h=. (Text-only version available here.)

It is possible and somewhat common to have multiple different DKIM signatures on the same email. This just means that each signer is authenticating what they’re sending on is what they received from you. The signer may be very different from the original sender.

DKIM requires that the signers have a TXT record in your DNS entries that includes the type of cryptography used and a public encryption key. The recipient mail server makes a query to the signers’ DNS server(s) to ask for the public encryption key and compares its results to the information in your headers. If the results don’t match, DKIM fails. Your email will be marked as failing and placed in the spam folder or rejected.

Note: DomainKeys, as opposed to DKIM, is deprecated.

DMARC, or Domain-based Message Authentication, Reporting, and Conformance logo

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance and is defined in RFC7489. DMARC relies on DKIM or SPF in a few different ways. While neither SPF nor DKIM require that they align with your friendly from, DMARC requires that at least one does. Remember, SPF has to align with your Return-path or envelope from while DKIM relies on the signer’s domain value in the full headers? That’s a bit confusing, so why is the DMARC requirement different? DMARC is intended to combat online phishing and fraud, so it makes sense that the requirement of the email address you see is the one that has to be aligned to pass authentication.

DMARC requires a TXT record that recommends to a provider how they should place your email if DKIM and SPF do not align with the friendly from or both fail to pass and what percentage of email to apply the policy to. Policy options are none (deliver as normal, used for initial setup and troubleshooting), quarantine, or reject. Many providers will choose to quarantine rather than reject email regardless of the policy set.

BIMI, or Brand Indicators for Message Identification

BIMI Group logo

BIMI stands for Brand Indicators for Message Identification and is the newest protocol. BIMI is still in draft and has not yet reached the point of having an RFC. The draft is available at Because it is still in draft, implementation is limited, however there are a number of providers who have implemented BIMI as of late July 2020.

BIMI allows DMARC-compliant mail with an enforcement policy (quarantine or reject at 100%) to display a company logo in your subscriber’s mail interface. In order to display your logo, you must produce a Scaled Vector Graphic Tiny PS version of your logo and make it available via a URL. Once that is available, you publish a DNS TXT record that indicates where your logo is.

BIMI is not available at all mailbox service providers or for all senders yet, but it’s an exciting advancement and we’ll keep you updated as its use becomes more common.

Key take-aways

All forms of sender authentication use DNS TXT records. To implement sender auth, you may need to pull in your IT team or DNS provider.

Sender auth is used by reputation systems. Not having sender authentication implemented, or having them implemented wrong can decrease your inbox delivery.

SPF conirms your envelope from (or return-path) domain matches an IP you have authorized to send mail on your behalf.

DKIM confirms the content of the email sent is the content your recipient received and uses the domain listed in the DKIM header for authentication.

DMARC requires either DKIM or SPF to pass and also to align with the friendly from address. DMARC lets you tell mailbox providers how you want mail that doesn’t pass authentication to be treated.

BIMI uses your DMARC policy to add a logo next to your email in some web interfaces for email providers. It is the newest protocol and likely to be adopted at a much wider scale in the coming years.

Sender authentication can be very complicated to get right. If you’re looking for additional help, you can contact me via the Contact form or via email at