Domain

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

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

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 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 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 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 SBL, CBL and SpamCop. Omeda proactively monitors these and the following ISP’s 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
• Registered Site
• Verizon
• Yahoo

Content

The major ISP’s 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 ISP’s and blocklists that they are able to. These issues include, but are not limited to, ISP blocks, blocks due to listing services, or 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 (ISP’s)]:

• 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 and 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 (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 Email 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 Email Deliverability staff consistently monitors deliverability to the ISP’s and will adjust Email Builder protocol according to 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. 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 ISP’s 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 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.

• BlueTie
• Comcast
• Cox
• Earthlink
• Fastmail
• La Poste.net
• Libero (Italiaonline)
• Locaweb
• Mail.Ru
• 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 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.

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 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 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 Omeda to process any replies generated from a deployment. If a client chooses not to have the Email Builder staff process the replies, they have the option of using a reply-to email address for each deployment or Omeda 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 Email deployments are sent to the Email Inbound Mail application for processing. Email 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.

Omeda 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)

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 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 Email Builder 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, Email Builder (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, Email Builder 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, Email Builder 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, 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 full. 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 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, Email Builder 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 Email Builder to enhance delivery as well as determine accurately how the communication bounce status should be set