Email – Deliverability
- Bettina Lippisch
Domain Assignment
Omeda is predicated on the idea that each brand has a unique domain. We believe that this is the best practice in order to establish a reputation for the domain and IP address, as well as the most efficient set up in order to resolve any deliverability issues for the domain.
Clients may also choose to assign a unique domain to each type within the brand. If each type has its own domain, the deployments sent from each type will not be affected by the other types of deployments sent from this brand. For example, third party promotions would not affect the deliverability of a daily newsletter.
Omeda supports the use of subdomains. In the configuration, each subdomain is assigned a unique domain name. Please note that when using subdomains, it is possible that if the parent domain is blocked for any reason, all sub-domains may also be affected by this block.
Omeda will purchase domains for each customer. However, if the customer prefers to purchase the domain, it is the customer’s responsibility to point the domain or subdomain of their root domain to the Omeda DNS servers. Please redirect as follows
IP Address Assignment
Your sending domain will then be either assigned to a sending pool or to a dedicated IP. Small senders benefit most from the sending pool since the reputation has already been established and each sender contributes to maintaining a steady flow of outgoing mail. A dedicated IP can be used by large senders since they have the ability to have volume and cadence, which is important to building and maintaining the reputation of the IP.
Domain Name System (DNS) Servers
DNS publishes information, such as SPF and Sender ID records, about the domain. All domains used for Email deployments are pointed to the Omeda DNS servers.
Authentication
Since the major ISPs are not in agreement as to which authentication method is best, Omeda utilizes the following three technologies. Therefore, the likelihood of your emails reaching the recipients’ inbox is increased.
Sender Policy Framework (SPF)
The SPF record specifies which machines are authorized to transmit emails for specific domains. An SPF record is generated when the domain/IP addresses are assigned in the Email application.
DKIM and DMARC
Omeda uses DKIM for sending domains. The DKIM technology adds an encrypted ‘signature’ to the header of the email message, which can be used by receiving servers to authenticate the email. Email Builder has a publicly published domain key that receiving servers use to decrypt the ‘signature,’ thereby verifying that the email is legitimate. The DMARC technology is an email-validation system designed to detect and prevent email spoofing. It is intended to combat certain techniques often used in phishing and email spam, such as emails with forged sender addresses that appear to originate from legitimate organizations.
If subdomains are being used, DKIM records is established for each subdomain.
New Domain/IP address Warm-up
Omeda recommends that each new domain/IP address go through a warm up period in order to establish a reputation for the domain/IP address. The warm up period will depend on the email volume expected to deploy from each domain/IP address. Generally, a warm up period will take approximately 1-3 weeks. This should be started before regular deployments are scheduled in order for the last warm up to be sent the day before the first ‘real’ deployment goes out.
We recommend that the content for the warm up deployment be a customer-service oriented email. This will alert the recipient that the current sending domain/IP address will be changing on {specified date} and asks them to add the new domain/IP address to their ‘safe senders’ list.
Below is an example of an email that can be sent during the warm up period:
Dear @{firstname}@, As a valued subscriber of Brand A’s Product, we would like to inform you of an upcoming domain and IP address change. Starting MMDDYYYY, our new domain will be ***.com. To ensure you are still able to receive Product from Brand A, we recommend that you add the new domain to your ‘safe senders’ list. For generic instructions on this, you can refer here to our Whitelisting Information page. If you are receiving your email at a corporate domain, you may need to contact your corporate mail server admin to add this domain to the ‘safe senders’ list. Sincerely, Brand A Customer Service To unsubscribe from future Products from Brand A, please click here: @{confirmunsubscribelink}@ (or other unsubscribe link) Contact Us: Brand A Postal Address
Below is a sample schedule for establishing a good reputation:
The Omeda team will schedule and deploy the ‘warm up’ emails. You can submit your creative and deployment file to your Omeda team. The Omeda staff will submit all requests for feedback loops from the major ISP’s (where available). Deliverability is closely monitored for each deployment and unblock requests submitted when necessary. The schedule listed above may be modified, depending on any deliverability issues that are found.
This schedule may also be modified depending on the volume expected to deploy from the domain/IP address. We may need a longer warm up period for those domains/IP addresses that will be sending a higher volume of email and a shorter period for smaller volumes. You may be able to do ‘self-warming’ for the volumes under 6,000. This is where you will break down the audience into smaller segments and send over a few hours/days for live deployments. The Omeda team will work with you in implementing the schedule.
In conjunction with this, we also recommend that you include a notification regarding the domain change in the emails sending from your current domain. This will also help your customers with adding the new domain to the ‘safe senders’ list.
Please note that when changing ESP’s, it is common to see a drop in your open and click metrics due to the new sending IP. The warm up campaign will help to mitigate that decrease but cannot alleviate it entirely. Within 1-2 weeks of your go-live, the Omeda team will schedule a meeting to review the metrics.
You will most likely see some corporate domains where there is no activity – no bounces, no opens, no clicks, no unsubscribes. In actuality, the receiving server is ‘dropping it on the floor,’ which indicates they are not delivering to the recipients’ inbox. The Omeda reports can easily identify where that is occurring – please see the Delivery by Receiving Domain report here.
Methods you can use to gain delivery include
personal reach out to customers at that domain, asking them to add your domain/IP’s to their ‘safe senders’ list. It can be very helpful for a recognized name/editor at your company to send a personal email to customers
reach out to the mail admin at those domains
create a personalization modal to pop up on your website when visitors at those domains are detected
if you still have access to your prior ESP, send a few follow-up emails to customers at the blocked domains. Subject lines such as “Have you missed us” can definitely help.
Deliverability Reputation
The reputation associated with a domain/IP address is vitally important in regards to deliverability. The higher the reputation the greater the chance the email will be delivered to the Inbox. Many ISPs use the domain/IP address reputation as one of the criteria that determines if the email will be blocked.
A domain reputation is established by a client’s audience development practices, their email practices, the engagement level of the recipients, their bounce management, and most importantly, the number of recipients that click the “this is spam” button.
The most widely used and therefore the most damaging blocklists are Spamhaus SBL, CBL and SpamCop. Omeda proactively monitors these and the following ISPs and business filters for bounce and block activity related to your IP addresses and domains:
AOL
AT&T
Barracuda
Comcast
Cox
Gmail
iCloud
Microsoft
Proofpoint
Verizon
Yahoo
Content
The major ISPs continue to filter based on content but this has become a much smaller factor for deliverability. Omeda does assign a spam score based on Spam Assassin to both the html and text content of each email. It is advisable to keep the score below 5.0.
Daily Delivery Monitoring
Omeda has a dedicated Email Deliverability team that monitors deployments in order to isolate deliverability issues. They work on behalf of Omeda clients to resolve those deliverability issues with the ISPs and blocklists that they are able to. These issues include, but are not limited to, ISP blocks, blocks due to listing services, and temporary deferrals.
When an IP or domain is blocked, here are some of the steps that are taken:
Inform the Client Success Manager/client of the block since blocks have the potential to damage Omeda’s network and impact delivery
The Client Success Manager works with the client to identify the possible cause and provide steps to better target the audience list (use engagement data, for example)
The Email team will try to mitigate the block by submitting a blocklist removal request
For temporary deferrals [more information can be found below under Internet Service Providers (ISPs)]:
Inform the Client Success Manager/Client if a significant number of temporary deferrals from an ISP permanently bounce after 72 hours
The Client Success Manager works with the client to identify the possible cause and provide steps to better target the audience list (use engagement data, for example)
The Email team will try to work with the provider to get the emails delivered
The client is not normally notified of blocklists that typically do not impact delivery. However, these blocks can serve as early warnings that there may be problems with a sender’s list. Blocklists have become even more sensitive to Spam and customers should regularly review their email reports, remove inactive and unengaged email addresses, and follow email deliverability best practices.
The Email Deliverability team may also notify clients if they notice significant deliverability issues with corporate domains. The Email Deliverability team and the Client Success Manager will work with the client in order to resolve these issues if possible, but ultimately, the client will need to contact their subscribers in order to resolve deliverability issues at the corporate domain level.
Internet Service Providers (ISPs)
ISPs have criteria that are used to determine if an email is accepted for delivery or if an email will be deferred or blocked. The major ISPs have published protocol for the number of concurrent connections sent from a sending domain/IP address and the number of emails contained in each connection. The Email outbound mail servers are configured to apply these rules. Other criteria normally included, but not limited to, are the number of bounced emails, users’ interaction with emails, and the number of user complaints being received from a sending domain/IP address.
Many ISPs will initially defer emails. Deferred emails are automatically retried by our outgoing mail servers and are normally delivered within 48 hours of the initial send time. Email Builder will continue to attempt to deliver emails for up to 72 hours.
The Email Deliverability staff is well versed in the block and deferral codes returned by ISPs and will work on behalf of our clients to attempt to get blocks or deferrals removed in order to assist with the delivery process.
Feedback Loops (FBLs)
FBLs are a procedure established by the major ISPs where the email addresses of all recipients that click the “this is Spam” button are returned to the sender.
Omeda will register all domains/IP addresses to the available FBLs. Listed below are the ISPs that currently offer FBLs. As other FBLs become available, Omeda will register the domains/IP addresses to them.
BlueTie
Comcast
Cox
Earthlink
Fastmail
Libero (Italiaonline)
Locaweb
MSN
OpenSRS/Hostedmail (Tucows)
Rackspace
Synacore
Telenor
Telstra
Terra
UOL
XS4ALL
Yandex
Yahoo
Complaints received from the FBL are processed automatically. The email recipient is then opted out of all deployment types from that brand.
User complaints for each deployment are reported in the Email Builder Reports in the ‘Complaint’ field
Allow List/White Listing
Some ISPs will allow domains/IP addresses to be white listed once an FBL has been established if there is a steady stream of deployments and the number of complaints is minimal to non-existent. ISPs may accept or decline a white list request based upon their criteria (which is extremely stringent).
Bounce Management
The management of bounced email addresses is important in regards to deliverability. ISPs will begin to block mail from a sending domain/IP address if it exceeds their limits on the number of bounced emails. For example, AOL may block a sending domain/IP address if 10% or more of the AOL email addresses bounce.
Deploying to a large number of bad email addresses will hurt the reputation of the sending domain/IP address.
Omeda offers separate Hard and Soft Bounce Thresholds. Clients can set the number of bounces allowed per email address at the database level. This number should be set after considering the frequency and volume of email deployments for that brand.
Once an email address has met either of the bounce thresholds, the email address will be flagged as invalid. All email addresses flagged as invalid should be excluded from any query used to create an audience list for an Email Builder deployment.
Omeda differentiates between ‘soft’ and ‘hard’ bounces in accordance with industry standards. Emails that bounce and return a message which indicates a true non-deliverable (domain or email account does not exist) are not retried in the 72 hour period and are flagged as hard bounces, causing the hard bounce threshold number to be incremented. All temporarily deferred messages (except for DSN Misconfiguration message) are retried for 72 hours with variable intervals specific to the particular bounce reason (from 15 min to 30 hours between retries). If they cannot be delivered in the 72 hour period, they are counted as a soft bounce and the soft bounce threshold number is incremented.
Simple Mail Transfer Protocol (SMTP)
Omeda uses an RFC 2821 based SMTP MTA (Mail Transfer Agent) to send deployment and transactional emails, and receive email responses (e.g. DSN). Individual email messages are sent via the SMTP protocol through a conversation between an Omeda server and a remote MTA. Based upon the outcome/status codes from the conversation, Omeda’s MTA architecture uses dynamic rules to determine the status of an email (e.g. delivered, deferred, bounced).
When messages are deferred, Email Builder will continue to retry delivery for up to 72 hours from the start of the deployment. Timing of individual retries varies depending on the reason for the deferral. A multitude of 4** and 5** SMTP codes can be received, and via rules configuration, indicate that a retry is necessary. SMTP codes are augmented by text-matching rules to further narrow down what status should be assigned to a communication as well as handle scenarios in which recipient ISPs are not adhering strictly to the RFC standards.
A few examples may be helpful. These are conceptual, and are examples of the kind of rule processing that takes place within the Email Builder MTA.
Scenario 1: Permanent failure code 5** is received
During the SMTP conversation we receive code 5**. A 5** level code can have different variations and error messages, but they all indicate a failure to deliver the email. These messages will be automatically moved to Bounced status and will not be retried, based on industry standards for handling bounces.Scenario 2: Transitory failure code 4** is received
During the SMTP conversation we receive code 4**. A 4** level code is intended to mean that this is a transitory failure, and that the sender should retry. This can be an indication that the remote MTA is busy, or in a shutdown state. In this scenario, Email Builder will retry delivery within a short interval. Retries will continue until delivery is successful, or approximately 72 hour cutoff is reached, at which point the email is put in a bounced state.
Scenario 3: DSN (Delivery Status Notification) Delayed Bounce
In this scenario, Email Builder successfully delivers an email to a remote MTA. The communication is therefore considered to be delivered successfully. However, at some later time (typically within an hour) an inbound DSN message is received indicating that the final delivery was not successful. This can happen, for example, if the remote MTA, after accepting the email for delivery, determines that the recipient’s mailbox is inactive . In this case, the DSN would indicate this reason. Using inbound processing rules, Email Builder determines the communication to which this email pertains and uses text-matching rules to determine which status code should be assigned to the email. In this case, the communication would be marked as a bounce where the reason is ‘Permanent Deferral.’Scenario 4: Deferral–Non-RFC DSN Misconfiguration at Remote Site
This is our generalized message for when the receiving server does not return any of the standard RFC messages. We don’t have insight as to why the receiving server returns that message. These messages are not retried.
As there are many exceptions to the rules outlined in the RFC specification, and many organizations do not adhere strictly to the RFC SMTP specification, Email Builder uses extremely sophisticated rules to optimize delivery. These rules can be finely tuned based on the SMTP codes, accompanying text, and points in the SMTP conversation flow. This allows Email Builder to enhance delivery as well as accurately determine how the communication bounce status should be set.