How to set up DMARC/DKIM/SPF for Oracle Email Delivery
Published 16 Aug 2026
Updated 23 Oct 2026
14 min read
Summarize with
Updated on 23 Oct 2026: We clarified Oracle service scope, return-path DNS setup, and strict DMARC domain matching.
Oracle Email Delivery works with DMARC when you add the visible From domain in Oracle Cloud Infrastructure (OCI), publish Oracle's DKIM CNAME, configure the correct regional SPF authorization and custom return path, then publish DMARC at _dmarc on your domain. DMARC passes when either the DKIM signing domain or the SPF-authenticated return-path domain matches the visible From domain.
Configure both DKIM and the custom return path. DKIM authenticates your From domain without depending on the return path, while Oracle's custom return path lets SPF contribute a matching domain. Keep an existing p=quarantine or p=reject policy in place. For a new DMARC deployment, begin with p=none and inspect real traffic before enforcement.
Confirm your Oracle sending service
Use the OCI Console steps below when your application submits messages through OCI Email Delivery. Oracle Fusion application email and other Oracle-managed notifications have service-specific authentication workflows. An oracleemaildelivery.com hostname in a report does not identify which application controls the sender.
Oracle's DKIM setup documentation excludes OCI Classic services such as Fusion Apps, and also excludes Oracle Integration Cloud Generation 2 and Oracle Transportation and Global Trade Management. Use the generating service's authentication workflow or contact Oracle Support. Give each service a distinct DKIM selector when it shares your From domain.
Add your domain
Create the Email Domain in the OCI region used for Email Delivery, in a compartment covered by your IAM permissions. The domain must exactly match the domain after @ in the visible From address, including any sending subdomain. Oracle rejects mail unless its From address or domain also exists as an Approved Sender. The sending application can run in a different compartment.
Creating an email domain in Oracle Email Delivery
- Open Email Delivery. In OCI, select Developer Services, Application Integration, Email Delivery, then Email Domains.
- Confirm scope. Select the sending region and the compartment where the email resources and IAM permissions belong.
- Create the domain. Select Create Email Domain, enter example.com or the exact subdomain used in From, then select Create. Do not enter a public mailbox domain.
- Register senders. Open Approved Senders and create each exact From address. After DKIM becomes Active, create @example.com as an Approved Sender to authorize all addresses on that exact domain. This does not authorize its subdomains.
- Check the region. Approved Senders are regional. Create them in every region that submits mail, and retry with backoff if a new sender returns a temporary authorization failure.
Match the exact From domain
A DKIM key created for mail.example.com does not sign mail sent as user@example.com. Add each distinct From domain and give each one its own DKIM setup.
Set up SPF
Oracle publishes different SPF includes by sending region. When adding Oracle authorization to an existing SPF TXT record, use only the sending regions you need and insert the include before the final all mechanism. Never publish a second SPF record at the same hostname. Adding Oracle to the visible From domain's SPF record alone does not change the SMTP MAIL FROM domain used for DMARC.
Follow the current Oracle SPF instructions for your realm. The commercial-region values below are valid starting points, but government and sovereign realms use different domains.
Commercial-region SPF examplesdns
# 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
- Inspect the current record. Locate the TXT record beginning with v=spf1 at the visible sender domain. For a custom return path, check whether the hostname already has records before choosing Oracle's CNAME workflow.
- Choose the region. Use rp.oracleemaildelivery.com for Americas, ap.rp.oracleemaildelivery.com for Asia/Pacific, or eu.rp.oracleemaildelivery.com for Europe.
- Merge safely. Insert Oracle's include before ~all or -all in the SPF record being edited and preserve every legitimate sender. Keep SPF within its limit of ten DNS lookup-causing terms, including nested includes.
- Create the return path. First activate DKIM or verify the Email Domain in OCI. Open the domain, select Custom Return Path, select Add custom return path, and enter an unused subdomain such as bounce.example.com.
- Publish Oracle's CNAME. Select Generate CNAME Record, copy Oracle's exact host and target into DNS, then select Add custom return path. Publish it within 72 hours.
For the CNAME workflow, Oracle supplies SPF and bounce routing through the CNAME target. Do not publish SPF TXT or MX records at the same hostname as that CNAME. Oracle also documents an alternative using SPF TXT and MX records. Choose one method. Custom return paths are regional, so use a distinct subdomain per region. See Oracle's return-path DNS options. Only one custom return path can be active per Email Domain.
Generating a custom return-path CNAME in Oracle Email Delivery
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
Run the SPF check against the return-path hostname, following its CNAME when present. Check for one valid SPF record and no more than ten evaluated DNS lookup-causing terms across nested records. A result for the visible From domain does not prove DMARC's SPF domain match. In a received message, inspect smtp.mailfrom in Authentication-Results to identify the domain SPF actually checked. The limit is defined in RFC 7208.
Relaxed SPF domain matching is the default (aspf=r). For From: user@example.com, a passing SPF result for bounce.example.com satisfies that match. With aspf=s, those domains differ, so SPF cannot satisfy DMARC even when the custom return path is Active. Keep an existing strict policy and confirm DKIM passes with the required matching d= domain. See the domain-matching rules in RFC 9989.
Set up DKIM
DKIM is the primary authentication path for Oracle Email Delivery. OCI generates the private key and a DNS CNAME, then signs outbound messages after the record becomes active. Use a selector that identifies Oracle and the rotation date.
Adding a DKIM selector and CNAME in Oracle Email Delivery
- Open DKIM. Select the Email Domain, choose DKIM on its detail page, then select Add DKIM and Add new DKIM.
- Name the selector. Enter up to 63 lowercase letters, digits, or dashes, such as oracle-202608, then select Next.
- Generate the record. Select Generate DKIM Record and copy the CNAME host and target exactly as OCI displays them. Non-commercial realms can provide a TXT value instead.
- Publish in DNS. Create the record with the DNS provider authoritative for the domain. Do not append the zone twice if the provider adds it automatically.
- Activate and test. Return to OCI, select Add DKIM, and wait for Active. Send a message and confirm dkim=pass with header.d equal to the exact From domain configured in OCI. With adkim=s, an exact domain match is required.
DKIM CNAME shape onlydns
oracle-202608._domainkey.example.com. IN CNAME oracle-202608.example.com.dkim.region.oracleemaildelivery.com.
Use Oracle's generated values
The example shows the record's shape, not a deployable value. Copy both fields from your domain's OCI panel. Oracle allows two DKIM keys per Email Domain, but only one is active at a time, which supports controlled key rotation about every six months.
Set up DMARC
Publish one DMARC TXT record at _dmarc.example.com. Start a new deployment at p=none so aggregate reports help identify legitimate sources without asking receivers to quarantine or reject failures. If the domain already uses p=quarantine or p=reject, keep that policy and fix Oracle without lowering enforcement.
Replace example.com in the reporting address with a mailbox that accepts aggregate XML reports. Oracle Email Delivery does not receive or process these reports for you. The DMARC record generator can build the same record and add optional tags while keeping an explicit p policy.
Starting DMARC TXT valuedns
v=DMARC1; p=none; rua=mailto:dmarc@example.com
- Choose the host. Check the exact From domain and its inherited DMARC policy first. For mail.example.com, a separate record belongs at _dmarc.mail.example.com. A subdomain can inherit its parent domain's policy, including sp, so add a separate record only when needed and preserve any existing enforcement.
- Publish one record. Use the exact starting value shown above for a new deployment, changing only the report mailbox to one you control.
- Keep enforcement. Do not replace an existing p=quarantine or p=reject record with p=none. Repair Oracle's DKIM or custom return path under the current policy.
- Confirm domain matching. Require either DKIM pass with a matching d= domain or SPF pass with a matching return-path domain. One matching pass is enough for DMARC.
Do not publish duplicate DMARC records
Two TXT records beginning with v=DMARC1 at the same hostname make DMARC invalid. Edit the existing record instead of adding another one.
Check the published hostname after DNS propagation and cached records expire according to their TTL. For this setup, confirm one valid record with an explicit p policy and the correct rua report address. Use the DMARC checker to inspect parsed tags and syntax.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
A valid DNS record proves only that receivers can read the policy. It does not prove Oracle messages pass DMARC. Send a real message through the same region, SMTP credentials, From address, and application path used in production.
Inspect the receiving server's Authentication-Results header. A healthy message shows dmarc=pass and at least one matching path. If dmarc=fail accompanies dkim=pass, compare header.d with header.from and check adkim. For dkim=neutral or permerror, read the receiver's diagnostic text and check the signature syntax as well as the selector and DNS record.
Verify and troubleshoot
Verify with a message generated by the production application, not a hand-built message from another client. Use the same OCI region, approved sender, envelope sender, and visible From domain so the test exercises the actual path.
Send a message through Oracle Email Delivery to Suped's email tester below, then review the SPF identity, DKIM selector and d= value, DMARC result, return path, reverse DNS, and visible headers together.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Raw SPF pass can still accompany DMARC fail when Oracle's default return path uses a regional oracleemaildelivery.com domain. Activate the custom return path to make SPF use your domain, or rely on a fully passing DKIM signature whose d= domain matches the visible From domain.
OCI also verifies SPF and DKIM on the Email Domain detail page. Use that status for DNS discovery, then use a received message for end-to-end proof. Enable outboundaccepted and outboundrelayed logs to distinguish submission errors from delivery errors. Relay logs also include dkimSelector and any dkimError. Successful relay does not prove inbox placement. See Oracle's Email Delivery log fields.
Checking authentication status and delivery logs in Oracle Email Delivery
|
|
|
|---|---|---|
SPF | pass | smtp.mailfrom matches header.from under aspf |
DKIM | pass | header.d matches header.from under adkim |
DMARC | pass | At least one passing authentication method has a matching domain |
Policy | Matches the published policy | Policy discovered for header.from, including any inherited policy |
Authentication results to inspect; either matching SPF or matching DKIM is enough for DMARC
- SPF permerror. Remove duplicate SPF records, repair invalid mechanisms, and stay within ten evaluated DNS lookup-causing terms, including nested includes.
- DKIM key not found. Use the selector s= and domain d= in DKIM-Signature to check <selector>._domainkey.<domain>. Follow any CNAME to the TXT public key and remove duplicated zone suffixes.
- DKIM passes, DMARC fails. Compare header.d with the visible From domain and the adkim setting. Confirm at least one passing signature has the required domain match.
- Return path failed. Republish the generated CNAME. If the record was not published within 72 hours, delete the Failed custom return path and create it again.
- SMTP authorization failed. Confirm the Approved Sender, region, compartment policy, SMTP credentials, and From address before changing DNS. Oracle recommends matching the submitted SMTP envelope From to the header From; if they differ, both addresses need authorization.
Monitor Oracle authentication changes
A one-time test cannot detect later DNS changes or new sending sources. Aggregate DMARC reports show authentication results for messages that reach reporting receivers, and usually arrive daily rather than immediately. Use OCI logs for submission failures that receivers never see. Reporting cadence is described in RFC 9990.
- Monitor every source. Track Oracle's regional infrastructure separately from other approved and unknown senders using aggregate-report evidence.
- Alert on change. Use report-based alerts for changes in authentication results or sending sources, and DNS monitoring for record changes.
- Route the fix. Give the owner the affected domain, source, failure path, sample volume, and exact remediation steps.
- Watch reputation. Correlate authentication with deliverability and blocklist (blacklist) changes for the sending domain and infrastructure.
Review Oracle traffic in Suped
Suped is our DMARC reporting and email authentication platform. Suped's DMARC monitoring groups aggregate reports by sending source so you can review Oracle's SPF and DKIM results, investigate failures, and track changes after enforcement. Alerts based on these reports depend on when receivers send them.
Set rua to the reporting address issued for your domain and keep alert recipients current. If reports go to another organization's domain, verify that the destination authorizes them through its external reporting DNS record. Allow at least one reporting cycle before investigating missing reports. An oracleemaildelivery.com hostname alone does not prove that mail belongs to your tenancy.
Secure your domain with p=reject
Move to p=reject only after Oracle and every other legitimate source consistently pass DMARC. Do not lower a domain that already uses p=quarantine or p=reject. Repair failures under the current policy and test known forwarding paths. Forwarding commonly breaks SPF; DKIM can survive when signed content remains unchanged.
Advance the policy
- Known sources. Every material sender is identified and owned.
- Stable DKIM. Oracle signs production mail with a matching domain.
- Clean reports. Legitimate volume passes across normal sending cycles.
- Named owner. Each source has a contact for future breakage.
Hold the policy
- Unknown volume. A material source has no confirmed owner.
- Wrong d= domain. Oracle DKIM passes but does not match From.
- Broken forwarding. Expected traffic loses both matching paths.
- Unmonitored change. No alerting or rollback owner exists.
- Inventory first. Map every report source to an application, owner, approved sender, DKIM domain, and return-path domain.
- Fix high-volume failures. Correct Oracle's DKIM or custom return path and test every active region before changing policy.
- Apply quarantine. Move a new deployment to p=quarantine, observe normal business cycles, and investigate any legitimate mail placed in spam.
- Move to reject. Publish p=reject only when legitimate failures are understood and controlled, then confirm reports and alerts continue.
- Keep monitoring. Treat enforcement as a maintained control because senders, DNS records, regions, and keys change after rollout.
Enforcement policy alternatives; publish one TXT value at a timedns
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Suped's Hosted DMARC lets you manage policy changes after an initial DNS delegation. Review Oracle and other legitimate sources before each move, then monitor incoming reports for regressions after p=reject is active.
Keep rejection reversible
Record the DNS owner, policy-change time, expected TTL, validation evidence, and rollback decision before publishing p=reject. A rollback should change only the DMARC policy, not remove working DKIM or SPF records.
FAQ
Yes. Publish DMARC on your own From domain, enable Oracle-generated DKIM, and configure a custom return path when SPF also needs a matching domain. Oracle does not publish your DMARC policy for you.
Oracle Email Delivery uses oracleemaildelivery.com for regional mail infrastructure. An rDNS suffix alone does not identify the sending application or prove that mail belongs to your tenancy. Confirm the DKIM signing domain, SPF identity, return path, approved sender, and DMARC report source together.
rp.oracleemaildelivery.com is the Oracle Email Delivery SPF include for Americas commercial regions. Asia/Pacific uses ap.rp.oracleemaildelivery.com and Europe uses eu.rp.oracleemaildelivery.com. Do not add an include solely because it appears in a lookup or report. Confirm the sending service and region in OCI, then use Oracle's current documentation.
Yes. DMARC passes when Oracle DKIM passes and its d= domain matches the visible From domain, even if SPF uses a nonmatching Oracle return path. A custom return-path subdomain can provide a second matching path with aspf=r, but fails strict SPF matching with aspf=s when it differs from the From domain.
Check for a missing or incorrect generated CNAME. Oracle requires the DNS update within 72 hours. Compare the host and target with OCI, remove any duplicated zone suffix, and check for conflicting TXT or MX records at the CNAME hostname. If the 72-hour window expired, delete the Failed resource and create a new custom return path.
Oracle Email Delivery supports up to two DKIM keys per Email Domain, with one active key at a time. Create a new selector, publish and verify its CNAME, and confirm production messages use it. Keep the old public key available until messages signed with it have cleared delivery retries, then retire it. Oracle recommends rotation about every six months.
