Separate Responsys branding from authentication evidence
Responsys domain branding affects more than the display of a From address. Oracle's public conversion guide describes a branded domain used for sender addresses, hosted replies and link-related functions. It requires an account-enabled feature and a domain or subdomain unused by other entities because Responsys manages its traffic. See Responsys converting to a branded domain.
This article covers delegation planning and authentication verification for that documented route. The retrieved guide does not establish a universal Responsys SPF include, tenant DKIM selector or complete key-activation procedure. Those configuration details remain a scope hold pending current account-specific first-party instructions. Do not fill the gap with OCI Email Delivery records or a competitor's recipe.
Choose a delegation boundary that protects existing services
Inventory the proposed domain before approval. Identify existing websites, mailboxes, MX records, application callbacks, verification records and other service dependencies beneath it. Prefer a deliberately allocated marketing subdomain when that matches the organization's design, rather than casually transferring the main corporate domain.
Oracle's guide directs customers to delegate the chosen subdomain to nameservers shown in the account's conversion dialog. It warns that full-domain use must be dedicated rather than the main company domain. See Responsys converting to a branded domain. Treat delegation as an operational handover of authority for that DNS subtree, not as an isolated email TXT-record addition.
Agree who owns incidents after delegation. The corporate DNS team still controls the parent delegation, while the delegated authority supplies records within the child zone. Record how to contact both teams and how to recover without breaking active marketing links or reply handling.
Capture the actual account conversion instructions
Inspect the supported Brand management workflow in the correct Responsys account. Record the intended brand and the exact nameserver values supplied by the account. Do not submit the conversion while still collecting information. Review the proposed change, business impact, notification address and recovery conditions with the authorized owners first.
If the standard delegation method cannot be used, Oracle directs customers to support rather than presenting a generic replacement record set. See Responsys converting to a branded domain. Obtain a first-party supported alternative for that account. A web article describing another customer's record layout is not sufficient authority to alter the zone.
Require explicit authentication outputs
Ask the Responsys owner or verified support to identify the expected envelope domain, DKIM signing domain and selector, how signing is activated, and who maintains SPF and DKIM records after delegation. Also identify the correct DMARC policy location for the intended visible From domain. Do not publish duplicate or conflicting records in the parent zone in an attempt to override records controlled by the delegated zone.
SPF authorizes the relevant SMTP identity; DKIM binds a verified signature to a signing domain; DMARC requires an aligned passing mechanism for the visible From domain. See RFC 7208 Sender Policy Framework, RFC 6376 DomainKeys Identified Mail and RFC 9989 Domain-based Message Authentication Reporting and Conformance. These standards explain what to test but do not prove what a particular Responsys account currently supports.
Verify authority and a controlled campaign
First trace the public DNS delegation and confirm which nameservers are authoritative for the chosen subdomain. Then examine the issued authentication records at the appropriate names. Retain the source of each value and an observation timestamp. Do not mark authentication complete merely because the brand conversion notification arrived.
Send a small controlled campaign from the intended brand. Capture the delivered From, envelope identity, DKIM d= and s=, and the receiver's SPF, DKIM and DMARC results. Verify reply handling and tracked-link destinations as separate functional tests. A link that opens correctly does not establish aligned DKIM, and a signed message does not prove replies reach the intended team.
Responsys delegation and authentication worksheet
- Account and brand: ____; proposed dedicated domain or subdomain: ____.
- Existing web, email and application dependencies checked: ____; business approval: ____.
- Nameserver values from this account: ____; parent-zone change owner: ____.
- Delegated-zone authority observation and timestamp: ____; conversion confirmation: ____.
- Supported authentication instructions and activation owner: ____.
- Expected envelope identity: ____; DKIM d= and selector: ____; policy owner: ____.
- Controlled campaign Message-ID and receiver: ____; authentication results: ____.
- Aligned mechanism: ____; reply handling: ____; link checks: ____.
- Recovery dependencies, unresolved records and release decision: ____.
Leave the authentication instruction field unresolved if no first-party account evidence exists. Delegation readiness and authentication readiness are different acceptance decisions.
Fictional diagnosis of a parent-zone record mistake
Fictional example only: Harbor Retail delegates news.example to its Responsys account, then adds a guessed DKIM TXT record under news.example in the parent DNS interface. The record appears in the interface but is not returned by the nameservers authoritative for the delegated subdomain. A campaign test still lacks the intended verified signing identity.
The team traces authority, removes the unsupported assumption from its plan and asks the responsible operator for the actual issued record and activation workflow. It tests a new campaign only after those requirements are resolved. No Harbor Retail account or DNS zone was inspected.
Hold release until the route is evidenced
Approve the domain handover only with the dependencies and recovery plan understood. Approve authentication only after account-specific instructions, authoritative records and received-message evidence agree. Preserve the distinction in the change record so a branded account cannot be mistaken for a verified sending domain.
Full Responsys SPF and DKIM configuration remains held because the retrieved branding guide does not supply the missing authentication procedure. Live account inspection, delegated DNS, message testing, human visual inspection, SME approval and publication are all pending.
Set a separate change decision for each brand
The branding guide documents up to five branded domains and a one-time conversion after account creation. Confirm account applicability before committing a brand change. Conversion, reply handling, tracked links and authentication each need their own acceptance evidence; a passing link test must not close a missing DKIM configuration task.
Separate message acceptance from policy rollout
A passing aligned SPF result can satisfy a message evaluation, but does not alone justify moving an entire domain to reject. RFC 9989 Section 7.4 requires valid DKIM for domains publishing p=reject and warns about indirect-mail interoperability. Inventory all legitimate senders and indirect routes before the policy owner approves enforcement. No DNS change, tenant operation or received-message test was executed for this article.