NetSuite’s current DKIM setup uses two account-generated CNAME records per sending domain or subdomain. Add the domain under Email Preferences, publish both records, and wait for the domain to show Ready. Do not follow older instructions to create a private key or manually activate a legacy Domain Keys row. Oracle changed this workflow in NetSuite 2024.1. Current NetSuite DKIM model
A separate SPF change is conditional, not the main path to DMARC compliance. Oracle distinguishes email-service requirements from fax-service requirements, so the two published includes are not interchangeable. NetSuite SPF guidance
This guide covers email sent by NetSuite using your domain, especially production-account business mail. It does not configure every Oracle product, a third-party delivery integration, or a separate marketing platform.
No NetSuite account, customer DNS zone, or delivered message was tested for this guide.
Inventory the actual NetSuite senders
List the From domains used by invoices, order messages, employee-generated email, workflows, and campaigns. Record which account and process generates each message. The point is not to assume every category uses a different transport, but to avoid declaring coverage after testing only one convenient sample.
For example, billing@example.com and offers@mail.example.com are different domain entries. Oracle instructs administrators to repeat the configuration for each domain and subdomain used to send mail. Enter email domains
A production configuration is not evidence of a sandbox configuration. Oracle says DKIM keys are not copied to non-production accounts, whose email preferences commonly restrict recipients. Keep sandbox and production test evidence separate. Production and non-production scope
If your application actually hands mail to a separate Google or Microsoft relay, use the relevant route documentation instead. EmailAuth’s Google Workspace SMTP relay guide and Microsoft 365 application mail routes help distinguish those paths from NetSuite-native sending.
Prepare account permissions and DNS access
The NetSuite operator needs the Administrator role or Full level of the Set Up Company permission. The DNS operator needs authorized access to the actual authoritative zone. Domain registration and DNS hosting may be with different companies. Required NetSuite permissions
Before editing, save the existing records and establish a rollback owner. Include current DKIM selectors, SPF policies, DMARC settings, TTLs, and any records occupying the proposed CNAME names. Do not combine an authentication change with unrelated MX, website, or account-access modifications.
Confirm whether the DNS editor expects a full hostname or automatically appends the zone. For a supplied owner SELECTOR._domainkey.example.com, the host field may need only SELECTOR._domainkey in the example.com zone. SELECTOR is a placeholder, not a value to publish.
For an issued signing domain such as news.example.com, a full owner SELECTOR._domainkey.news.example.com is SELECTOR._domainkey.news relative to the parent example.com zone, or SELECTOR._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com itself is delegated, the relative owner there is SELECTOR. Replace the selector placeholder with the issued value, preserve the account’s exact type and public value, and publish at the actual authority without removing the NS delegation. This example explains name placement, not automatic product eligibility for a new domain. DKIM owner construction, relative DNS names.
A CNAME owner must not conflict with another ordinary record at that name. Preserve a working sender rather than deleting its record to satisfy a new form. CNAME owner restrictions
Generate and publish the two DKIM CNAMEs
- Open Setup > Company > Email > Email Preferences.
- Select Email Domains (DKIM).
- Enter the exact sending domain or subdomain and save.
- Copy the generated DNS information from the banner or Show DNS Info.
- Publish both owner/target pairs as CNAME records in your authoritative DNS zone.
The values must come from your account. Never substitute a selector or target copied from a screenshot. Generate domain records and publish both CNAMEs
Keep these authentication CNAMEs DNS-only/unproxied, not behind a website proxy. Disable CNAME flattening for verification aliases where it would hide the required target. Cloudflare CNAME-verification guidance
For authentication records that actually use CNAME, retain a literal CNAME answer to the issued target and use DNS-only rather than HTTP proxying. Turn the relevant per-record Flatten setting off where available, and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, 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 DNS-host behaviors, not assumed controls in the sending application. If mandatory behavior or shared settings cannot preserve the required CNAME answer, stop and coordinate a supported layout without breaking other services or removing shared NS delegations. Do not blindly disable features across the whole zone. Cloudflare verification guidance, flattening controls and limits.
NetSuite manages key rotation through these aliases. Only one CNAME having a DKIM key linked at a particular time is expected; the other record must still remain published. A missing TXT key behind the standby target is therefore not automatically a failed deployment. NetSuite key-rotation behavior
Keep a two-row worksheet containing the supplied name, supplied target, public CNAME answer, and time checked. This is more useful during a support escalation than a screenshot showing only that two rows exist in the DNS dashboard.
Migrating an older TXT-based configuration
Oracle’s migration guidance explicitly says to retain the existing TXT record while adding the new CNAME records. Retrieve the new pair from the existing domain row’s Show DNS Info. Do not erase the old key just because the new setup uses another record type. Existing-domain migration
This instruction does not permit a TXT and CNAME to occupy the same exact owner. If the generated names collide, investigate the supplied values and involve the relevant administrators or support before changing production DNS.
Interpret Ready and pending states correctly
Oracle documents three useful setup states: Requires Action means DNS needs attention; Pending Verification means checks are underway; Ready means the domain is verified for signing. It reports a typical verification interval of 30 minutes to two hours after prompt publication, with support escalation if pending persists beyond 24 hours. These are guidance, not a guaranteed completion time. DKIM status definitions
Review both Status and Details. Current setup does not require the old Active-checkbox workflow. Once DNS checks are complete, move on to message validation rather than searching for a legacy activation control.
Retain the published aliases after Ready appears. They are continuing dependencies, not disposable ownership tokens. Record the configuration owner so a later DNS migration includes them in its checklist.
Use the right SPF rule for the right requirement
Oracle says SPF alignment is not required for NetSuite mail when the appropriate DKIM path is in place. It advises adding SPF only when a recipient’s infrastructure specifically requires it. The documented conditional values are:
- Email infrastructure:
include:sent-via.netsuite.com. - Fax infrastructure, such as the documented eFax case:
include:mailsenders.netsuite.com.
Do not reverse those roles or add both without a demonstrated need. Oracle’s email-versus-fax SPF distinction
If an approved requirement applies, edit the existing SPF TXT policy at the relevant owner, preserving all legitimate senders and its terminal qualifier. Do not publish another v=spf1 record. Validate the complete ten-lookup-term budget, including nested includes. SPF checks the envelope MAIL FROM domain, not necessarily the customer-facing From domain, so an include alone cannot force alignment. SPF identity and processing rules
If an existing SPF policy uses redirect=, preserve its intended authorizations and final semantics through a reviewed merge. Any all mechanism causes redirect to be ignored, so appending a canned policy or an all without reviewing that dependency can change which senders are authorized. SPF redirect semantics.
Avoid copying a temporary list of resolved service IP addresses into a permanent policy. That turns a vendor-managed authorization into a maintenance task without establishing that the correct envelope identity is being checked.
Keep DMARC policy changes separate
DMARC passes with either aligned, passing SPF or aligned, passing DKIM. Relaxed alignment compares organizational domains; strict alignment requires an exact match. Inspect the existing policy before diagnosing a subdomain mismatch. DMARC standard
For billing@example.com, the direct policy owner is _dmarc.example.com. For billing@mail.example.com, start with _dmarc.mail.example.com and check applicable parent inheritance. Preserve existing enforcement, reporting destinations, and alignment settings. An absent subdomain record does not justify overriding a parent’s protection with a weaker policy.
Only if no effective policy exists and monitoring is appropriate, a starting TXT example at _dmarc.example.com is v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com. Replace the address with an approved reporting destination; the relative DNS host in the example.com zone is _dmarc. External reporting may require authorization. Do not add a second policy. RFC 9989 supersedes RFC 7489 and removes pct, so new rollout plans should not rely on it. DMARC discovery and policy
Compare the Organizational Domain of the aggregate-report URI host with the Organizational Domain of the domain where the DMARC policy was found, not automatically the visible From domain. If they differ, the report-generating receiver must check the destination’s DNS authorization. A destination in the same Organizational Domain as that policy domain is excepted, even when its hostname differs. This protocol check does not replace the domain owner’s separate approval to share report data with that recipient. RFC 9990 section 4.
For the approved first policy at From example.com, full TXT owner _dmarc.example.com maps to _dmarc in that zone. For From news.example.com, full owner _dmarc.news.example.com maps to _dmarc.news in the parent example.com zone or _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve any existing direct or inherited policy; this mapping does not authorize a child monitoring override.
Verify DNS, then a delivered business message
Replace these uppercase placeholders with account-generated or observed values. The commands read records; they do not configure NetSuite:
dig +short CNAME FIRST_GENERATED_OWNER
dig +short CNAME SECOND_GENERATED_OWNER
dig +short TXT MESSAGE_SELECTOR._domainkey.MESSAGE_SIGNING_DOMAIN
dig +short TXT OBSERVED_MAIL_FROM_DOMAIN
dig +short TXT _dmarc.VISIBLE_FROM_DOMAIN
Both public CNAME answers should match NetSuite’s supplied targets. For active signing, query the selector from a newly delivered message rather than requiring both rotation targets to return a key simultaneously. DKIM uses the message’s s= selector and d= signing domain to locate its public key. DKIM lookup model
Send a representative invoice or other non-sensitive test business message to an external mailbox. Open its original headers and identify the receiver’s trusted Authentication-Results. Capture From, Return-Path, DKIM selector/domain, and SPF, DKIM, and DMARC outcomes. Do not trust arbitrary authentication claims injected earlier in the path. Receiver-result trust
Use receiver-controlled diagnostic output, or have the receiving administrator establish which fields were generated inside its known processing boundary and document how externally supplied Authentication-Results are removed or distinguished. A familiar authserv-id string or header position alone does not establish provenance. Ignore attacker-inserted or otherwise untrusted results, including a forged field naming the expected receiver. Operational receiving-boundary requirements.
Accept the route only when the intended From domain remains unchanged and visible, and the trusted receiver reports DKIM pass for the intended NetSuite signature: reconcile its observed d= and s= with the account-issued active signing key and require that signing domain to align with the intended From under the applicable alignment mode. Also require trusted dmarc=pass for that From. An unrelated added signature or an unnoticed provider-domain From rewrite is insufficient; the published standby alias does not need to sign the same message. Record SPF separately. Investigate unexpected SPF failures even when aligned DKIM allows DMARC to pass: check the observed envelope domain, sending IP, published policy, and any forwarding hop. A DKIM-based pass is not evidence that SPF is correctly configured. Then test replying, because authenticated delivery and correct reply routing are different business requirements.
Diagnose SPF at the actual smtp.mailfrom independently, even when aligned DKIM supplies DMARC pass. fail or softfail calls for checking whether the connecting sender is authorized for that envelope route; temperror indicates transient evaluation trouble such as a DNS timeout; permerror calls for checking malformed syntax, duplicate policies and the evaluated DNS-term budget. A passing but unaligned SPF identity is a separate condition. SPF result meanings.
Diagnose sender rewriting before changing policy
Without completed DKIM setup, NetSuite can rewrite the From address to system@sent-via.netsuite.com, moving the original address into the display text. A receiver may authenticate that NetSuite address successfully without proving authentication of your intended branded From domain. Inspect the actual address, not just the displayed name. Oracle’s From-rewriting explanation
If rewriting persists, check the exact sending subdomain, account, published CNAME pair, and current Status/Details. Save a fresh message rather than rechecking one sent before configuration completed.
If only one business process fails, compare its identity and route with a passing process. If all messages pass authentication but remain filtered, investigate the rejection response, recipient policy, reputation, and content. Do not relax DMARC as a substitute for finding the cause.