Email Deliverability

Email Deliverability is commonly known as the science behind delivering both bulk/marketing and transactional emails to opt-in recipients.

This topic provides information on best practices, troubleshooting undelivered emails, and other ways that senders can improve inbox placement.

Deliverability Best Practices

These email deliverability best practices help you both learn and manage the habits that affect your sending reputation which, in turn, can help more email get delivered.

By following these recommendations, senders can lower both bounce and complaint rates, stay off blocklists, and improve your company’s sending reputation.

Implement an Opt-in Process

The opt-in process is how recipients subscribe to your bulk/marketing lists which gives you permission to send them email. Only send messages to subscribers who have opted-in to your mailing list, avoiding buying or renting lists at all costs.

There are two types of opt-in methods. Note that these methods apply to bulk/marketing email as transactional emails are sent based on an action that requires proof:

  • Single opt-in (unconfirmed): A user provides their email address and gives the sender permission to receive relevant messages. After the address is provided, messages can be sent without confirming the email address belongs to the user who provided it. The risks in using single opt-in are exposure to list bombing through a targeted attack on a signup form, and by those signing up email addresses that don’t belong to them.

  • Double opt-in (confirmed): A user provides their email address, but before the first campaign is sent, they receive a confirmation email to the address that signed up. That email requires action from the account owner to confirm that future messages are wanted, most frequently done with a verification click. The double opt-in method ensures that the address was not added without consent and keeps electronic proof if future data privacy inquiries or audits arise.
Purge Unengaged Users

One of the easiest and best ways to help keep your marketing lists clean is to remove unengaged users: those addresses which haven’t opened or clicked within an email in a certain amount of time. Unengagement is a strong indication that the recipient is no longer interested in your content or that the account has been abandoned.

Remove recipients who have not engaged with your email in a timeframe defined by your business model but no longer than two years. By doing so, you show major inbox providers that you are keeping an updated database which helps boost your sending reputation. You also avoid the potential of hitting spam traps as some mailbox providers convert inactive inboxes to help prevent scraping of email addresses.

Database Cleanliness

Keeping an overall clean and up-to-date database is important in addition to removing unengaged users. The best way to keep a clean database is to sync with Email Delivery using API calls so any hard bounces, unsubscribes, and suppressions are marked as such.

That constant sync helps lessen processing time when sending emails, ensures that your database is always updated, and minimizes the chance you send to an address that you should no longer be sending to.

Evaluate Your Sending Frequency

Sending too many emails in a short time might aggravate your recipients, causing them to either unsubscribe or mark your campaigns as spam. By regularly reviewing your strategies, open rates, and other key metrics, you can reduce list fatigue and better learn how they want to engage with you.

Offer the ability to reduce the amount of emails they receive (for example, yearly, quarterly, or monthly), giving you a better chance at retention rather than them unsubscribing altogether. Recipient tastes and wants for email changes over time. Ensure that you’re changing with it.

Provide an Easily Accessible Unsubscribe URL

Don’t attempt to hide your unsubscribe link as by doing so, you only further encourage your recipients to click the spam button, further hurting your reputation. Some providers will also hold it against you in their algorithm if you use a light color for your unsubscribe link and language.

If someone wants to be removed from your list, make the link easy to find and include it in both the header and footer. Offer a single-click unsubscribe option in addition to a preference center where they can reduce the frequency of emails, opt in to a different list, and so on.

CAN-SPAM, GDPR, CASL, and Privacy Laws

Knowing how to handle, process and market to consumer data in a legally permissible way is a must.

There are several regulatory measures and laws that help protect consumers around the world. One of the oldest is the CAN-SPAM Act, a piece of U.S. legislation that established requirements for “commercial” email.

Not using deceptive subject lines, honoring unsubscribes quickly, and having a physical address in the footer of emails are just some of the requirements outlined with violations resulting in fines.

Similarly, there is also CASL, a Canadian-based anti-spam set of laws that was heavily based on CAN-SPAM. While based in Canada, the law applies to those who email Canadian residents.

Data privacy has become a hot topic in the last few years which is why knowing about the General Data Privacy Regulation (GDPR) is key. Active in 2018, the law regulates data privacy and protection in the European Union and has become a model for other countries’ privacy laws.

Oracle Cloud Hosting and Delivery Policy

Often, the Oracle Cloud Hosting and Delivery Policy is more stringent than some of these industry requirements. It is important that you review Oracle policies before using the service.

Discussing your approach to data privacy and regulation with the appropriate personnel within your company is highly recommended.

Troubleshooting Undelivered Emails

The following issues can cause an email to be undelivered:

  • The recipient is on the Suppression List.
  • An authentication failure or an issue with the format of the email message occurred. For example, if the SMTP "From" address is not the same as the "From" address in the email body, the email is rejected. The addresses must match and be an Approved Sender. Refer to your sending application's logs to review any issues.
  • Use of multiple addresses in the email From header is discouraged. If you use multiple addresses, it increases the possibility that your mail is placed in a spam folder or discarded (because of DMARC From alignment rules). The performance of your emails is reduced because all addresses have to be authorized as approved senders. A best practice for the SMTP envelope From address is to match the header From address when you submit mail to Email Delivery. If you use mismatched addresses, it reduces the performance of your emails because both addresses need to be authorized as approved senders. Certain future platform features will not be available if you use mismatched addresses.
  • Lack of SPF or DomainKeys Identified Mail (DKIM).

If you are unable to resolve the issue, you can go to My Oracle Support and create a service request. See Open a support service request for more information.

Additional Options to Increase Deliverability

DomainKeys Identified Mail (DKIM)

DKIM is an authentication framework you can set up to help ensure good email delivery reputation. See Managing DKIM for instructions on setting up DKIM.

SPF

A Sender Policy Framework (SPF) lets domain owners identify servers they have approved to send emails on behalf of their domain. In Oracle integration's case, domain owners need to approve OCI as an approved sender and to add a record for it in their domain. See Configure SPF for more information.

Domain-based Message Authentication, Reporting, and Conformance (DMARC)

DMARC is a technical specification created by a group of organizations that want to help reduce the potential for email-based abuse by solving long-standing operational, deployment, and reporting issues related to email authentication protocols. DMARC standardizes how email recipients perform email authentication using SPF and DKIM. This gives the sender the ability to have control of mail that does not pass authentication and tell the email recipients what to do with non authenticated mail.

DMARC checks both SPF and DKIM and requires one to pass in order to send and deliver email. When you start using DMARC, it is a best practice to put a p=none policy in place and ensure that every legitimate sending application is aligned and authenticated correctly before considering a more aggressive policy. During any transition period where a new email-related service for the sending domain is evaluated, using a DMARC p=none policy and following this advice is recommended.

A DMARC record is a DNS TXT record in the domain _dmarc.<sending-domain> with content similar to the following:
"v=DMARC1\;p=none\;rua=mailto:dmarc_rua@example.com\;ruf=mailto:dmarc_ruf@example.com\;fo=1"

You must have an administrative INBOX service to receive DMARC reports (in the preceding example, example.com is your INBOX provider). Currently Email Delivery does not offer INBOX service or automated DMARC report processing. If you don't want to manage and process DMARC reports, do not create a DMARC record.

Create a Custom Return Path

Note

Setting up DKIM is more likely to improve your deliverability than a custom return path. As a result, it is recommended you set up DKIM before or at the same time you set up a custom return path.

Email Delivery is required to process bounces to protect the reputation of our IP addresses and domain. Therefore, by default the Return Path is set to be that of our Bounce servers. Email Delivery offers a custom return path feature to improve inbox placement. To use this feature, you need to set up DNS records for your custom return path domain. The custom return path domain must either match the domain of your approved sender or be a subdomain of that domain. Our suggested naming convention for a custom return path subdomain is <REGIONKEY>.rp.<sending-domain>. To prepare for use of this feature, provision SPF and MX records on the custom domain as follows:

MX Record for Custom Domain

The following record syntax applies to commercial regions only:

10 bmta.email.<REGION IDENTIFIER>.oci.oraclecloud.com

Custom return path is regional. Adding REGION IDENTIFIER to the entry is imperative to avoid confusion. For more information about regions, see Regions and Availability Domains.

SPF Record for Custom Return Path Domain

Sending Region SPF Record
Americas v=spf1 include:rp.oracleemaildelivery.com ~all
Asia/Pacific v=spf1 include:ap.rp.oracleemaildelivery.com ~all
Europe v=spf1 include:eu.rp.oracleemaildelivery.com ~all
All Commercial Regions v=spf1 include:rp.oracleemaildelivery.com include:ap.rp.oracleemaildelivery.com include:eu.rp.oracleemaildelivery.com ~all
Government Regions

Note

You must complete the DNS updates on your domain before the setup can be completed by Oracle Cloud Infrastructure.

After DNS changes are complete, create a service request to request the setup by Oracle Cloud Infrastructure. See Open a support service request for more information.

The following information is needed to complete this configuration after you have made your DNS changes:

  • Tenant OCID
  • SMTP endpoint used to submit mail
  • Approved sender email address and OCID
  • Custom return path domain