Source review dated 8 November 2026. Provider settings and acceptance exercises below are documentary guidance, not executed account, DNS or message tests.
Use NetSuite's current two-CNAME DKIM model
For email sent by a NetSuite production account, the current first-party setup differs from older guides that ask you to invent a selector, generate a key pair and paste a public TXT key. Oracle documents a change beginning with NetSuite 2024.1: the account generates information for **two CNAME records**, and NetSuite manages DKIM key rotation. Only one of those CNAMEs having a linked DKIM key at a given time is documented as expected. Do not delete the other merely because a lookup shows no current key behind it. NetSuite DKIM overview.
This guide is for that NetSuite account workflow. Oracle OCI Email Delivery, SuiteProjects Pro and other Oracle products have separate configuration models. Do not import their custom Return-Path settings or DNS targets into this procedure. Identify the production account and the exact email-generating action: invoice, transaction notice, campaign or application script. A successful test in a different account or mail product is not proof for the intended route.
Before work starts, inventory the From domains that the account actually uses. Include subsidiary or brand identities only where relevant to the configured workflows. Assign a NetSuite administrator and a DNS operator. Save the existing domain settings, DKIM-related RRsets and a baseline message or error, with confidential invoice or customer content removed from the evidence copy.
Add the domain and publish both generated records
Oracle's preferences page points to **Setup → Company → Email → Email Preferences**, then **Email Domains (DKIM)**. Enter each sending domain on its own row and save it. The page exposes Status and Details. Use the current domain row rather than assuming the display name of the company establishes a signing domain. Email Domains preferences.
Open the relevant domain, choose **Show DNS Info**, and copy both rows of generated CNAME information to the authoritative DNS service. Oracle's procedure explicitly requires two CNAME records per email domain. Record the full intended owners, targets and the DNS editor's input convention. A relative-label editor can append the zone automatically; entering the full name in the wrong field can publish a doubled owner. Inspect for existing data at each owner before changing anything. Set Up CNAME Records in DNS.
Do not generate your own selector names, substitute a generic target or put the CNAME target into a TXT value. The delegation gives NetSuite the documented role in key rotation. Preserve a record of who authorized it and which account supplied the targets. Query the CNAME owners at authoritative DNS and follow the target chain when checking the active public key. Test the selector actually present in a fresh message rather than assuming which of the two is active.
For an existing setup, Oracle's FAQ says a domain may already show Ready while still displaying a warning to add CNAMEs. It instructs customers to add the generated CNAME records and **not delete the existing TXT record**. Keep that migration distinction explicit; Ready alone is not a reason to discard the older record. NetSuite DKIM FAQ.
Read Status and Details before changing anything else
Oracle defines Requires Action as a domain whose DNS needs attention, Pending Verification as records being checked, and Ready as a verified domain whose messages use the domain keys. Its guidance recommends contacting NetSuite support if Pending Verification persists beyond 24 hours after publication. Preserve publication time and the exact Details message so a support request can distinguish an absent record, a wrong target and a verification delay. Do not repeatedly remove and recreate the domain as a substitute for diagnosis. DKIM status meanings.
Treat those status descriptions and timing guidance as application behaviour, not a guarantee of worldwide DNS convergence. Authoritative correctness, resolver caching, account readiness and a receiver's message verdict are separate observations. A Ready label is necessary evidence of this workflow, but the business acceptance test still needs an actual message.
Check the real From address and the reply path
If DKIM setup is incomplete, NetSuite documents rewriting the From header by default. Its example moves the original address into the display string and uses a system@sent-via.netsuite.com address. A recipient may therefore see what looks like the original address in the mailbox interface while the actual address belongs to NetSuite. Inspect the address inside the header, not just the displayed sender label. FROM Headers in Email Can Be Rewritten.
A DMARC pass for a rewritten NetSuite From does not prove authentication of the organization's original From domain. After setup, confirm both the intended visible identity and a passing aligned DKIM signature. Capture the envelope SPF result too, but do not assume adding a NetSuite SPF term to the organization's root policy changes the actual envelope identity. DMARC can pass through aligned DKIM without aligned SPF. DMARC identifier alignment.
Keep **Capture Email Replies** tests distinct. Oracle documents a special reply address that routes replies through NetSuite for recording and forwarding. That incoming/forwarded conversation path is different from an outbound invoice originated by the account. Test reply capture and onward delivery separately if the business relies on them, without treating a forwarding failure as proof that outbound DKIM setup failed. DMARC-Compliant Messaging in NetSuite.
Fill in the NetSuite two-record worksheet
Use one copy per production account and From domain.
- Account/environment: ______. Workflow and responsible operator: ______.
- From domain entered in Email Domains: ______. Status / Details / observation time: ______.
- CNAME row 1: intended owner ______; generated target ______; authoritative answer ______; UTC time/TTL ______.
- CNAME row 2: intended owner ______; generated target ______; authoritative answer ______; UTC time/TTL ______.
- Existing TXT key retained during migration: ______. Existing-record conflict or warning: ______.
- Fresh message ID and sending time: ______. Actual From address domain: ______. Rewritten? ______.
- Envelope domain/SPF result: ______. Every DKIM
d=/s=/ result: ______. - Active selector's authoritative key path: ______. Trusted receiver DMARC verdict and aligned path: ______.
- Reply capture enabled? ______. Separate reply/forwarding result: ______.
- Rollback or sending-pause owner: ______. Outstanding evidence: ______. Release approver: ______.
Decision: an absent CNAME is a DNS publication issue; a Ready domain with a different actual From requires a workflow/sender check; a passing service-domain signature against a rewritten service From does not prove that customer branding is configured. Inspect those branches before broadening SPF or weakening DMARC.
Fictional worked diagnosis: Ready and a migration warning
**Fictional training example, not a NetSuite production test.** An account sends invoices from billing.example and has an older DKIM TXT record. The domain shows Ready, but the interface requests the two CNAME records. The operator proposes deleting the TXT record first to “start clean.” The source-backed migration instruction is to retain it and add the generated CNAMEs.
After both records are published in this fictional case, only one CNAME target exposes an active DKIM key. That matches the documented rotation model and does not justify deleting the second CNAME. A fresh invoice carries a passing signature with d=billing.example, and the trusted receiver reports DMARC pass even though SPF uses an unaligned service envelope. The DKIM identity, not a guessed root-domain SPF change, supplies the passing path.
A separate test from a sandbox behaves differently. Oracle says keys are not copied to non-production accounts and email preferences there can constrain recipients. The production evidence cannot simply be copied into the sandbox worksheet. Account-scope note in the DKIM overview.
Recovery and release gates
Preserve the generated DNS information, old records and before/after status. If the new setup fails, stop the affected outbound workflow under the approved plan and investigate the specific account and owner names. Do not erase both CNAMEs to force a fresh start, and do not remove a key still needed by queued or previously signed mail without a controlled retirement decision. Restore only changes owned by this release and retest a fresh invoice or other intended workflow.
**No NetSuite account, live DNS publication or received message was tested for this manuscript.** The current review retrieved readable first-party pages and retained raw responses. Earlier unavailable-page responses are not current access evidence. Documentary verification is not a tenant acceptance test. Live account applicability, authoritative DNS, message and reply-path evidence, visual review and human SME approval remain open.