Getting started

Installation & Setup

Administration

Audience Management

Email Marketing

Plug-Ins & Add-Ons

Developers

Advanced

Help

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.

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

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.

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:

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:

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.

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:

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:

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.

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:

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 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:

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 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:

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.

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:

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

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 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.

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 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;

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;

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:

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;

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

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;

These events will boost your email delivery reputation.

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;

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.

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.

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;

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.

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:

Trailing Segments

Example:

Randomized Segments

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

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.

On this page