Overview of Email Delivery

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 can't send email through the US East (Ashburn) region.

SUPPRESSION LIST

The Suppression List is included on 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 sender reputation. Email Delivery doesn't send any messages to these recipients in the future.

Reasons for suppression include:

• Complaints
• Hard 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.

SMTP credentials can be used for any region, as identities are global assets. However, approved senders (your "From" address) must be configured within each region you plan to use for Email Delivery. To configure approved senders within each region, select a region from the Region menu in the Console and create an approved sender. Configure your application to send email to the endpoint of that region where you created the approved sender, using the global SMTP credentials. The sending application is not required to be located in the region where email is sent from, however, we recommend that it is local or as close as possible for performance reasons.

For more information, see Regions and Availability Domains.

Email Delivery supports all OCI native authentication mechanisms, see OCI SDK Authentication Methods.

Email Delivery supports all OCI native authentication mechanisms when using HTTPS email submissions. For more information, see OCI SDK Authentication Methods. It also supports the AUTH PLAIN command when using SMTP authentication. If the sending application isn't 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.

To know the regional endpoints, ports, or security details for establishing HTTPS or SMTP connections, see HTTPS sending information and SMTP sending information on the Console. For more information, see, Configuring HTTPS Connection and Configuring SMTP Connection.

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 and Notifications.

For information about available Email Delivery service metrics and how to view them, see Email Delivery Metrics.

For a list of applicable limits and instructions for requesting a limit increase, see Service Limits. 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 per day where an email is defined as either a single recipient in the TO:, CC:, or BCC: fields, or a 2 MB chunk of data.

  Email examples:

  • A single request with 10 recipients (TO:, CC:, or BCC:) equals 10 emails.

  • A 10 MB email sent to a single recipient is equal to 10 MB divided by 2 MB per email. This equals 5 emails.

  • A single email request with a message size of 10 MB sent to 10 recipients is equal to 10 MB divided by 2 MB per email multiplied by 10 recipients. This equals 50 emails.

• 2,000 approved senders.
• Each user is limited to a maximum of two SMTP credentials.
• Sending rates are limited to 10 emails per minute.
• Inline attachments and external attachments.
• 2 MB maximum message size including base64 encoding and headers

Enterprise accounts are limited to:

• A volume of 50,000 emails per day where an email is defined as either a single recipient in the TO:, CC:, or BCC: fields or a 2 MB chunk of data.

  Email examples:

  • A single request with 10 recipients (TO:, CC:, or BCC:) equals 10 emails.
  • A 10 MB email sent to a single recipient is equal to 10 MB divided by 2 MB per email. This equals 5 emails.
  • A single email request with a message size of 10 MB sent to 10 recipients is equal to 10 MB divided by 2 MB per email multiplied by 10 recipients. This equals 50 emails.
  This limit applies to unique recipients among all emails sent. For example, a single email sent to 100 recipients would count the same as 100 individual emails each sent to a single recipient.
• 10,000 approved senders.
• Sending rates are limited to 18,000 emails per minute.
• Inline attachments and external attachments.
• 2 MB maximum message size including base64 encoding and headers

Email Delivery, by default, supports messages up to 2 MB, inclusive of message headers, body, and attachments. Each 2 MB of data counts toward your daily sending volume and sending rate limits. For example, a 10 MB counts as five emails.

For any email limit increase, SPF and DKIM are required for your sending domain and approved sender. See Configuring SPF and Configuring DKIM.

Based on your requirement, you can request for limit increase up to a maximum of 60 MB for message size .

To open a service request to increase the limit, see Requesting a Service Limit Increase. Your increase request is evaluated by the following information you provide:

• What are your current sending domains?
• Do your sending practices meet the requirements of CAN-SPAM and CASL?
• Briefly describe the type of email you' will be sending. For example, are the emails marketing, bulk, newsletters, transactional, notifications, and so on?
• Do you send emails related to payday loans or credit card offers?
• Do you send emails on behalf of other companies?
• How do the recipients sign up to receive these emails? Specify any domains they might sign up on.
• Are there any other methods that are used to collect email addresses?
• How many emails do you want to send per month?
• Which ESP supplier are you using to send your emails?
• What is the maximum number of messages you need to send in a burst capacity (within a specific timeframe)?
• What is the maximum size of your messages?
• What is the number of emails sent per day that is over 2 MB?
• Are your recipients Oracle email addresses (for example, test.user@oracle.com)?
• Which email delivery region do you intend to use to send email through?

If you're new to policies, see Getting Started with Policies and Common Policies. For more details about policies for Email Delivery, see Details For the Email Delivery Service.

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

When you create an Email Delivery service account, by default, your emails are sent from IP addresses shared with other Oracle customers.

Email Delivery supports IPs addresses dedicated to you, for complete control over your reputation. Both a shared IP or dedicated IP strategy can provide excellent delivery depending on your needs and mail stream characteristics. For more information about shared IP, see Shared IP or Dedicated IP.

When using a dedicated pool of Oracle owned IP addresses, only your mail is sent from them.

Dedicated IP addresses are ideal for senders who:

• Send large volumes of mail on a consistent basis to sustain their own IP reputation. Sending a large volume of mail consistently is what Internet Service Providers (ISPs) automated filters use to assign a reputation to your IP address. This is one of the key inputs into whether your messages are delivered into the inbox, spam folder, or temporarily rejected.
• Want complete control of their sending reputation AND understand email delivery best practices. When you are the only sender on an IP, it insulates your reputation from other senders. This can be good or bad depending on your sending practices and consistent hygiene.
• Have large volumes, different mail streams, and want to build unique reputations for each. Dedicated IPs enable you to build separate IP reputations based on different types of mail streams like transactional messages versus bulk marketing mail. If you have the volume to support it, isolating these mail streams can reduce the risk of delivery challenges for more critical message types.

Dedicated IP addresses are likely not a good fit for senders who:

• Send mail inconsistently at low volumes preventing an ISP reputation from being assigned. To build an IP reputation, ISPs prefer a predictable mail cadence with enough email volume to assign a reputation. Failing to meet this requirement could lead to delivery challenges. Sending in a shared IP pool with many smaller senders will provide the ISP with a large volume of consistent mail.
• Do not understand email best practices, which could lead to poor-reputation delivery challenges. Sending in a shared IP pool with other customers that is managed by Oracle can be less risky for an email novice.

Your mail characteristics (volume, burst rates, reputation, and so on) will vary your dedicated IP strategy. Our teams are trained on dedicated IP strategies and ready to support your needs. If you need help with your configuration, you can go to My Oracle Support and create a service request.

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 tags. For general information about applying tags, see Resource Tags.

Email Delivery supports applying tags to approved senders.

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.