Creating an Email Domain
Learn how to create a DNS email domain to send bulk emails from approved senders.
Using the Console
To send email from many addresses with the same domain:
- Configure DKIM for the domain providing authorization to send from the domain.
- When DKIM is active, create the approved sender @domain.com.
If DKIM isn't active, you can't create the approved sender.
Create a Custom Return Path
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 |
|
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.
_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.