Search the Omeda Knowledge Base

Email – Deliverability

Domain

Domain Assignment

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

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

Omail will purchase domains for each customer. However, if the customer prefers to purchase the domain, it is the customer’s responsibility to redirect their name servers to the Omail DNS servers. Please redirect as follows:

  • namesrv.omeda.com 204.180.130.33
  • namesrv2.omeda.com 204.180.130.35

IP Address Assignment

An IP Address is an internet address for a sending domain. Each domain is assigned a unique IP address. IP addresses are assigned by the Omail staff.

Domain Name System (DNS) Servers

DNS publishes information, such as SPF and Sender ID records, about the domain. All domains used for Omail deployments are pointed to the Omail DNS servers.

Authentication

Since the major ISPs are not in agreement as to which authentication method is best, Omail utilizes the following three technologies. Therefore, the likelihood of your emails reaching the recipients’ inbox is increased.

Sender Policy Framework (SPF)

SPF record specify which machines are authorized to transmit emails for specific domains. SPF record is generated when the domain/IP addresses are assigned in the Omail application.

DKIM and DMARC

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

Omail requires 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 2-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 text based 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 whitelist the new domain/IP address.

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 XXXX, our new domain will be XXX.com, and our new IP address will be XXXXX.
To ensure you are still able to receive Product from Brand A, we recommend that you whitelist the new domain. For generic instructions on this, you can refer here: https://my.omeda.com/portal/public/whitelist.htm If you are receiving your email at a corporate domain, you may need to contact your corporate mail server admin to whitelist this domain.
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:

  • Step 1: Deploy 1000 records at the same time of day for 5 days.
  • Step 2: Deploy 2000 records at the same time of day for the next 3 days.
  • Step 3: Deploy 5000 records at the same time of day for the next 2 days.
  • Step 4: Deploy 10,000 records at the same time of day. Increase volume by 3-5,000 per day for the next 3 days.

The Omail staff (Elist) will schedule and deploy the “warm-up” emails. You can submit your creative and deployment file to elist@omeda.com. The Omail 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. The Omail staff will work closely 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 whitelisting the new domain.

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 following website provides an excellent gauge of each IP’s reputation: http://www.senderscore.org

The most widely used and therefore the most damaging blocklists are Spamhaus, SpamCop, CBL, and the Return Path blacklist. Omeda proactively monitors these and the following ISP’s for bounce and block activity related to your IP addresses and domains:

  • AOL
  • AT&T
  • Barracuda
  • Bellsouth
  • Cablevision
  • Comcast
  • Compuserve
  • Cox
  • Earthlink
  • Excite
  • Gmail
  • iCloud
  • Microsoft
  • Netscape
  • Proofpoint
  • Registered Site
  • Roadrunner
  • SBC
  • USA.net
  • Verizon
  • Yahoo

Content

The major ISP’s continue to filter based on content but this has become a much smaller factor for deliverability. Omail 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 2.0

Daily Delivery Monitoring

The Omail staff has dedicated personnel who monitor deliverability. The Omail staff monitors all deployments in order to isolate any deliverability issues. Omail will work on the behalf of our clients to resolve any deliverability issues with the ISP’s and blocklists. These issues include, but are not limited to, ISP blocks, blocks due to listing services, silent deletes, or temporary deferrals.

The Omail staff will notify the client if there are any deliverability issues with corporate domains. We will work with the client in order to resolve these issues, but ultimately, the client will need to contact their subscribers in order to resolve deliverability issues at the corporate domain level.

Internet Service Providers (ISP’s)

ISP’s have criteria that are used to determine if an email is accepted for delivery or if an email will be deferred or blocked. Primarily, the major ISP’s 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 Omail outbound mail servers are configured to apply these rules. Other criteria normally included, but not limited to, are the number of bounced emails, and the number of user complaints being received from a sending domain/IP address.

The Omail staff is consistently monitoring deliverability to the ISP’s and will adjust any Omail protocol according to any changes in the delivery criteria. Many ISP’s will initially defer emails. Deferred emails are automatically retried by our outgoing mail servers (OMS) and are normally delivered within 48 hours of the initial send time. Omail will continue to deliver all emails for up to 72 hours.

The Omail staff is well versed in the block and deferral codes returned by ISP’s and will work on behalf of our clients to have any blocks or deferrals removed in order to assist with the delivery process.

Feedback Loops (FBLs)

FBLs are a procedure established by the major ISP’s where the email address 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 ISP’s that currently offer FBLs. As other FBLs become available, Omeda will register the domains/IP addresses to them.

  • BAE Systems
  • BlueTie
  • Comcast
  • Cox
  • Earthlink
  • Fastmail
  • Italia Online
  • La Poste
  • Locaweb
  • Mail.Ru
  • MSN
  • OpenSRS
  • Rackspace
  • Synacore
  • Telenor
  • Telstra
  • Terra
  • UOL
  • USA.NET
  • UnitedOnline
  • XS4ALL
  • Yandex
  • Yahoo
  • Zoho

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 Omail Reports in the ‘Complaint’ field

White Listing

Some ISP’s will allow domains/IP addresses to be white listed once a FBL has been established if there is a steady stream of deployments and the number of complaints is minimal to non-existent. ISP’s may accept or decline a white list request based upon their criteria (which is extremely stringent). Omeda will proceed with submitting a white list request to those ISP’s that have established white lists – this currently includes: United Online, Verizon and Yahoo.

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 of the number of bounced emails. For example, AOL will 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.

Omail/Omeda offers separate Hard and Soft Bounce Thresholds. Clients can set the number of bounces allowed per email address at the brand 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 Omail deployment.

Omail 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 flagged as hard bounces and cause the hard bounce threshold number to be incremented. All other bounce messages 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.

InBox Processing

Clients have the option for Omail to process any replies generated from a deployment. If a client chooses not to have the Omail staff process the replies, they have the option of using a reply-to email address for each deployment or Omail can add an auto-forward on the account so that these replies are sent automatically to the requested email address.

All replies that are generated from Omail deployments are sent to the Omail Inbound Mail application for processing. Omail uses a rules based protocol in order to automatically process many of the emails that are received. This protocol is also used in order to eliminate emails that do not need any action taken on them, such as spam and delivery confirmations.

Omail has dedicated staff that processes all emails that are received in the Inbox. Emails are processed on a daily basis. Challenge response emails are completed within 24 hours in order to allow the email to be delivered.

Simple Mail Transfer Protocol (SMTP)

Omail 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, Omail’s MTA architecture uses dynamic rules to determine the status of an email (e.g. delivered, deferred, bounced).

When messages are deferred, Omail will continue to retry delivery for up to 72 hours from deployment start. Timing of individual retries varies depending on the reason for the deferral. A multitude of 400 and 500 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, handling 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 Omail MTA.

Scenario 1: Permanent failure code 554 is received
During the SMTP conversation we receive code 554. 554 (according to the RFC specification) indicates that the host or domain does not exist. A 500 level code is intended to mean that this is a permanent failure. However, in practice, this code may be received due to configuration issues/changes at the recipient domain. Typically, Omail (through rules configuration) will determine that this email should be retried in 24 hours. If we cannot successfully send the email within 72 hours from when the deployment was sent, this status would change to bounced.

Scenario 2: Transitory failure code 421 is received
During the SMTP conversation we receive code 421. 421 (according to the RFC specification) indicates that the “Service is not available”. A 400 level code is intended to mean that this is a transitory failure, and that the sender should retry again. This can be an indication that the remote MTA is busy, or in a shutdown state. In this scenario, Omail considers this ‘Misconfiguration at Remote Mail Site’, and will retry delivery in a short interval (typically 20 minutes.) Retries will continue until delivery is successful, or until the 72 hour cutoff is reached, at which point the email is put in a bounce state.

Scenario 3: Permanent failure code 500 is received, along with additional text
In this scenario, Omail receives code 500, which according to the RFC specification, indicates a syntax error or unrecognized command. In addition, the text accompanying the code contains the word ‘full’ (determined via rule text matching). Although not RFC compliant, this approach is used by many recipient MTAs, and indicates that the receiving mailbox is full. This is therefore not a true bounce and will be retried in 24 hours. If we cannot succeed in delivering the email within 72 hours, the retry will turn into a bounce with the reason ‘Mailbox full’. It is often the case where bounces considered permanent in the RFC specification (codes in the 500 range) can be retried and delivered after a reasonable wait period.

Scenario 4: DSN (Delivery Status Notification) Delayed Bounce
In this scenario, Omail 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 full. In this case, the DSN would indicate this reason. Using inbound processing rules, Omail 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 deferred and retried in 24 hours. After the 72 hour cutoff, if not delivered, the communication will be marked as a bounce where the reason is ‘Mailbox full’.

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, Omail uses extremely sophisticated rules to optimize delivery. These rules can be finely tuned, even to the point of setting conditions that address a specific sending domain/receiving domain combination, and take into consideration SMTP codes, accompanying text, and points in the SMTP conversation flow. This allows Omail to enhance delivery as well as determine accurately how the communication bounce status should be set

Last Updated On November 12, 2018
Tags:
Knowledge Base Feedback