Source review dated 8 November 2026. This is documentary guidance; account, DNS and received-message acceptance tests below have not been executed.
Choose the notification route before changing DNS
OneTrust email authentication begins with the email account selected for a notification. The platform can deliver through its default cloud configuration, Send on Behalf of my Domain, a custom SMTP relay or Microsoft Exchange Online. These routes do not have interchangeable DNS instructions. The first task is to identify the parent organization, environment, notification workflow, account and routing rule involved. Keep production and test environments distinct so that a successful test in one does not become evidence for the other.
The provider's Email Server Settings article describes the default configuration and lists the alternative methods, with license differences. It limits Email Settings access to Site Admin users in the parent organization and directs customers to support for assistance with email domains. Confirm the methods actually available in the tenant before planning the change. This guide gives a documentary procedure for Send on Behalf and route-aware checks for the alternatives; it does not establish that every tenant has the same entitlement or interface. OneTrust email server options
A custom platform login address or branded web form does not prove that outbound messages use a custom authenticated domain. Record those separately. The visible sender name is also independent from the sender address domain. Decide which identity users and data subjects should recognize, which team owns replies, and who may approve changes affecting notification delivery.
Separate cloud delivery from a customer relay
With the default cloud route, OneTrust operates the sending infrastructure and describes automated SPF and DKIM management. Do not add a guessed OneTrust SPF include to the organization's domain merely because the application sends notifications. First inspect whether that domain is even the visible From or evaluated envelope identity for the route. OneTrust email server options
Send on Behalf allows OneTrust's delivery service to use an approved organizational identity through domain authentication. Custom SMTP instead hands mail to the customer's configured server. For that route, the relay administrator must establish the final envelope, DKIM signer and supported sender authorization. The application authenticating to SMTP and the destination mailbox validating DKIM are different events. A successful SMTP connection test establishes neither final delivery nor DMARC alignment.
If the organization requires IP-based restrictions, ask the network team and OneTrust to confirm the supported configuration for the selected route. Do not translate a cloud service's shared delivery infrastructure into a permanent IP list from incidental message headers. Avoid broad recipient allowlisting as the first response to an authentication failure. It can hide the symptom without correcting the sender identity.
Configure Send on Behalf using the current account record set
The current English first-party article describes Global Settings, then Email and branding, Email settings, Accounts and Add. Select Send on behalf and enter the account name, authentication domain, sender name and sender email. Save and next exposes a Cnames section containing the records for that configuration. Use the records issued there rather than a public example or a different tenant's setup. Configure Send on Behalf of my Domain
Before saving the account, agree which domain will be authenticated and who owns its DNS. Record the intended From domain alongside the authentication domain so any mismatch is reviewed rather than assumed acceptable. Capture the issued record owners, types and targets without exposing credentials or unrelated tenant information. Keep the complete prior record sets and the approved change scope. The account label should make its environment and business purpose clear to future administrators.
Publish at the authoritative DNS host. For each record, distinguish the fully qualified owner from the editor's relative Host entry. Check for conflicting records at DKIM selectors and do not overwrite another sender's active key. A CNAME delegates a lookup; it is not a place to paste a private signing key. Preserve one valid SPF policy at an evaluated owner when TXT changes are required, including other authorized senders and recursive lookup limits. DKIM RFC 6376 SPF RFC 7208
The provider notes that the displayed DMARC TXT record is optional when a policy is already set. Inspect the actual policy and keep its approved reporting destinations, enforcement and alignment settings. Do not create a second policy merely to satisfy a copied checklist. After DNS publication, use Verify domain and preserve its result. The documented account transition from Pending Verification to Verified is one checkpoint, not the end-to-end acceptance test. Send on Behalf configuration
Verify rule selection and the default account
A verified account can remain unused. Determine which notification rules select it and what happens when no rule matches. OneTrust documents a default account for that fallback case. Review the current default before changing it because the effect can extend beyond the one workflow being tested. An account change intended for one program should not silently alter notifications for other teams.
Build a small test matrix covering a rule match, a fallback notification and any separately configured workflow that must use a different account. Use synthetic content and controlled recipients. Record the trigger and expected account before sending so the observed From address is compared with a prior expectation. Do not use a real data-subject request merely to exercise authentication. A transport test should not expose case details or create accidental commitments to recipients.
The Send on Behalf guide also distinguishes editable sender fields from the authentication domain: changing that domain requires a new configuration under its documented procedure. Plan any domain replacement as a migration with account-selection review, not a cosmetic rename. Confirm the disposition of pending notifications with support before removing a configuration.
Diagnose transport failures without deleting queued mail
For custom SMTP, collect the connection result, timestamp, account state and precise server response. Ask the relay owner to check credential validity, supported authentication, reachability and permitted sender identities through approved tools. Keep secrets out of screenshots, worksheets and support excerpts. Do not rotate credentials as an undocumented experiment while other production clients depend on them.
OneTrust's Custom Email Server Configuration FAQ warns that deleting an SMTP configuration can remove emails stuck in its queue. Preserve the configuration and investigate first. If deletion or replacement becomes necessary, obtain a reviewed plan for queued messages, duplicates and recovery. An administrator should know whether messages will be retried, regenerated or deliberately abandoned before any destructive step. OneTrust custom email server FAQ
Classify failures by stage. A connection failure precedes recipient authentication checks. A domain verification failure points to account-specific DNS or publication. A received message with passing SPF but failing DMARC requires identity comparison. A bounced message may instead reflect recipient state or local policy. Changing DNS is useful only when the evidence identifies DNS or sender authentication as the cause.
Reusable OneTrust account worksheet
Complete one copy per route and environment. A missing entitlement or inaccessible tenant is a hold, not a reason to infer settings from screenshots in documentation.
- Tenant environment, parent organization and responsible Site Admin: ______.
- Notification workflow, trigger and controlled recipient: ______.
- Delivery methodology and verified entitlement: ______.
- Selected email account, matching rule and fallback default: ______.
- Intended visible From, reply destination and authentication domain: ______.
- Tenant-issued DNS records, issue date and DNS administrator: ______.
- Existing SPF and DMARC policies and approved changes: ______.
- Authoritative publication evidence and Verify domain result: ______.
- SMTP or Exchange handoff owner, if applicable: ______.
- Independent received-message reference, envelope, DKIM d=/s= and trusted results: ______.
- Queue-preservation decision, rollback account and retest owner: ______.
- Tenant walkthrough, visual review and human SME acceptance: pending.
Fictional diagnosis of a verified but unused account
This scenario is fictional. A privacy team creates a Send on Behalf account and receives a Verified status. Its test notification still arrives with the platform's default sender. The administrator concludes that DKIM is not working and proposes replacing the domain's DMARC policy.
The proposed investigation first checks the rule that selected the account. In this fictional case, the test notification did not match the intended rule and used the existing default. The message can authenticate correctly for that default identity while failing the team's branding expectation. The corrective plan is to review routing, test the approved account selection, then inspect the received message. No policy replacement is justified by that observation. This example demonstrates a diagnostic sequence, not an observed OneTrust tenant result.
Record both authentication and workflow acceptance
For each controlled received message, retain the visible From, SMTP envelope, every DKIM signing domain and selector, and the trusted receiving system's authentication results. DMARC needs a passing authentication path aligned with the From domain; account verification alone cannot establish that relationship. Use the actual policy's alignment mode when interpreting the result. DMARC RFC 9989
Close the change only after the expected notifications use the intended account and the real message evidence supports acceptance. Record separate outcomes for delivery, authentication and recipient-facing sender identity. This article has not accessed a customer tenant, published DNS, sent test notifications or inspected live screenshots. Tenant availability, issued values, live DNS and received-message evidence, visual review and human approval remain pending.
Avoid a same-domain route conflict
OneTrust’s Send on Behalf guidance says not to configure the same domain simultaneously through a customer email server and SendGrid. For the domain in scope, confirm whether the selected OneTrust route is Send on Behalf or Custom SMTP before changing authentication. This is a OneTrust-specific configuration constraint, not a general prohibition on multiple legitimate senders. OneTrust Send on Behalf guidance.