Email Delivery FAQ

General questions

What is Email Delivery?

Oracle Cloud Infrastructure Email Delivery is an email-sending service that provides fast and reliable managed service for sending high-volume emails that need to reach your users’ inbox. Email Delivery provides customers the tools necessary to quickly and reliably send application-generated email for mission-critical communications such as receipts, fraud detection alerts, multifactor identity verification, and password resets. Email Delivery is a highly scalable, cost-effective, and reliable infrastructure service, and it eliminates the complexity and expense of building an in-house email delivery solution.

Who should use Email Delivery?

  • Any cloud-based application that includes email should leverage Email Delivery.
  • Any business that wants to send messages that will reach their user’s inbox in a cost-effective way should use Email Delivery.

Why do I need Email Delivery?

  • It's essential to ensure your business's email reaches your users inbox, as email is the most direct means for businesses to communicate with their customers. As the number and frequency of automated outbound email grows, it becomes increasingly more difficult to ensure messages reach their customer’s inbox due to many spam filtering systems.
  • Email Delivery is a developer-friendly service that solves configuration, infrastructure, security, and authentication issues for email delivery.

What kind of email can I send with Email Delivery?

Email Delivery is ideal for transactional, application-generated email such as receipts, fraud detection alerts, multifactor identity verification, and password resets, but any email compliant with industry regulations and laws can be sent.

Is Email Delivery a front-end provider like Eloqua and Responsys?

Email Delivery is a back-end infrastructure that can be integrated with front-end providers like Eloqua or Responsys. Email Delivery doesn't offer users the ability to develop HTML campaigns or manage recipient lists.

Is Email Delivery the same as Amazon SES or SendGrid?

Yes, Email Delivery service is a similar service to Amazon SES or SendGrid.

How do I begin sending email with Email Delivery?

Follow the steps below in the API or Oracle Cloud Infrastructure Console to begin sending email.

Detailed instructions on how to configure and use Email Delivery will be available here

1. From the Oracle Cloud Infrastructure Console locate the user under which you'll create SMTP credentials. Ensure that user is in a group that has a policy to manage approved-senders, for example, allow group MyGroup to use approved-senders in compartment MyCompartment).

2. In the settings for the new user, choose SMTP credentials on the left, then generate SMTP Credentials.

3. Choose Email in the Oracle Cloud Infrastructure Console. Ensure that you have the correct compartment chosen. Your user must be in a group with permission to manage approved senders in this compartment.

4. Create one or more approved senders within a specified compartment. These are the email addresses that will appear in the ‘From’ line of the email. Note approved senders are specific to the region. If you create an approved sender in Phoenix, you cannot send mail through Ashburn.

5. Follow the instructions to configure your DNS for sender policy framework (SPF) by adding a TXT record under the corresponding domain.

6. Setup and test your SMTP connection from your system through Email Delivery. Postfix and SendMail are two popular SMTP products, but any SMTP library can be used.

What region(s) support Email Delivery?

Email Delivery is available in all OCI regions and realms. See Regions and Availability Domains for a complete list.

Note: The application that is sending mail does NOT have to be in the region where mail is sent from but it is ideal for performance reasons to configure Email in the same region as the sending Application.

Why am I receiving an error when trying to add an approved sender?

  • Ensure you have permissions to manage approved senders in the compartment you have chosen. (Policy Basics)
  • You may have reached your approved sender limit. You can use My Oracle Support to file a service request to increase the email sending limit as needed.
  • Your account may be suspended which would reduce your approved sender limit to 0.

Sending emails

What is an approved sender?

An approved sender is a resource that enables Email Delivery to send email with a matching from address. Approved senders are associated with a compartment and only exist in the region in which they were configured.

Can I send bulk email with Email Delivery?

Yes, bulk email can be programmatically sent with Oracle Email Delivery.

Note - Reporting is not available at GA.

Does SMTP require TLS?

  • Oracle prides itself on strict security policies and Email Delivery abides by those policies. As such, we only accept Email from customers over TLS.
  • TLS (TLS is mandatory)
  • Only TLS version 1.2 is supported since earlier versions are less secure.
  • Java applications must be updated to the latest version to ensure the updated security protocols, ciphers, and patches to be compliant with Oracle's security policies.
  • The approved ciphers are:
    • TLSv1.2:
    • TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,
    • TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
    • TLS_RSA_WITH_AES_256_CBC_SHA,
    • TLS_RSA_WITH_AES_256_CBC_SHA256,
    • TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
    • TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
    • TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
    • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
    • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
    • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
    • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
    • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

What SMTP Auth command is supported?

  • Only SMTP Plain is supported
  • Note - If the sending application is not flexible on the Auth Command, an smtp proxy/relay can be used

Can my application send email to Email Delivery without public internet access?

  • Yes, the application would need to send to a service that does have Internet access, such as a proxy or relay service.
  • In the future, Email Delivery will be able to accept email from within Oracle Cloud Infrastructure using the Service Gateway service, without having to traverse the public internet)

What are the limits associated with Email Delivery?

The Email Delivery platform is managed by Oracle Cloud Infrastructure's Email Deliverability team. Limits are put on accounts to safeguard the service and our customers' reputations. The following limits can be increased to meet large scale sending requirements by opening a service request from My Oracle Support.

  • Customers that sign up on oracle.com for a free trial are limited to 200 emails in a rolling 24 hour period and sending rates must not exceed 10 emails per minute. Approved senders are limited to 2,000. Maximum messages size including base64 encoding and headers is 2MB.
  • Enterprise accounts are limited to 50,000 emails in a rolling 24-hour period and sending rates must not exceed 18,000 emails per minute. Approved senders will be limited to 10,000 for enterprise customers. Maximum messages size including base64 encoding and headers is 2MB.
  • Email Delivery supports high volume, but the limit is set as a safeguard for our customers' reputations.
  • Contact My Oracle Support who can work with you to understand your use case and increase the sending limit as needed.

Are there limitations to the type of email I can send with Email Delivery?

As referenced within the service description, the following obligation applies to the type of email sent with Email Delivery:

  • You shall not use the services for purposes of distributing "spam" emails, bulk unsolicited instant messages, or any other form of unsolicited electronic communications distributed on a bulk basis to recipients with which You have no preexisting business or personal relationship.

What size email can be sent?

The default maximum Message size up to 2MB in size, inclusive of message headers, body, base64 encoding, and attachments, are supported initially.

If the size limit is increased, each 2MB of data will be counted as an "email" toward your daily sending volume and rate limits.

Email examples

  • A 10MB email sent to a single recipient equals 10MB/2MB per email = 5 emails.
  • A single email request with a message size of 10MB and 10 recipients equals 10MB /2MB per email * 10 recipients = 50 emails

Can I send emails with attachments?

Email Delivery supports sending multipurpose internet mail extensions (MIME) messages via SMTP. MIME is the RFC standard that specifies in part how attachments work. For more information, see here.

What methods of sending are available?

SMTP is currently the only method to send email through Email Delivery. There is a unique SMTP endpoint in each Oracle Cloud Infrastructure region where Email Delivery is available.

Are there any SDK’s provided for Email Delivery?

Yes, Email Delivery is contained within the Oracle Cloud Infrastructure SDKs.

Deliverability

How does Email Delivery ensure reliable delivery?

Email Delivery provides a reliable service via a system that is compliant with industry best practices. The platform is managed by Oracle Cloud Infrastructure's Email Deliverability team, which reviews key deliverability metrics to ensure the best sending reputation possible. The following items are taken care of for you when you send email with Email Delivery:

  • Mailbox Provider Unique SMTP configurations
  • Bounce collection
  • User complaint collection
  • Email authentication standards (like SPF)
  • IP Pool management

How does Email Delivery customize SMTP configurations?

Email Delivery is configured with mailbox provider specific rate limiting, back-off modes, and SMTP configurations. These configurations have been set through industry relations and years of tuning across global mailbox providers to optimize inbox placement and speed of delivery.

Does Email Delivery collect any bounced emails?

Yes, bounced emails are collected and categorized appropriately per their corresponding bounce codes.

What should I do if an email bounces?

Any recipient address deemed to be permanently undeliverable, such as hard bounces, are put on the customer’s suppression list. Repeated attempts to send to addresses on the suppression list will not be delivered by Email Delivery, and such occurrences are recorded in the blocked report. A high hard-bounce rate (ratio of hard bounces to messages sent) occurs when a sender attempts to send a message to a recipient address that does not exist. The mailbox provider will return a hard bounce code to the sender. Hard bounces are a good indication of list quality and should be below 2 percent.

Does Email Delivery collect user complaints?

Yes, users complaints are collected and processed via mailbox provider complaint feedback loops. The setup of these complaint feedback loops is fully automated with Email Delivery.

When user spam complaints are collected the user is added to the suppression list to protect the customer sending reputation. It is suggested that you also remove the user from your mailing list at that time but no other action is required to ensure quality email deliverability.

What is the suppression list?

The suppression list is included on your Email Delivery console user interface as well as within the API, SDK and CLI.

Email Delivery automatically adds email addresses with bounce codes showing permanent failures or user complaints to the suppression list to protect your sender reputation. Email Delivery will not send any messages to these recipients in the future. Repeated attempts to send to suppressed email addresses will appear on your blocked report.

Reasons for suppression currently include: spam complaints, hard bounces, repetitive soft bounces, manual entries, and list-unsubscribe requests.

What is Sender Policy Framework (SPF) and how do I use it?

SPF prevents email address spoofing and minimizes inbound spam. Through SPF, a domain may explicitly authorize the hosts that are allowed to use its domain name. SPF works by publishing SPF (code 99) or TXT (code 16) records, which are DNS resource records that declare which hosts are allowed to use a domain name. The receiving mail server checks the SPF records from the domain identified as sending the email to verify that the source IP which the email originated from is authorized to send email from that domain.

Mailbox providers and ISPs check SPF to ensure the sender (Email Delivery) is authorized to send email on behalf of your domain. SPF is an essential foundation at providing good deliverability for your domain and protecting you from abuse like spam or phishing attacks.

To set up SPF, you must include a TXT record on the domain used by your approved sender. If Email Delivery is the only sender authorized for this domain, it would look like the following:

Sending Location SPF
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

"v" indicates the version of SPF used. The other mechanisms test the legitimacy of the email. "MX" and "A" are resource records that are compared between the email and the SPF record to decide whether or not to accept the email. "all" always matches and serves as a default action. The mechanisms are combined with qualifiers to determine how to handle a match. The simplest are + (which is implied if omitted) and -, resulting in a pass or a fail, respectively. How these results are handled is left to the receiving domain’s administrators to handle. Typically "fails" are rejected and soft fails are marked as potentially spam.

Using SPF can increase client confidence and trust. A domain which implements SPF is much less likely to be spoofed. Without SPF, a spam email can be spoofed to show a particular domain, in which case the recipient would likely report the email as spam. With enough such reports, Bayesian spam filters would be more likely to block the domain, thus blocking any potential legitimate emails. If a domain does implement SPF, however, and it is forged, the receiving server will be more likely to block the fraudulent email.

Can I send email on dedicated IPs?

Yes, Email Delivery supports dedicated IPs. By default, customer accounts are configured into tiered shared sending pools depending on your email characteristics. Dedicated IPs are suggested for larger sending volumes. Dedicated IPs may not be advised for lower or more sporadic email sending as this will not support a good sending reputation, and therefore cause impact to your email deliverability.

Each customer’s mail characteristics (volume, burst rates, reputation, etc.) will vary your dedicated IP strategy. Our teams are trained on this subject and ready to support your dedicated IP needs. Contact support to assist with this configuration.

What do I need to do to ensure my email is compliant with deliverability best practices?

Deliverability best practices are built upon providing transparent, user desired, email. Canada's Anti-Spam Law (CASL) is one of the best guides to ensuring your compliance with the law, user’s desire, and the intended filtering that most mailbox providers use. The following link provides a CASL overview and describes the industry leading practices: https://help.dyn.com/casl-faq/

Why is reputation important?

When it comes to sending, having a clean network to deliver email is more in important than ever. If you’re sharing IP addresses with spammers and other less reputable senders, the chances of your email being delivered to inboxes decrease drastically. Our ongoing vigilance in overseeing our network helps weed out the bad and bring on more of the good.

What affects reputation?

Authentication

When using a third party email delivery service, email authentication helps to verify the identity and trust between the sender (Email Delivery) and the receiving server (ISPs and corporate mail servers) by imprinting both SPF and domain keys (DKIM) into your DNS records. Receiving servers, in an attempt to prevent unwanted or forged mail from reaching the inbox, perform lookups on your domain’s DNS records to see if the third-party sender is authorized to send mail on your behalf.

Volume/Frequency

Steady volumes and frequency help develop your reputation as a good sender. Random spikes of traffic is a behavior often associated with spammers. Enough volume needs to be sent from your IP(s) before being established as a trusted sender by receiving ISPs.

Bounce Rate

Your bounce rate is a percentage of undeliverable messages (bounces) based on the total number of emails that you have sent. It is recommended that bounce rates remain below 2 percent. Higher bounce rates are often indicative of improper list management and cleansing, or that the list is old, rented, or purchased. Email Delivery automatically adds bounces to the suppression list to help keep your bounce rate low.

Spam Complaint Rate

Your spam complaint rate is a percentage of user-submitted complaints to their ISPs based on the total number of emails that you have sent. Spam complaints occur when the email receiver opts to click the "This is Spam" button in the email client’s UI. It is recommended that your spam complaint rates remain below 0.05 percent. Email Delivery automatically adds spam complaints to the suppression list.

Blacklists

ISPs use blacklists to block spam from senders with poor reputations. Legitimate senders can be mistakenly blacklisted. Email Delivery scans the top 10 blacklisted services in real time for our sending IP(s). Most blacklists are 24 hour blocks and you will automatically be removed from the list after this period. Some, however, require your action to remove yourself from the list.

How can I lower my hard bounce rate?

A high hard-bounce rate (ratio of hard bounces to messages sent) occurs when a sender attempts to send a message to a recipient address that does not exist. The mailbox provider will return a hard bounce code to the sender. Hard bounces are a good indication of list quality and should be below 2 percent.

Typically, hard bounces occur when a recipient address is:

  • Entered incorrectly
  • No longer in use (the user cancelled the account)
  • Acquired from a website by scraping the web
  • Manufactured by a list service provider

Mailbox providers expect hard bounces to occur; however if too many hard bounces occur, deliverability will begin to decline. Email Delivery will automatically add all hard bounced recipient addresses to your suppression list to prevent future delivery attempts and protect your sending reputation.

You can reduce a high bounce rate by doing the following:

1. Implement an opt-in process. For bulk mailing (sending to many recipients at the same time) implement an opt-in process. An opt-in process is a method for your users to subscribe (give permission for you to send messages) to your mailing list. It is critical to only send messages to the subscribers that have opted-in. There are two types of opt-in procedures.

2. Single opt-in (unconfirmed)—a single opt-in is when the user provides their email address and gives permission to receive relevant messages. Once the address is provided messages can be sent without confirming the email address belongs to the user who provided it.

3. Double opt-in (confirmed)—a double opt-in is when the user provides their email address. Before the first mailing, a confirmation email with a required user action is sent to ensure that the account owner wishes to receive future messages. An account can be verified by having the owner click a link for reply to the email. This ensures that the address was not added to a third-party mailing list without consent from the owner.

4. Purge unengaged users. Implement a process to remove unengaged users. If a recipient is not opening or clicking your mail, it may indicate that they no longer use the email account. If this is the case, eventually the mailbox provider will terminate the account or transform it into a spam trap. To avoid hitting these spam traps or hard bouncing an email to a canceled account removed recipients who have not engaged with in a time frame defined by your business model. This will also help your deliverability by increasing your user engagement rate.

5. Review subscriber list. When reviewing your subscriber list make sure to:

Eliminate duplicate addresses prior to sending. If addresses that do not exist receive email multiple times, it could inflate your hard bounce rate.

Ensure that a previous suppression list (possibly from another email service provider) was not accidentally included.

Verify subscribers have opted-in (do not send to an old list that you found).

Restrict users from uploading their email client’s contact list in a "select all" fashion. Forcing users to select addresses individually will prevent accidentally including out of date or possibly expired addresses.

6. Evaluate sending frequency. If a message does not have a chance to register as a hard bounce before the next message is sent to the recipient it will hard bounce again. Give the mailbox provider and email service provider time to process the bounce before sending another message. Decreasing sending frequency also provides the user an opportunity to unsubscribe before receiving multiple messages that they may mark as spam.

How can I lower my soft bounce rate?

A soft bounce rate (ratio of # soft bounces per # messages sent) occurs when a message is sent to a recipient and the receiving server is either temporarily unavailable or the message has been blocked by the receiver. It is a temporary nondelivered status and the mailbox provider will return a soft bounce code to the sender. These addresses will not be added to the suppression list because they exist.

  • Note: Email Delivery will add an address to the suppression list if 4 emails sent to it within a 24 hour period result in a soft bounce.
  • Soft bounces are a usually a good indication of message content quality and relevance.

    Typically, soft bounces occur for:

  • Spam like content—Message content has been identified as spam by the receiver and is being blocked temporarily.
  • Content not relevant to recipient—This can cause a high number of complaints and receivers will temporarily block messages from the sender’s IP address or domain.
  • High number of complaints—Some receivers will block all incoming messages from an IP address when a complaint threshold (number of complaints over a time period per IP) is exceeded.
  • Busy receiving mail server—If this occurs the outgoing mail server will attempt to send the message four times and then hard bounce the message.
  • Full or over quota mailbox—If the recipient’s mailbox is full or over their quota the message may soft bounce.

How can I lower my complaint rate?

Complaints can happen for many reasons and not all of them are because the user thinks your message is "spam". Let’s face it, sometimes it’s easier for people to click the spam button to reduce messages in your crowded inbox.

Here are some common reasons that people may complain about your messages:

  • It is truly spam.
  • Content is no longer relevant to what the recipient is expecting (different than what they opted-in to).
  • It is easier than finding the unsubscribe URL that is buried in the footer of the email.
  • The recipient trusts the ISP user interface over your unsubscribe URL.
  • The recipient is tired of receiving your messages.

Here is how you can improve your complaint rate:

  • Don’t send spam
  • Keep content relevant—If the recipient signed up on your site for daily coupons for groceries, don’t start sending auto loan rates.
  • Easily accessible unsubscribe url—Unsubscribing is a good thing. It will shrink your list which feels bad, but it actually helps your inbox success sending only to recipients that engage by opening or clicking your messages. When people complain, it harms your sending reputation, so make it easy for them to be removed from the list. The worst thing you can do is hide the unsubscribe url at the bottom of the message. A small percentage of users will scroll to the bottom of the email and search for a small url. Most will take the easy way out and just mark as spam.
  • Implement list-unsubscribe header—If supported by the mailbox provider, this feature will allow users to safely unsubscribe from your list through the trusted ISP user interface rather than mark as spam. This is the closest thing Gmail has to a feedback loop.
  • Implement a double opt-in process—Mailing current users and confirming that they wish to receive your messages is a great way to ensure they still value your message. This is a great way to remove recipients prior to marking as spam.
  • Review frequency of mailing—Sending too many messages in a short period of time may aggravate recipients, causing them to mark your message as spam. Ensure that your message cadence aligns with the expected frequency of your content. Reducing frequency may reduce spam complaints.
  • Purge unengaged recipients—Recipients may be tired of your mail if they are not opening your messages or clicking your links. You should purge recipients if your final attempt to engage with them is unsuccessful. Here are some tips to help understand list management best practices in this area.

My email wasn't delivered. How do I troubleshoot?

  • Check if the recipient is on the suppression list.
  • Ensure that you have SPF set up to increase your inbox placement.
  • Check your application's logs to ensure that there wasn't an issue (for example, an authentication failure or an issue with the format of the email message).
  • If you provide two different addresses for envelope from and body from, they must both be approved senders or the mail will be rejected.
  • If the SMTP FROM is not the same as the from in the email body they both need to be an approved sender.
  • Still can't find the issue? Open a Customer Support Ticket

Does Oracle Email Delivery support Dedicated IPs?

Yes, Email Delivery supports dedicated IPs which allow you to have control over your reputation. Dedicated IPs are Oracle Cloud IP addresses that are reserved for your email sending. By default, customer accounts are configured into tiered shared sending pools depending on your email characteristics. Dedicated IPs are suggested for larger sending volumes. Dedicated IPs may not be advised for lower or more sporadic email sending as this will not support a good sending reputation, and therefore cause impact to your email deliverability.

Each customer’s mail characteristics (volume, burst rates, reputation, etc.) will vary your dedicated IP strategy. Our teams are trained on this subject and ready to support your dedicated IP needs. Contact support to assist with this configuration.

Commercial

What are the offerings provided by Email Delivery?

Reputation Management is an add-on service through sales and requires the purchase of a Universal Cloud subscription.

What does Email Delivery cost?

Email Delivery costs $0.085 per 1,000 emails submitted for delivery through the service. An "email" is defined as a 2MB or less email chunk of raw email data, as well as a single recipient of an email. This is defined more specifically in the service documentation, with examples.