NICE inContact SPF, DKIM and DMARC setup, step by step

Authenticate NICE CXone ACD email on the route it actually uses: verified hosted domains use Amazon SES, unverified domains use a separate legacy system, and a customer-managed SMTP server is a distinct route. For hosted email, verify each sending domain and publish the DKIM CNAMEs downloaded from CXone. Do not apply a universal include:incontact.com recipe to every CXone product.

This guide covers ACD channel mail formerly associated with NICE inContact. Digital Experience, system notifications and integrated-product mail need their own route checks.

Choose the delivery route before editing DNS

NICE documents these separate traffic classes and supplies regional SPF instructions specifically for unverified email-channel domains. Its receiving allowlist is not the same list as outbound SPF authorization. CXone System Email.

For example, allowing a password-reset source through your inbound filter does not authenticate an agent's reply as your domain. Do not copy every IP in a networking table into SPF. Confirm the tenant region and the applicable SPF section, and merge only the authorized source terms into the actual envelope-domain policy. Prefer completing the supported hosted-domain verification rather than assuming legacy infrastructure will remain unchanged.

Prepare permissions and the operational test

You need DNS administration for each sender domain and a CXone administrator with Skills Edit permission for domain verification. Skill creation or modification requires ACD Skills Create/Edit as applicable. Confirm the real inbound or outbound email skill, its configured From address, and which agents can use it. The ACD setup documentation explicitly directs Digital Experience users to a separate workflow. Set Up Email.

Record the skill and test type before changing DNS: an agent response to an inbound contact and a newly initiated outbound message may exercise different configurations. Keep screenshots of status and a record of DNS changes, but avoid storing customer conversations in a broad-access troubleshooting folder.

Verify the hosted domain and activate DKIM

In ACD, open Contact Settings > Email Domains. For each domain, use Verify: Initiate to obtain its verification key, then publish the issued TXT at _amazonses.<your-domain>. Return to the domain-verification result. Separately use Action: Initiate, download the Dkim Tokens (CNAME) CSV, and publish every generated pair. Check DKIM status after DNS propagation; NICE allows up to 48 hours and directs administrators to correct failed records before reinitiating. Domain verification and DKIM workflow.

Publish the verification token as an actual DNS TXT record; saving a local text file does not update DNS. The native instructions describe removing _amazonses when a DNS host rejects underscores and optionally adding amazonses: to the token. Do not silently apply those alternate forms: confirm the exact supported owner/value with NICE and your DNS administrator before changing the tenant-issued data. The verification TXT is not an SPF record and does not sign messages. Domain verification success is also separate from whether a skill actively uses the domain. Do not resolve a missing skill by repeatedly replacing good DNS records. If the DNS host cannot represent an issued owner, involve its administrator and NICE before adapting it; never silently rename a DKIM selector.

For custom SMTP, NICE documents the option through the account representative in the Americas, EMEA and APAC. Follow the selected relay's own SPF/DKIM instructions and test the final outbound hop. Publishing CXone hosted-DKIM records is not proof that the customer relay uses them. ACD email and custom SMTP scope.

Preserve SPF and DNS safely

SPF checks the SMTP envelope MAIL FROM domain, usually visible in the delivered Return-Path, not the display name or visible From address. For a null reverse-path, the applicable SPF identity is HELO. Query the actual evaluated hostname. SPF identities. SPF does not inherit from a parent domain. A valid policy at example.com says nothing about SPF at bounce.example.com. Keep one SPF TXT record at each owner, preserve other authorized senders, and leave unrelated TXT records intact. Multiple quoted strings within one TXT record are different from multiple competing SPF records.

Before adding authorization, evaluate the complete SPF path. The limit is ten evaluated DNS-querying terms, including recursive include and redirect processing; a, mx, ptr, and exists also count. It is not a budget of ten visible includes. ip4 and ip6 do not consume that term budget. Preserve the existing final qualifier unless the domain owner separately approves changing it. Do not use +all, remove another sender, or flatten changing provider IPs manually to make a checker green. SPF requirements, RFC 7208.

An all mechanism always matches, making later mechanisms unreachable and causing redirect= to be ignored. Preserve intentional redirect control flow when merging authorization rather than silently disabling it. SPF all and redirect.

For each issued CNAME, compare the complete owner and target against the account's instructions. Some DNS panels append the zone automatically: entering a full owner in a relative-name field can produce selector._domainkey.example.com.example.com. For a child signing domain notices.example.com, full owner selector._domainkey.notices.example.com maps to selector._domainkey.notices inside parent zone example.com, or selector._domainkey inside delegated zone notices.example.com. If _domainkey.notices.example.com is separately delegated, use selector inside that zone. Likewise _amazonses.notices.example.com maps to _amazonses.notices in the parent or _amazonses in the delegated child. Preserve NS authority and exact issued tokens; these illustrative selectors are not generated values.

In Cloudflare, set every required literal CNAME to DNS only, not Proxied, and turn its per-record Flatten option off where available. Applicable whole-zone flatten-all must not suppress the aliases; coordinate other affected services before turning shared behavior off. Per-record settings cannot override whole-zone flatten-all. Apex flattening is mandatory and same-zone targets may flatten regardless of settings. If literal issued aliases cannot remain visible safely, stop and request a supported alternate configuration from NICE rather than moving nameservers, deleting another service or disabling security controls. Cloudflare flattening controls, CNAME verification behavior. A CNAME owner cannot also hold unrelated TXT, MX, or another CNAME target. Resolve a conflict with the provider rather than deleting an existing service's records. Never publish a private signing key.

Keep the existing DMARC policy

DMARC requires either a passing, aligned SPF identity or a passing, aligned DKIM signature. DKIM alignment compares the signature's d= domain with the visible From domain; SPF alignment compares the authenticated MAIL FROM domain. Relaxed alignment uses the same organizational domain, determined under the applicable DMARC discovery rules. Strict adkim=s or aspf=s requires an exact domain match. A valid provider-domain signature is not automatically aligned with your organization. DMARC, RFC 9989.

Check _dmarc at the visible From domain and the applicable parent policy before changing anything. An absent subdomain record does not establish that there is no policy. Retain established policy, reporting destinations and alignment settings, including inherited protection. Do not add p=none below an enforced parent merely to make this sender work.

Only if there is no established applicable policy and the domain owner approves a monitored first deployment, a concrete example for the hypothetical From domain notices.example.com is:

Owner: _dmarc.notices.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Inside parent zone example.com, the example’s relative owner is _dmarc.notices; inside separately delegated notices.example.com, it is _dmarc. Replace both example domains before use. Obtain the domain owner’s approval for the aggregate-report recipient and the data shared, separately from protocol DNS authorization. Create and monitor the reporting mailbox first, assign an owner to review aggregate reports, and keep exactly one DMARC record at this owner. The record requests observation rather than quarantine or rejection; it does not repair authentication. When the report destination is in a different Organizational Domain from the policy domain, the receiving report generator must check DNS external-destination authorization before transmitting reports. A destination within the same Organizational Domain is the exception. Arrange the required authorization with the report service; an rua address alone does not supply it. Use the actual Organizational Domain determination, not a last-two-label guess. External reporting authorization, RFC 9990 §4. Inventory other senders and review representative reporting cycles before considering stronger policy. The obsolete pct tag is not a current percentage-rollout mechanism. Aggregate reporting is specified by RFC 9990; failure reports can reveal personal message data, so do not add ruf without a deliberate privacy review.

Validate DNS and a real delivered message

These are read-only examples, not completed tests. Substitute the actual MAIL FROM domain, generated selector, signing domain and From domain. Query every generated owner, not only the first one.

dig +short TXT envelope.example.com
dig +short CNAME selector._domainkey.notices.example.com
dig +short TXT selector._domainkey.notices.example.com
dig +short TXT _dmarc.notices.example.com

The SPF answer must correspond to the actual envelope identity. A DKIM CNAME must match the issued target, which must resolve to a usable public key. A TXT query may show the alias and the final TXT answer. Compare an authoritative nameserver with an independent recursive resolver; old cached answers can persist until their TTL expires. When a public-key TXT answer contains multiple component strings, concatenate them without adding spaces; they form one logical record, not separate key records. DKIM TXT syntax. DNS existence alone does not prove that a service signs mail.

At a trusted recipient, open the newly delivered message's original headers. Use the receiving system's own Authentication-Results, not an arbitrary upstream or sender-supplied copy. Establish the actual receiving service’s processing boundary from its documentation or administrator-confirmed mail path, including its treatment of forged incoming result fields. An authserv-id string or topmost position alone does not establish trust. If the boundary is unknown, ask the receiver administrator before accepting a verdict. Record visible From, smtp.mailfrom, header.d, DKIM s= selector, and SPF/DKIM/DMARC results. For a custom-domain DKIM rollout, require the intended branded signature to show dkim=pass, its signing domain to align with the expected From under the applicable policy, and the trusted receiver to report dmarc=pass. The protocol permits either aligned SPF or aligned DKIM, but an SPF-carried DMARC pass does not prove that the DKIM setup you just changed works. Provider-owned default senders are a separate baseline, not evidence of custom-domain readiness. Investigate delivery disposition separately. Authentication passing cannot guarantee inbox placement. Authentication-Results trust boundary, RFC 8601.

For example, spf=pass for an unrelated provider bounce domain plus dkim=pass with header.d=notices.example.com can supply DMARC through DKIM for From: alerts@notices.example.com. In contrast, a passing intended signature d=mail.example.com with visible From support@example.com aligns only in relaxed mode when both share the same Organizational Domain; it fails strict adkim=s. Passing d=example.com aligns in both modes. A rewritten provider From is not acceptance of the intended custom identity. DKIM alignment. If neither passing identity aligns, adding a DMARC record cannot turn failure into a pass. Retest after every repair and retain a redacted evidence record with date, route and receiver result.

Investigate an actual SPF fail, permerror or temperror even when aligned DKIM makes DMARC pass. Compare the actual envelope identity, sending IP and authoritative policy; correct unauthorized-route, syntax/lookup-limit or transient DNS causes as appropriate, then retest the same route. Distinguish those failures from spf=pass for a valid but unaligned provider envelope domain.

For interpreting the signing result separately from alignment, see raw DKIM results versus aligned DKIM policy results.

Run a contact-center acceptance test

After both hosted-domain checks succeed, send through the actual approved skill. Test an inbound reply and a new outbound interaction where both are used. Confirm the chosen From domain in each received message, not just the domain row in the administration screen. Include a controlled external receiver so an internal bypass does not hide authentication failures.

Preserve the last approved record set and channel configuration with a named recovery owner. Coordinate rollback with the contact-center team so active signing and DNS do not diverge; leave inbound MX and unrelated skills alone.

Record whether SPF aligned, DKIM aligned, or both supplied the DMARC pass. If SES uses its own envelope identity, a valid SPF result can remain unaligned; check the aligned custom DKIM signature rather than adding Amazon-wide authorizations to your apex. Do not claim a custom return-path is configured unless the tenant and delivered headers establish it.

Troubleshoot CXone email authentication