OneTrust SPF, DKIM and DMARC setup, step by step

For OneTrust notification emails, choose the delivery method first. Send on Behalf of my Domain uses DNS records generated in your account; publish those records, verify the domain, and confirm that notification rules or the default account actually select it. Custom SMTP Relay and Microsoft Exchange Online use your mail infrastructure instead. There is no single OneTrust SPF include that configures all four methods.

This guide covers platform notification email settings, not every independently configured OneTrust integration. No customer account, DNS or real-message delivery was tested.

Check licensing, permissions and delivery ownership

Email Settings require a Site Admin in the parent organization. OneTrust asks customers to contact Support when adding or updating email domains. Its current options table lists the default method for all licenses and the three customized methods for Advanced and Enterprise. Email server setup options.

The default sender is noreply@m.onetrust.com. OneTrust does not publish the cloud delivery IPs for customer safelisting; its overview recommends SMTP or Exchange when that control is needed. Do not confuse application egress IPs reaching your relay with the final outbound mail servers that SPF evaluates. OneTrust email settings.

Before implementation, list the notifications, organizations, brands and countries that use each account. Assign an application owner to check routing rules, a DNS owner to publish records, and a mail owner to examine receiver results. This prevents a correctly authenticated but unused account from being signed off as a completed migration.

Configure Send on Behalf of my Domain

In Global Settings, open Email and branding > Email settings. On Accounts, add a Send on behalf account with its account name, domain, sender name and sender email. Save and next exposes the generated Cnames section. Publish the listed DNS records, then select Verify domain and require Verified rather than Pending Verification. Do not replace an established DMARC policy with the optional generated suggestion. Send-on-behalf configuration.

OneTrust's workflow delegates authentication through generated DNS values. A CNAME used for the SPF/bounce identity is not a TXT include to paste into your apex policy. Follow the current record set instead of manually constructing a record from the vendor's brand or underlying delivery platform. Keep each generated hostname connected to its purpose in your change request.

After verification, select the intended default account or routing rules. To change the fallback in Email settings, hover over the account, open its context menu, choose Set as default, select the account in Current default, and save. Review other workflows affected before changing that shared default. Notifications that match no rule use the default. Changing a send-on-behalf domain requires a new configuration rather than simply editing its domain field, so plan replacement and rollback before removing a working account. Account selection and domain changes.

Configure a customer SMTP route separately

OneTrust's SMTP workflow is Accounts > Add > SMTP. Enter the approved relay details, test the connection, create the account and configure routing rules. The relay must have sufficient sending capacity. Choose failure-alert recipients deliberately; the documentation describes the root organization's Site Admins as the fallback when none are selected. Custom SMTP email accounts.

Use the mail team's approved encrypted transport and credential-handling process. OneTrust lists cloud SMTP ports 587 or 465 and a Security Protocol setting; do not interpret the port number or the native statement that 587 need not use TLS as permission to send credentials or messages unencrypted. Require the relay owner’s supported encrypted configuration. Do not paste credentials into DNS or a public ticket. A successful connection test cannot prove that the relay signs with your From domain or that the downstream recipient accepts the message. Configure signing on the final outbound mail service, then inspect a notification sent through OneTrust, not merely a message sent directly from a user mailbox on that service.

For Microsoft Exchange Online, follow OneTrust's separate administrator-managed Microsoft Exchange email account configuration, which recommends modern authentication. This connection is distinct from send-on-behalf DNS delegation. Application registration, Mail.Send permission/admin consent, secret storage and mailbox access scoping belong to the authorized Microsoft administrator’s separate security change, not a DNS shortcut. Confirm current Microsoft guidance before applying the native page’s Azure AD-era examples; never broaden mailbox access just to pass a test. The mail administrator must still configure and verify Microsoft-side SPF/DKIM for the intended domain, and acceptance must use an actual OneTrust notification through that Exchange account. A successful connection alone does not establish aligned signing or the correct notification route.

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, use the applicable HELO identity. Query that 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 causes redirect= to be ignored and later mechanisms to be unreachable. Preserve an intentional redirect-only policy’s control flow while merging authorization. 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 signing domain notices.example.com, full owner selector._domainkey.notices.example.com is relative selector._domainkey.notices in parent zone example.com, or selector._domainkey inside delegated notices.example.com. If _domainkey.notices.example.com is itself delegated, use selector there. Preserve legitimate NS delegation and publish at its authority. The selector is illustrative; use the issued value.

In Cloudflare, keep required literal aliases DNS only, not Proxied, and turn per-record Flatten off where available. Whole-zone flatten-all must not suppress the aliases; coordinate effects on other services before switching shared behavior off. Per-record settings do not override flatten-all. Apex flattening is mandatory and same-zone targets can flatten regardless of settings. If an issued literal CNAME cannot remain visible safely, stop and ask OneTrust for a supported alternative owner/configuration rather than moving nameservers or deleting unrelated records. 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

For the example child domain, use relative _dmarc.notices in parent zone example.com, or _dmarc inside delegated notices.example.com. Replace both example domains before use. 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. Obtain owner approval for the aggregate-report recipient and data sharing separately from DNS authorization. If the destination has a different Organizational Domain from the policy domain, the report-generating receiver must check DNS external-destination authorization before sending reports. A destination within the same Organizational Domain is the exception. An rua address alone does not provide authorization, and a last-two-label guess is not a reliable Organizational Domain determination. External reporting authorization. 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. Concatenate component strings within a single logical public-key TXT record without added spaces; do not create independent key records for fragments. 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 receiving service’s processing boundary from its documentation or administrator-confirmed mail path, including how externally supplied Authentication-Results fields are stripped or isolated/distinguished. Ignore untrusted fields; an authserv-id string or topmost position alone is forgeable. If handling is uncertain, use receiver-controlled logs or message traces and obtain receiver-administrator confirmation before accepting results. 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. A passing intended signature d=mail.example.com with visible From alerts@example.com aligns under relaxed mode when both share the same Organizational Domain, but not strict adkim=s; passing d=example.com aligns under 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 distinguishing a raw signature verdict from policy alignment, see raw DKIM results versus aligned DKIM policy results.

Verify account selection as well as authentication

Test one notification that matches each important routing rule and one controlled fallback notification. Keep recipient data synthetic where possible. Record the expected account, actual From address, return-path domain, signing domain and trusted receiver result. A brand-specific notification should not quietly leave through an unrelated default account even if the resulting message passes DMARC for that default sender.

A pass from the default m.onetrust.com identity does not validate your custom domain. Conversely, an authentication pass does not establish that the right sender branding or data-subject reply process is in use. Include the application owner in acceptance, not only the DNS team.

Troubleshoot OneTrust notification mail

Do not use a real data-subject request or expose case details just to test mail. Keep production and test environments separate in the evidence. Before reusing one domain across Send on Behalf and a customer SMTP/SendGrid route, stop and have OneTrust confirm the supported coexistence or migration plan for that tenant. This is a route-specific compatibility check, not a universal DNS prohibition on multiple legitimate senders.

If verification fails, preserve the generated records and exact error for Support. If replacing a route, keep the old authorized configuration available until the new rule and fallback tests pass. Do not delete a working account just to clear a transient DNS-verification error. OneTrust explicitly warns that deleting an SMTP configuration removes emails stuck in its queue. Troubleshoot first and agree how queued notifications will be retained, retried or deliberately abandoned before any replacement. Custom email server FAQ.