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.
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.
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.
Yes, Email Delivery service is a similar service to Amazon SES or SendGrid.
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. Please see the Oracle Cloud Infrastructure DNS FAQ for how to set this up.
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.
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.
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.
Yes, bulk email can be programmatically sent with Oracle Email Delivery.
Note - Reporting is not available at GA.
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.
As referenced within the service description, the following obligation applies to the type of email sent with Email Delivery:
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
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.
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.
Yes, Email Delivery is contained within the Oracle Cloud Infrastructure SDKs.
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:
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.
Yes, bounced emails are collected and categorized appropriately per their corresponding bounce codes.
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.
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.
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.
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.
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.
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/
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.
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.
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:
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.
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.
Soft bounces are a usually a good indication of message content quality and relevance.
Typically, soft bounces occur for:
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:
Here is how you can improve your complaint rate:
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.
Reputation Management is an add-on service through sales and requires the purchase of a Universal Cloud subscription.
Email Delivery costs $0.10 per 1,000 email sent through the service. Emails sent is defined as the number of unique outbound deliveries during a calendar month. Outbound deliveries are defined by the number of unique messages as well as the number of unique recipients per message.