Oracle Cloud Infrastructure Email Delivery is an email sending service that provides a fast and reliable managed solution for sending high-volume emails that need to reach your recipients' inbox. Email Delivery provides the tools necessary to send application-generated email for mission-critical communications such as receipts, fraud detection alerts, multi-factor identity verification, and password resets.
Oracle Cloud Infrastructure's Email Deliverability team manages the platform using key deliverability metrics to ensure the best sending reputation possible for your emails.
The following items are provided to you when you send email using the Email Delivery service:
- Unique mailbox provider SMTP configurations on our Mail Transfer Agents (MTA)
- Bounce collection
- User complaint collection
- Email authentication standards
- Deliverability performance
Email Delivery Service Components
Email Delivery uses the components described in this section.
- approved senders
- An Approved Sender is a resource that equates to the "From" address. An approved sender is associated with a compartment and only exists in the region where the approved sender was configured. If you need to have the same approved sender in another region, it must be created in the other region. For example, if you create an approved sender in the US West (Phoenix) region, you cannot send email through the US East (Ashburn) region.
- suppression list
- The Suppression List is included on your Email Delivery console user interface and from the API. 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.
- Reasons for suppression currently include:
- Hard bounces
- Repetitive soft bounces
- Manual entries
- List-unsubscribe requests
- spf authentication
Sender Policy Framework (SPF) is used by email receivers to detect email spoofing. Using SPF, an email receiver can check if the Internet Protocol (IP) is explicitly authorized to send for that domain. SPF is implemented by publishing a special TXT record to a domain's DNS records. The TXT record declares which hosts are allowed to send mail on behalf of this domain. Receiving mail servers check the SPF records of sending domains to verify that the email's source IP address is authorized to send from that domain. Without SPF, a spam or phishing email can be “spoofed” to appear that the email comes from a legitimate domain. Domains that implement SPF are much more likely to block emails attempting to spoof your domain. For an overview of how SPF works, see Sender Policy Framework. For details on SPF record syntax, see SPF Record Syntax.
Email Delivery is available in the following regions:
- South Korea North (Chuncheon)
- India South (Hyderabad)
- Australia Southeast (Melbourne)
- India West (Mumbai)
- Japan Central (Osaka)
- South Korea Central (Seoul)
- Australia East (Sydney)
- Japan East (Tokyo)
- Canada Southeast (Montreal)
- Canada Southeast (Toronto)
- Netherlands Northwest (Amsterdam)
- Germany Central (Frankfurt)
- Switzerland North (Zurich)
- Saudi Arabia West (Jeddah)
- Brazil East (Sao Paulo)
- UK South (London)
- US East (Ashburn)
- US West (Phoenix)
For more information, see Regions and Availability Domains.
The sending application is not required to be located in the region where email is sent. For example, if your sending application is located in a region where Email Delivery is not currently available, you would configure email from one of the regions where it is available. In the Console, change your region to an available region and create an approved sender. When creating SMTP credentials, any region can be used, as identities are global assets. Configure your application to send email to the region where you created the approved sender using the SMTP credentials.
When Email Delivery is available in more regions, you can configure Email Delivery in the same region as the sending application to improve performance.
Configuring a New Region
If you want to start sending email from a new region, keep the following in mind:
- An approved sender must be created in the new region.
- SMTP credentials are global, however, it is recommended that you generate SMTP credentials for a new user (without console access) in the new region so that the credentials are not shared with other regions. Ensure that the user has the correct privileges.
- Email must be sent to the new regional SMTP connection endpoint.
- The suppression list and approved senders are regional Email Delivery assets.
For example, if an email sent from the US West (Phoenix) region bounces, the recipient email address will be added to the US West (Phoenix) region suppression list. This recipient would not be added to other region suppression lists. If you are sending email from different regions, approved senders must be created in each region.
- SPF must be set up on each subdomain. For example, in your DNS setup, create a TXT record for notification.eu-frankfurt-1.oraclecloud.com and paste the following information from the dialog box into the record:
v=spf1 include:eu.rp.oracleemaildelivery.com ~all
Ways to Access Oracle Cloud Infrastructure
You can access Oracle Cloud Infrastructure using the Console (a browser-based interface) or the REST API. Instructions for the Console and API are included in topics throughout this guide. For a list of available SDKs, see SDKs and Other Tools.
To access the Console, you must use a supported browser. You can use the Console link at the top of this page to go to the sign-in page. You are prompted to enter your cloud tenant, your user name, and your password. For general information about using the API, see About the API.
Authentication and Authorization
Each service in Oracle Cloud Infrastructure integrates with IAM for authentication and authorization, for all interfaces (the Console, SDK or CLI, and REST API).
An administrator in your organization needs to set up groups , compartments , and policies that control which users can access which services, which resources, and the type of access. For example, the policies control who can create new users, create and manage the cloud network, launch instances, create buckets, download objects, etc. For more information, see Getting Started with Policies. For specific details about writing policies for each of the different services, see Policy Reference.
If you’re a regular user (not an administrator) who needs to use the Oracle Cloud Infrastructure resources that your company owns, contact your administrator to set up a user ID for you. The administrator can confirm which compartment or compartments you should be using.
Email Delivery supports the following authentication types for control plane operations (management endpoint):
- Instance Authorization: The IAM service feature that enables instances to be authorized actors (or principals) to perform actions on service resources. Each compute instance has its own identity, and it authenticates using the certificates that are added to it. These certificates are automatically created, assigned to instances and rotated, preventing the need for you to distribute credentials to your hosts and rotate them.
- Cross-Tenancy: Cross-tenancy authorization allows customers to share resources between tenancies. To authorize a cross-tenancy request, the request must be endorsed by the requester's tenancy and permitted by the target tenancy.
Federated: Federated authentication enables an administrator to configure a relationship between an identity provider and a service provider. When you federate Oracle Cloud Infrastructure with an identity provider, you manage users and groups in the identity provider. You manage authorization in Oracle Cloud Infrastructure's IAM service. Oracle Cloud Infrastructure tenancies are federated with Oracle Identity Cloud Service by default.Note
Instance authorization, cross-tenancy, and federated authentication types do not apply to SMTP email sending. An approved sender and SMTP credentials are required and must be associated with the same tenancy for SMTP email sending.
SMTP Authentication and Connection Endpoints
Email Delivery only supports the AUTH PLAIN command when using SMTP authentication. If the sending application is not flexible with the AUTH command, an SMTP proxy/relay can be used. For more information about the AUTH command, see AUTH Command and its Mechanisms.
Use the following regional endpoints for establishing SMTP connections for sending.
- South Korea North (Chuncheon):smtp.email.ap-chuncheon-1.oci.oraclecloud.com
- India South (Hyderabad): smtp.email.ap-hyderabad-1.oci.oraclecloud.com
- Australia Southeast (Melbourne): smtp.email.ap-melbourne-1.oci.oraclecloud.com
- India West (Mumbai): smtp.email.ap-mumbai-1.oci.oraclecloud.com
- Japan Central (Osaka): smtp.email.ap-osaka-1.oci.oraclecloud.com
- South Korea Central (Seoul): smtp.email.ap-seoul-1.oci.oraclecloud.com
- Australia East (Sydney): smtp.email.ap-sydney-1.oci.oraclecloud.com
- Japan East (Tokyo): smtp.email.ap-tokyo-1.oci.oraclecloud.com
- Canada Southeast (Montreal): smtp.email.ca-montreal-1.oci.oraclecloud.com
- Canada Southeast (Toronto): smtp.email.ca-toronto-1.oci.oraclecloud.com
- Netherlands Northwest (Amsterdam): smtp.email.eu-amsterdam-1.oci.oraclecloud.com
- Germany Central (Frankfurt): smtp.email.eu-frankfurt-1.oci.oraclecloud.com
- Switzerland North (Zurich): smtp.email.eu-zurich-1.oci.oraclecloud.com
- Saudi Arabia West (Jeddah): smtp.email.me-jeddah-1.oci.oraclecloud.com
- Brazil East (Sao Paulo): smtp.email.sa-saopaulo-1.oci.oraclecloud.com
- UK South (London): smtp.email.uk-london-1.oci.oraclecloud.com
- US East (Ashburn): smtp.us-ashburn-1.oraclecloud.com
- US West (Phoenix): smtp.us-phoenix-1.oraclecloud.com
You can monitor the health, capacity, and performance of your Oracle Cloud Infrastructure resources by using metrics, alarms, and notifications. For more information, see Monitoring Overview and Notifications Overview.
For information about available Email Delivery service metrics and how to view them, see Email Delivery Metrics.
See Service Limits for a list of applicable limits and instructions for requesting a limit increase. To set compartment-specific limits on a resource or resource family, administrators can use compartment quotas.
Customers that sign up for a free Oracle Cloud trial are limited to:
- A volume of 200 emails a day.
- 2,000 approved senders.
- Each user is limited to a maximum of two SMTP credentials.
- Sending rates are limited to ten emails per minute.
- Inline attachments.
Customers that start with a Free Trial and transition to a paid account must request a limit increase.
Enterprise accounts are limited to:
- A volume of 50,000 emails a day.
- 10,000 approved senders.
- Sending rates are limited to 18,000 emails per minute.
- Inline attachments.
Dedicated IP Availability
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.
The Email Delivery platform supports higher volumes. Limits are set as a safeguard for our customers' reputation. To file a service request to increase the email sending limit, open the navigation menu. Under Governance and Administration, go to Service Limits. Click Request a service limit increase.
Currently, Email Delivery supports messages up to 2 MB, inclusive of message headers, body, and attachments. This is not a limit set per tenant. Larger message sizes will be available in the future.
Required IAM Service Policy
To use Oracle Cloud Infrastructure, you must be given the required type of access in a policy written by an administrator, whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you try to perform an action and get a message that you don’t have permission or are unauthorized, confirm with your administrator the type of access you've been granted and which compartment you should work in.
Permissions are required for managing and using approved senders and the suppression list. For example:
- To enable all operations on approved senders for a specific user group:
Allow group <Your Group Name> to manage approved-senders in tenancy
- To enable all operations on suppressions for a specific user group:
Allow group <Your Group Name> to manage suppressions in tenancy
You can apply tags to your resources to help you organize them according to your business needs. You can apply tags at the time you create a resource, or you can update the resource later with the desired tags. For general information about applying tags, see Resource Tags.
Email Delivery supports applying tags to approved senders.
Integration with Oracle Cloud Infrastructure Services
Email Delivery audits the following events:
- Creating a sender (CreateSender)
- Deleting a sender (DeleteSender)
- Retrieving details about a sender (ListSenders)
To view logs for events in the Email Delivery service, your user must be in a group with the ability to view all of the Audit event logs in the tenancy. For more information, see Viewing Audit Log Events.
Getting Started with Email Delivery
You can set up the Email Delivery service within the Console. To begin sending email with Email Delivery, complete the following steps:
- Generate SMTP credentials for a user.
- Set up permissions.
- Create an approved sender.
- Configure SPF on the approved sender domain.
- Configure the SMTP connection.
- Begin sending email.
For more information, see Getting Started with Email Delivery.