Oracle Email Delivery SPF, DKIM and DMARC setup, step by step

For Oracle Cloud Infrastructure Email Delivery, configure the email domain and approved senders in the application's sending region, publish the DKIM record generated by OCI, and reconcile SPF with the correct regional authorization. If you need SPF alignment with your own domain, configure a custom Return-Path rather than assuming a root-domain SPF include changes Oracle's bounce identity. Finish by checking a newly delivered message. Oracle DKIM setup, custom Return-Path

This guide covers OCI Email Delivery, not every Oracle-branded sender. Oracle explicitly excludes OCI Classic services such as Fusion Apps, classic IDCS and Cloud Notification Services from this DKIM procedure. Oracle Integration Cloud Generation 2 and Oracle Transportation and Global Trade Management also have service-specific procedures. Do not reuse their selectors or support-ticket instructions for this route.

If your domain also sends employee mail through Microsoft 365, retain that separate configuration; see the Microsoft 365 SPF and DKIM guide.

Map the sending region before touching DNS

Record the application's OCI submission region, tenancy, compartment, email domain and visible From addresses. Identify whether it uses OCI SMTP or an OCI Email Delivery API path, and confirm the actual endpoint with the application owner. A hostname copied from another region is not interchangeable merely because both endpoints belong to Oracle.

You need access to manage the relevant Email Delivery resources, administrative control of the sender domain's authoritative public DNS, and a controlled external mailbox for later testing. Confirm compartment-scoped access with the tenancy administrator rather than granting broad access just to bypass an error. Keep SMTP passwords and API credentials out of DNS records, change tickets and screenshots.

Export the existing SPF, DKIM and DMARC records and note their TTLs. Record the owners of any existing aliases that might collide with a new selector or Return-Path. Design the change so other legitimate senders retain their authorizations and keys.

1. Create or select the email domain and approved senders

In the OCI Console, open Developer Services → Application Integration → Email Delivery → Email Domains. Create or select the domain you own and intend to use for sending. Do not use public mailbox-provider domains or a private-only name that receivers cannot resolve. Creating an email domain

Approved senders are associated with a compartment and exist only in the region where they were configured. A sender approved in one region is not automatically approved at another region's endpoint. Every From address must be covered by approved-sender authorization. Prefer matching envelope and header From addresses at submission; if they differ, Oracle says both require authorization. Managing approved senders

For domain-wide sending, Oracle documents the approved-sender form @YOUR_DOMAIN, but DKIM must already be active before creating it. Do not interpret “email domain exists” as domain-wide authorization. Configure DKIM first, then choose whether individual or domain-wide approval fits your intended scope. The domain-wide option authorizes more addresses and merits an explicit operational decision. Domain-wide approved sender prerequisite

2. Generate the domain's actual DKIM record

Open the email domain's DKIM section, select Add DKIM → Add new DKIM, and provide the selector prefix. OCI generates the final record; do not guess its complete selector from the prefix. Use Generate DKIM Record, copy the returned owner and value, publish them at your DNS host, then finish Add DKIM. Commercial realms use a generated CNAME; Oracle directs non-commercial realms to the supplied DKIM TXT value instead. OCI console DKIM procedure

A CNAME owner cannot coexist with unrelated TXT, MX or address records. Resolve a conflict rather than overwriting existing data. Check whether your DNS panel appends the zone suffix and confirm the full owner after saving. Use DNS-only publication where the host offers web proxying. For TXT keys, preserve the complete logical public key; do not split it into multiple independent records or publish a private key.

Where the actual authoritative DNS host offers these controls, use DNS-only aliases, not HTTP proxying or redirects, and keep a literal CNAME answer to each required target. Turn the relevant per-record Flatten option off when available, and ensure applicable zone-wide settings do not conceal the issued aliases. For Cloudflare specifically, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are Cloudflare behaviors, not assumed controls in another provider’s panel. If mandatory behavior or shared settings prevent the required CNAME answer, stop and coordinate a supported configuration without breaking dependent records. Do not blindly change the whole zone or remove an NS delegation; publish at the delegated authority when appropriate. Cloudflare CNAME verification, flattening controls. For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.

Use the Email Domain Details verification feature and confirm the intended key is active. OCI supports at most two DKIM keys per email domain, with only one active at a time. The presence of a second candidate key is not proof it signs outgoing mail. Managing DKIM

A DKIM-configured email domain applies to approved senders whose domain matches it exactly. Configuring a parent domain does not automatically give a child sending domain that key, or vice versa. Inventory and configure each actual sending domain before approving its addresses. This provider applicability rule is separate from DMARC relaxed alignment between related domains. Oracle DKIM domain matching

3. Choose SPF for the actual region and owner

Oracle's current SPF guide lists these commercial-region include mechanisms:

Use the current realm-specific guidance for government, sovereign and other realms. Do not turn the commercial table into a universal Oracle record. Add only the regional coverage required by your real sending routes, and use the Console's validation for approved senders. Oracle SPF configuration

If an SPF policy already exists at the relevant sending-domain owner, merge the needed mechanism before its final all. Preserve other approved senders, avoid duplicate includes, and do not publish another v=spf1 policy alongside it. Oracle's examples end in ~all; review an established policy's ending rather than changing it automatically.

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

SPF permits at most 10 evaluated DNS-query-causing terms, counting recursive include and redirect processing. The limit is not ten top-level vendors. Check the complete evaluation before adding another region. A one-time IP flattening exercise can become stale when providers change infrastructure. SPF standard

Why a root SPF include does not prove DMARC alignment

Receivers evaluate SPF using the delivered SMTP MAIL FROM domain, commonly reflected in Return-Path. OCI normally uses its bounce-server identity. Adding Oracle's include at your visible From domain does not, by itself, change that identity. A provider-domain SPF pass can be valid but unaligned with your From domain. Customer-domain DKIM or a correctly configured custom Return-Path supplies the relevant alignment route. Oracle Return-Path behavior

4. Configure a custom Return-Path when needed

The current management procedure requires a subdomain of your email domain and either DKIM configured for that domain or the domain verified. Choose an unused subdomain and keep its regional purpose clear in your change record. The Console supports one active custom Return-Path per email domain. Return-Path prerequisites

Open the domain's Custom Return Path section, select Add custom return path, enter the subdomain and description, then select Generate CNAME Record. Copy the exact returned CNAME owner and value into public DNS and complete the add operation. Check the status on the email-domain details page. Do not derive the regional target from a sample hostname. Creating a custom Return-Path

Publish the required DNS within 72 hours of creating the resource. Oracle says a missing record after that deadline moves the resource to Failed; its documented recovery requires deleting the failed Return-Path resource before recreating the same name. Check the actual state and obtain change authorization before that recovery action rather than deleting a working resource.

Why older Oracle instructions show MX plus SPF

The email-domain introductory page describes a regional MX-plus-SPF arrangement; the best-practices page discusses either that arrangement or a CNAME. The current dedicated Console procedure issues a CNAME. Follow the records and method issued for your actual workflow. Never combine CNAME with TXT or MX at the same owner. If an existing implementation uses the older method, preserve it while confirming its supported migration path with Oracle instead of replacing its records from this article. Oracle alternative-method discussion

A custom bounce subdomain can satisfy relaxed SPF alignment with the same organizational domain, but it does not satisfy strict aspf=s when the visible From uses a different exact domain. Keep aligned DKIM working and test the policy mode actually deployed.

5. Verify the message, not just the Console

Use placeholders only after replacing them with your actual hostnames:

dig +short TXT YOUR_SENDING_DOMAIN
dig +short CNAME YOUR_GENERATED_DKIM_OWNER
dig +short CNAME YOUR_CUSTOM_RETURN_PATH_OWNER
dig +short TXT _dmarc.YOUR_EXACT_FROM_DOMAIN

For a TXT-based DKIM realm, query TXT at the issued selector owner instead:

dig +short TXT YOUR_GENERATED_DKIM_TXT_OWNER

Check both the authoritative nameserver and an independent resolver if results disagree. Expect the exact generated values, no conflicting CNAME data, a single valid SPF policy where applicable, and the intended DMARC policy.

For each commercial-realm DKIM CNAME, also follow its alias chain to the usable public DKIM verification key. A matching CNAME target without a resolvable key does not satisfy DNS acceptance; retain the issued TXT check for non-commercial realms.

Next send an authorized test through the production application's actual OCI region and endpoint. Record submission acceptance separately from final delivery. At the controlled receiver, inspect trusted Authentication-Results, the visible From, smtp.mailfrom, and DKIM d= and s=.

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

Require the configured customer-domain signature to pass and align. If a custom Return-Path is part of the design, confirm it is the actual MAIL FROM identity and SPF passes for it. Check dmarc=pass and identify the aligned mechanism. A default Oracle-domain SPF pass or Oracle-domain DKIM signature alone is not evidence that your domain aligned. DMARC identifier alignment

For a multi-region deployment, repeat the test in each region. Keep a compact acceptance worksheet: region, compartment, approved sender, DKIM selector/status, Return-Path/status, public DNS results, timestamp and redacted receiver evidence. A successful test from one region does not certify failover.

Diagnose the actual smtp.mailfrom result independently: fail or softfail calls for checking the connecting sender against the approved authorization; temperror is a transient evaluation failure, often DNS; permerror requires checking malformed or duplicate policies and the evaluated lookup budget. An aligned DKIM pass does not repair these SPF faults. Do not change an unrelated apex policy to fix a provider-controlled envelope domain. SPF result definitions.

6. Preserve DMARC enforcement and reporting

DMARC passes with either a passing aligned SPF identity or a passing aligned DKIM identity. Relaxed alignment permits the same organizational domain; strict alignment requires exact domain equality for the selected mechanism. Check the visible From domain's policy and any inherited organizational-domain policy before creating or editing a record. A missing child record is not permission to replace inherited enforcement with p=none.

Preserve an existing policy. Only for a reviewed first deployment that does not weaken existing or inherited enforcement, provision an authorized reporting destination and publish one TXT record using this structural template:

Full owner: _dmarc.YOUR_EXACT_FROM_DOMAIN
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:YOUR_AUTHORIZED_REPORT_ADDRESS

Replace every placeholder. Use literal semicolons, not escaped backslashes. In the exact sender-domain zone the relative owner is _dmarc; in a parent zone include the sender's subdomain labels. Do not add a second DMARC record. Verify the effective policy and report receipt before considering enforcement changes. Current RFC 9989 removes pct; percentage-based policy rollout is not a current-standard control.

For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names.

OCI Email Delivery is not an inbox or automated DMARC-report processor. Arrange reporting separately. External aggregate-report destinations can require authorization under RFC 9990 section 4. Do not automatically add ruf failure reports, which can expose message-related information; evaluate the privacy and operational implications under RFC 9991.

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.

Troubleshooting and safe key maintenance

For rollover, prepare the replacement public record before making it active, confirm public resolution, then switch under a controlled change window and inspect newly delivered mail. Retain the previous public selector while messages signed with the old key may remain in flight. OCI's two-key, one-active limit means replacement planning must account for both existing slots; do not delete a needed key to free space without reviewing the impact. OCI DKIM lifecycle

Evidence and implementation limits

Oracle's pages did not expose a reliable per-page modification date in the retrieved bodies. Several direct requests returned an unavailable shell; readable official indexed bodies were used instead. Current dedicated task pages govern the Console flow where introductory pages differ.

No customer account, DNS zone, submission endpoint or real-message test was operated for this guide. Complete the account, DNS and message acceptance worksheet for your sending route. This guidance is based on documentation, not hands-on delivery testing.