Confirm OCI Email Delivery is the transport
Use this procedure only when the application actually sends through Oracle Cloud Infrastructure Email Delivery. Record the tenancy, compartment, region or realm, application and desired From domain before touching DNS. This matters because the Oracle product name alone does not identify the transport. Oracle excludes several SaaS and integration services from its OCI DKIM console procedure. See OCI Email Delivery configuring DKIM.
This is a configuration and verification plan, not a completed tenant change. Exact DNS values must be generated or confirmed in the relevant service and realm. Keep SMTP credentials, private keys and tenant secrets out of the article and evidence packet.
Prepare the domain and sender inventory
Decide which organizational domain is intended to appear in From and which application is authorized to use it. Verify control of its public DNS. Create a change record listing other senders using that domain, current SPF authorization, existing selectors and the owners of those integrations. A clean new subdomain may simplify operations, but it must fit the business identity and the supported provider configuration.
Approved senders belong to a compartment and are region-specific. Oracle requires approval for the sending addresses and discusses the additional authorization implications of mismatched submitted envelope and header addresses. See OCI managing approved senders. Therefore, compare the application endpoint region with the resource region before diagnosing a rejected submission as a DNS problem.
Generate the correct DKIM record
In the applicable commercial OCI console workflow, open the email domain, add a DKIM key and generate the provider record. Oracle describes a CNAME for the commercial flow and a TXT value for non-commercial realms. Use the exact owner and value displayed for the selected domain and realm, not a sample assembled from a remembered region code. See OCI Email Delivery configuring DKIM.
The DNS operator should check whether the supplied owner is fully qualified or must be entered relative to the zone. Record the resulting full name after the DNS interface applies its suffix. A duplicated zone suffix is a publication error, even when the application-generated value is correct. Confirm public authoritative resolution and then complete service-side activation. Do not remove another application's selector to make room for a new one.
Reconcile SPF with the sending region
Oracle's SPF documentation provides region-dependent authorization, including separate commercial groupings and references for government or other realms. Do not assume a commercial include is suitable for a sovereign or government deployment. See OCI Email Delivery configuring SPF. Obtain the applicable current value and evaluate it alongside existing senders.
Publish one SPF policy at the relevant owner and assess its DNS-query budget. Preserve other legitimate authorization instead of overwriting it with an Oracle-only example. The SPF standard's record selection and query limits apply to the combined policy. See RFC 7208 Sender Policy Framework. An SPF validation in the console is useful configuration evidence but is not a substitute for receiver-side alignment analysis.
Exercise submission and receiver verification
First verify that the application submits through the intended endpoint using the approved sender configuration. Then inspect a fresh controlled received message. Record the visible From, delivered envelope identity, every relevant DKIM signing domain and selector, and the trusted receiver's authentication results. A successful SMTP submission proves acceptance for processing, not successful authentication at the final destination.
Use the delivered identities rather than assuming the submitted envelope is unchanged. A DKIM pass shows signature verification; DMARC additionally needs the appropriate relationship to From. Determine which passing mechanism supplies alignment under the published alignment mode. See RFC 6376 DomainKeys Identified Mail and RFC 9989 Domain-based Message Authentication Reporting and Conformance. Keep delivery, inbox placement and authentication as separate outcome fields.
OCI Email Delivery acceptance worksheet
- Application and message purpose: ____; tenancy or approved internal reference: ____.
- Compartment: ____; endpoint region: ____; approved-sender region: ____; realm: ____.
- Email domain: ____; submitted From and envelope addresses: ____.
- DKIM record source: ____; full owner: ____; record type and target: ____.
- Authoritative DNS response and timestamp: ____; service activation evidence: ____.
- Applicable SPF source and existing-policy review: ____; DNS-query assessment: ____.
- Test Message-ID and receiver: ____; observed envelope domain: ____.
- DKIM d= and s=: ____; SPF and DKIM results: ____; DMARC and aligned path: ____.
- Recovery settings, application owner and approval decision: ____.
Use a new row for each region or application configuration. Do not mark a secondary endpoint ready merely because it uses the same visible domain.
Fictional diagnosis of regional sender rejection
Fictional example only: Cedar Lab moves an application endpoint to a second region. Its DNS records remain unchanged and resolve correctly, but submissions fail before reaching the test mailbox. The team discovers that the approved sender exists only in the first region. It verifies the intended regional resource and authorization rather than repeatedly editing SPF.
After submission succeeds, the team still checks a new received message for DKIM and DMARC. Resolving the regional resource issue does not prove downstream alignment. No Cedar Lab deployment was inspected.
Release and maintenance gates
Approve a pilot only after the application resource, DNS and received-message evidence agree. Preserve the previous working path for rollback, document key ownership and schedule rotation according to the applicable provider guidance. Treat a change in domain, region or realm as a new verification event.
All tenant-issued values, live DNS checks, provider activation, receiver observations, visual review and human SME approval remain pending. This article covers OCI Email Delivery, not every Oracle-branded email service, and remains unpublished.
Plan key rollover without losing the working route
The current OCI console documentation permits two keys per email domain but only one active record at a time. It recommends rotation every six months. Record the active selector and approved transition before replacing anything, and use the service-specific rotation instructions rather than assuming that adding a second public key activates it. A rotation plan is not a completed test.
Separate message acceptance from policy rollout
A passing aligned SPF result can satisfy a message evaluation, but does not alone justify moving an entire domain to reject. RFC 9989 Section 7.4 requires valid DKIM for domains publishing p=reject and warns about indirect-mail interoperability. Inventory all legitimate senders and indirect routes before the policy owner approves enforcement. No DNS change, tenant operation or received-message test was executed for this article.