Getting started

What’s New

Roadmap

Octeth Training Program

Installation & Setup

Requirements

Architecture

Server Setup

Oempro Installation

Community Edition Install

SSL Certificates

Version Upgrade

Troubleshooting

Video Tutorials

Video Tutorials

Administration

Quick Walkthrough

Security

Sub Admin Accounts

Settings

Delivery Servers

Global Segments

Global Custom Fields

Bounce Processing

Spam Complaints

Suppression List

Plug-Ins

Delivery Report

User Management

Maintenance

Audience Management

Introduction

Subscriber Lists

Custom Fields

Segments

Subscribers

Webhooks

Website Event Tracking

Email Marketing

Introduction

Auto Responders

Email Campaigns

Sender Domain Man.

Journeys (Automation)

Bounce Processing

Email Personalization

FBL Processing

Email Builder Integrations

Email Deliverability

Sender Domain Management

Plug-Ins & Add-Ons

AI Plug-In

RSS Plug-In

Bounce Catcher Add-On

Link Proxy Add-On

Developers

Introduction

Single Sign On

API

Plug-In Development

Database

Advanced

Reverse Proxy

Cookbook

Help

Troubleshooting

Contact Us

Email Deliverability

Getting Started

Email marketing is like a two sided coin. One side is the “frontend” which is all about managing your email campaigns, audiences, auto responders, metrics and the other side is “backend” which is all about email deliverability, technical compliance and legal compliance.

No matter how perfect email strategy you build, without a solid email deliverability setup and plan, you will fail.

In this article, we cover all fundamental components of the email deliverability. Each one of these components must be studied and applied to your email marketing activities whether you use an in-house or hosted email marketing system.

Terminology

Before we dive into email deliverability details, let’s study some primary email deliverability terms.

Technical Configuration

Whether you run your in-house email delivery server or use a hosted third party service, you must make sure that each one of these technical configuration items is set properly.

IP Address & PTR

When you create and send an email campaign on your email marketing software, it renders that email for each recipient and delivers them to your MTA. MTA stands for “Mail Transfer Agent”. The mission of MTA is to queue incoming emails and deliver them to recipient mail servers.

During the transmission of emails from your MTA to the recipient mail server, the connection is made from your MTA IP address to the recipient mail server IP address.

Your MTA IP address must be a valid public IP address.

Spam filters and mail servers classify incoming emails based on many different factors but one of the most important factors is your MTA IP address and its corresponding PTR record.

Let’s say your MTA IP address is 198.61.254.100. The PTR of this IP address is so254-100.mailgun.net.

Make sure that your MTA IP address PTR record also matches your MTA IP address. On Mac or Linux operating systems, you can test this quickly by running two commands:

$ dig -x 198.61.254.100 +short

so254-100.mailgun.net.

The result of the command above is so254-100.mailgun.net. which means, this domain is the PTR of the given IP address.

Now, let’s query this domain’s A record to see if it matches the IP address:

$ dig so254-100.mailgun.net +short

198.61.254.100

As you can see, 198.61.254.100 → so254-100.mailgun.net → 198.61.254.100 which is ✅

You must make sure that your MTA IP address and the corresponding PTR record are not blacklisted on any major blacklist services. You can use https://multirbl.valli.org/ for instant checks and IPMonitor.app for automated monitoring and getting alerts when your IP addresses or domains are blacklisted.

MFROM Setup

The email is no different than a regular mail. During the delivery of the email from your MTA to the recipient mail server, your MTA is required to say who the sender is (in a regular, it’s the sender written on the top left corner of the envelope). This sender is called MFROM (or Mail From).

Here’s a quick example of how the communication starts and proceeds between your MTA and the recipient mail server:

• Your MTA asks for the mail server IP address of the recipient email address domain.
• Your MTA connects to the recipient mail server
• Your MTA says “Hi”
• Recipient mail server greets your MTA
• Your MTA starts secure connection if needed (TLS) and recipient mail server acknowledges it
• Your MTA says it has an email to be delivered sent by test@test.com
• ...

As you can see above, your MTA will say who the sender of the email is. This is done by the following SMTP command during the communication:

...
MAIL FROM: <test@test.com>
...

This MFROM email address is very important. The domain of the MFROM email address must be set properly, otherwise, you will have high chance of serious delivery issues.

The MFROM email address domain must have a few configurations in order to make it ready for sending emails on behalf of it.

The A Record

The MFROM domain doesn’t need to have a valid A record which means, it doesn’t have to be pointing to a website. But it’s always a good approach to set an A record and point it to your website or a one-page landing page explaining the purpose of the domain. This is an optional setup but highly recommended.

The MX Record

However, it must have a valid MX record(s). MX record(s) identifies the responsible mail servers for the MFROM domain. Because all DSN (Delivery Status Notification) emails such as bounce reports, auto-replies, etc. will be delivered to this MFROM domain. An missing or misconfigured MX record will lower the chance of building a long-lasting email delivery reputation.

Make sure that you have at least one valid MX record for your MFROM domain and it accepts DSN emails that are being sent to your MFROM domain.

SPF Setup

Sender Policy Framework (SPF) is the first email authentication policy implemented in 2014. The detailed technical instructions of SPF can be found in RFC 7208.

The purpose of SPF is to prevent sending emails on behalf of a sender domain through unauthorized MTA IP addresses.

This policy is defined by adding a special TXT record to the sender domain DNS zone. This TXT record identifies what IP addresses are authorized to send emails on bahelf of this sender domain.

Here’s an example SPF record:

mytestdomain.com TXT "v=spf1 ip4:198.61.254.100 -all"

This SPF record authorizes the 198.61.254.100 IP address to send emails on behalf of mytestdomain.com domain. It also suggests receiving mail servers to follow strict SPF policy for sender MTA IP addresses which are not authorized in this SPF record.

You can use MX Toolbox’s SPF Generator tool to generate an SPF record for your sender domains.

DKIM Setup

DKIM stands for DomainKeys Identified Mail. It’s a policy that allows an organization to take responsibility for sending an email by signing it in a way that recipient mail servers can verify. For more details about DKIM, you may check RFC 6376.

The purpose of DKIM is to protect email senders and recipients from spam, spoofing and phishing.

Basically, when your MTA is delivering email to the recipient mail server, your MTA adds a digital signature to the headers of the email. This digital signature is generated based on email header properties.

When the email is received by the recipient mail server, it looks up the sender’s public DKIM key in DNS. The recipient mail server uses this key to decrypt the signature and compare it against a freshly computed version. If the two values do not match, DKIM validation fails.

For more information about DKIM, please check DKIM.org.

DKIM private key and DNS records can be created by various methods. If you are using PowerMTA, you can create a DKIM key on the command line:

pmtakeytool newdk oct mydomain.com 1024

This command will create a special private key and a DNS record to be added to the mydomain.com sender domain DNS records. A DKIM key can be 1024-bit or 2048-bit key.

The public key must be added to the sender domain DNS records with a <selected>._domainkey host name and value of k=rsa; p=........

Please make sure that your MTA server is properly configured to use the generated private key and selector.

You can use DKIMValidator.com to validate your DKIM setup.

DMARC Setup

DMARC is a special configuration on the sender domain DNS records that is used to authenticate an email by SPF and DKIM mechanisms. By having DMARC in the sender domain DNS zone, sender domain owners can prevent email compromise, phishing and spoofing.

You can tell the recipient mail server what to do when an authorized email is received with your sender domain:

• p=none No action is taken. The email traffic is monitored.
• p=quarantine Sends the email to the spam folder of the recipient.
• p=reject The unauthorized email will be rejected and never gets delivered to the recipient.

DMARC is a policy that compiles SPF and/or DKIM mechanisms. In order to activate the DMARC protection, you need to add a DNS record to the sender domain.

DMARC DNS record is a TXT record that tells the recipient mail server what to do when an email with a failed SPF and/or DKIM check is received. You can use MX Toolbox’s DMARC generator tool to generarte the required DNS record for your sender domains.

MX Setup

The technical specifications explained in RFC 5321 suggests having a MX server for your sender domain is optional. This means that you may have a sender domain (MFROM domain) with no MX server.

However, in today’s world, we strongly recommend you to have a working MX server that accepts incoming emails for your sender domain. Otherwise, you may have delivery issues. Your emails might be discarded or delivered to the spam folder.

RFC 2142 also explains some specific mailbox usernames to be valid and accepting email no matter what.

Please note that having an MX DNS record for your sender domain is not enough. That MX server must be accepting emails for your sender domain.

Take a look at the following example command sequence to test this. Let’s say your sender domain is sendloop.com and you want to test if sendloop.com has valid MX server setup.

First, let’s learn the MX server of mailgun.com:

$ dig +short sendloop.com mx

1 aspmx.l.google.com.
10 alt3.aspmx.l.google.com.
10 alt4.aspmx.l.google.com.
5 alt1.aspmx.l.google.com.
5 alt2.aspmx.l.google.com.

sendloop.com has 5 MX servers. Let’s pick any of them and test if the MX server is accepting messages for sendloop.com:

$ telnet aspmx.l.google.com 25

Trying 64.233.167.26...
Connected to aspmx.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP p8-20020a5d59a8000000b0020c4d8bc8fcsi9520477wrr.26 - gsmtp
ehlo local
250-mx.google.com at your service, [139.162.186.10]
250-SIZE 157286400
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8
mail from: <thisis@test.com>
250 2.1.0 OK p8-20020a5d59a8000000b0020c4d8bc8fcsi9520477wrr.26 - gsmtp
rcpt to: <postmaster@sendloop.com>
250 2.1.5 OK p8-20020a5d59a8000000b0020c4d8bc8fcsi9520477wrr.26 - gsmtp

As you can see above, our test attempt for postmaster@sendloop.com returned 250 SMTP code which means a success.

When sending a bulk email, most of the time, MFROM email will be a unique email address for each recipient. This is called VERP. Variable envelope return path (VERP) is a technique used by Octeth to enable automatic detection and removal of undeliverable e-mail addresses.

Therefore, make sure that your MFROM domain MX server has catch-all setting enabled that accepts all incoming emails. Otherwise, relaying denied error will be returned by your MX server and this will prevent delivery status notification emails (bounce reports) to be received.

MTA Setup

MTA stands for Mail Transfer Agent. It’s the email delivery server that receives the rendered email from Octeth, queues it and delivers it to the recipient mail server. An email will be delivered by your MTA via one IP address. Therefore, make sure that you have read IP / PTR topics earlier in this chapter and also set SPF record properly for your domains.

There are many MTA’s in the market such as Postfix, Qmail as well as PowerMTA, Green Arrow, MailerQ, MailEnable, etc. Each MTA has its own settings and feature sets. Setting your MTA for bulk email delivery requires more precise settings such as maximum number of connections that can be made for each domain, maximum message rate for each domain, backoff settings, etc.

Refer to your MTA documentation to learn more about optimum settings for bulk email delivery.

Best Practices

We have compiled very important best practices under this chapter. Following and applying these best practices will ensure that you have a long lasting and stable email delivery reputation.

Domain Alignment

Domain alignment lets you apply your domain throughout your email, starting from the MFROM email address, all the way to the links you add into the email.

Having a domain alignment in your email campaigns will ensure higher email delivery success rate as email filters love it for many reasons!

You have these domains in your emails;

• MFROM domain Example: bounces.mysenderdomain.com
• DKIM domain Example: sl._domainkey.mysenderdomain.com
• FROM domain Example: mysenderdomain.com
• Tracking domain Example: track.mysenderdomain.com
• Link domain Example: mysenderdomain.com
• Image domain Example: mysenderdomain.com

When you have domain alignment applied to your email, it means the same domain is used across all these email parameters from MFROM to links.

Domain alignment (also called identifier alignment) is a mechanism that ensures an authenticated email domain aligns with the domain found in the 'From' header address, which represents the sender's identity.

Domain alignment starts with SPF and DKIM authentication. Therefore, make sure you have setup SPF and DKIM properly for your domains.

When you have domain alignment in your email campaigns;

• Higher trust: Email filters love domain alignment. Your deliverability will improve.
• Better brancing: Links inside your emails will be recognizable by recipients. You will receive less spam complaints.
• Better sender reputation: Having your own domain will give you more control over your deliverability and sender reputation.
• Better DMARC implementation: The side affect of domain alignment is SPF alignment. You will have better DMARC implementation.

IP & Domain Reputation

When it comes to email delivery, your email delivery history plays an important role. But, how do they check your email delivery history? They do it via your MTA IP address and domains:

• Your MTA IP Address
• MFROM domain
• DKIM domain
• FROM domain
• Tracking domain
• Link domain
• Image domain

ISP’s keep a history of each one of these email components. When you send an email, they know how many complaints you have received, how many bounces you have caused, how many engagements you got from your audience. Based on these “event” metrics, they calculate a reputation score for you. Based on this score, they do one of the following;

• They accept the email and deliver it to the recipient inbox.
• They accept the email and delivery it to the spam folder.
• They accept the email but do nothing. The email is discarded.
• They accept the email, they discard it and send a DSN report (bounce report) to the sender domain
• They reject the email during the SMTP delivery.

When you start sending from a fresh IP address or domain, you must be very careful about;

• Number of emails you send on hourly and daily basis
• Number of emails you send to each ISP
• Number of bounces you receive
• Number of complaints you receive
• Number of opt-out requests you receive

If you start sending 1 million emails on day 1 from a fresh IP address or domain, your emails will be blocked. But instead, you can apply a warm-up process such as;

Once you follow a warm-up plan for your new sender IP and domain name, you will have a long lasting email delivery reputation and your IP address and/or sender domain will less likely be throttled.

In addition to events that we have listed above for negative reputation impact, we have also events that affect in a very positive way;

• Number of email clicks and opens (different than email open detection)
• Number of email replies
• Number of recipients who star your emails

These events will boost your email delivery reputation.

List Hygiene

Building (and protecting) your email delivery reputation starts before sending emails: By maintaining hygiene of your subscriber lists. When you send an email campaign to a list and get a high bounce rate, it’s too late because you have already got the damage on your sender reputation.

There’s a way to avoid (or minimize) this risk. Maintaining your list hygiene. This means, scanning the subscribers in your email list and removing;

• Invalid (hard bounced) email addresses before sending an email to them
• Role-based email addresses (support@, sales@, etc.)
• Risky email addresses (disposable email addresses, catch-all email addresses, etc.)
• Unresponsive email addresses

These email addresses that listed above will ruin your email delivery reputatio when you send even one email to them. You can get hit by a spam trap and you can receive a high bounce rate. These problems will cause your sender IP address and domain to get blaclisted or flagged quickly. And once you get listed in a blacklist, it’s very difficult and challenging to remove your IP address or sender domain from the blacklist.

There are many list hygiene and email verification services in the market. Octeth has a built-in integration with Cleanify.io email list verification and list hygiene service. You can simply activate the Cleanify.io plugin in [Admin Area → Settings → Plug-Ins] section and connect it to your Cleanify.io account in a few seconds.

Once the integration is completed, Octeth will display “List Verification” link on the subscrier list dashboard and you can run a bulk email list verification on the entire subscriber list or any segment of the list with a single click.

In addition to this, you can enable instant email address verification so that during the subscription process, the email address can be checked in real-time and risky ones can be eliminated even before sending a double opt-in confirmation email.

Double Opt-In Subscription Process

A new subscriber asks to be subscribed to the mailing list, but unlike unconfirmed or single opt-in, a confirmation email is sent to verify it was really them. Generally, unless the explicit step is taken to verify the end-subscriber's e-mail address, such as clicking a special web link or sending back a reply email, it is difficult to establish that the e-mail address in question indeed belongs to the person who submitted the request to receive the e-mail (wikipedia).

Unlike many European countries anti-spam laws, CAN-SPAM doesn’t require you to apply a double opt-in process, however, double opt-in keeps your email list clean and protects your sender reputation.

Do not forget that the only way of building and maintaining a long lasting sender reputation is keeping your email lists away from hard bounces and spam trap hits.

Audience Engagement

The only way to build and maintain a healthy (and long lasting) sender reputation is based on the engagement rate of your audience. There are many ways to engage your audience;

• They send a reply to your email
• They click a link inside your email
• They click and open your email

These are three very powerful engagement activities (sorted by the priority) that your audience members can do with your emails. Each one of your emails must have a goal of triggering any of these engagement events.

Audience Segmentation

Sending the right message to the right person is very important. Creating an email campaign and sending it as a bulk email to your entire audience doesn’t work any more. People want relevant message prepared for themselves.

This can only be achieved by segmentation.

Octeth provides you many powerful segmentation features such as attribute and activity based regular segments, trailing segments and randomized segments.

Regular Segments

Some examples:

• Anyone who [has a @gmail.com email address] AND [opened at least 1 email in the last 10 days] AND [Subscribed in the last 30 days]
• Anyone who [has a @gmail.com email address] AND ([opened at least 1 email in the last 10 days] OR [Subscribed in the last 30 days])
• Anyone who ([opened at least 1 email in the last 10 days] AND [has a @gmail.com email address]) OR ([subscribed in the last 5 days] AND [has a @gmail.com email address])
• Anyone who [is from San Francisco]
• Anyone who [has clicked https://unifund.com link at least 1 time in one of the last 10 sent emails]

Trailing Segments

Example:

• Anyone who have subscribed yesterday
• Anyone who has a trial expiring in 15 days
• Anyone who has made a purchase today

Randomized Segments

Multiple Delivery Server Utilization

Octeth has a powerful multi-delivery server feature that gives you ability to reroute outgoing emails through different delivery servers based on;

• the attributes and/or activities of the recipient
• the user account sending the email campaign

Just to give you an example, you can setup SES, Mailgun, Sendloop SMTP delivery servers in your Octeth server and reroute all emails going to @gmail.com email address through SES, all @yahoo.com and @aol.com email address through Mailgun and all openers and clicks through Sendloop SMTP.

Resources

• Gmail Best Practices
• Yahoo Best Practices
• Gmail Postmaster Tools
• Microsoft SNDS
• Cleanify.io email list verification and list hygiene service
• IPMonitor.app email blacklist monitoring service

On this page

• Email Deliverability
• Getting Started
• Terminology
• Technical Configuration
• IP Address & PTR
• MFROM Setup
• SPF Setup
• DKIM Setup
• DMARC Setup
• MX Setup
• MTA Setup
• Best Practices
• Domain Alignment
• IP & Domain Reputation
• List Hygiene
• Double Opt-In Subscription Process
• Audience Engagement
• Audience Segmentation
• Multiple Delivery Server Utilization
• Resources