Oracle Cloud Infrastructure Documentation

Creating an Email Domain

Learn how to create a DNS email domain to send bulk emails from approved senders.

Using the Console

  1. Open the navigation menu and click Developer Services. Under Application Integration, click Email Delivery. Under Email Delivery, click Email Domains.
  2. Click Create Email Domain.
  3. Enter your email domain name. This should be a domain you own or control in DNS, because measures used to establish verification and authentication require a DNS record update or similar actions. It requires to be the domain you plan to use for approved senders, and can't be a public mailbox provider domain such as gmail.com, hotmail.com, yahoo.com, or oracle.com.

    Tags : If you have permissions to create a resource, then you also have permissions to apply free-form tags to that resource. To apply a defined tag, you must have permissions to use the tag namespace. For more information about tagging, see Resource Tags. If you're not sure whether to apply tags, skip this option or ask an administrator. You can apply tags later.

  4. Click Create.
Tip

To send email from many addresses with the same domain:
  1. Configure DKIM for the domain providing authorization to send from the domain.
  2. When DKIM is active, create the approved sender @domain.com.
Warning

If DKIM isn't active, you can't create the approved sender.

Create a Custom Return Path

Note

Setting up DKIM is more likely to improve your deliverability than a custom return path. As a result, we recommend 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

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 doesn't pass authentication and tell the email recipients what to do with non authenticated mail.

To send and deliver email, DMARC checks both SPF and DKIM and requires at least one to pass. When you start using DMARC, it's 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). Email Delivery doesn't offer INBOX service or automated DMARC report processing. If you don't want to manage and process DMARC reports, don't create a DMARC record.