[ Sending-service guides ]

Plan Responsys branded-domain delegation and verify authentication

Protect existing DNS services during Responsys branding, then require account-specific authentication records and received-message evidence.

By the EmailAuth research team · 5 min read

[ Key points ]

  • Protect existing DNS services during Responsys branding, then require account-specific authentication records and received-message evidence.
  • A branded-domain conversion does not prove aligned authentication.
On this page

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.

[ Takeaway ]

A branded-domain conversion does not prove aligned authentication.

[ By role ]

What this means for you

Choose your role for practical next steps.

IT / Mail Admin

Validate the actual route

Confirm who is authoritative before publishing authentication records.

Next steps

  1. Record the product, environment and sending identity.
  2. Verify public DNS and a fresh receiver message.
  3. Retain exact settings and a rollback decision.

CISO / SecOps

Approve evidence rather than branding

Brand conversion is not a substitute for signing and alignment evidence.

Next steps

  1. Review authentication and alignment separately.
  2. Limit access and redact message content in evidence.
  3. Keep human SME approval and publication pending.

Founder / Non-technical

Protect the business workflow

Delegation can affect marketing links, replies and existing services.

Next steps

  1. Name the business owner and critical messages.
  2. Approve a controlled pilot before expanding traffic.
  3. Keep a usable recovery route and escalation contact.

[ FAQs ]

Frequently asked questions

Does this article provide a Responsys DKIM selector?

No. The retrieved branding guide does not provide a universal signing configuration.

Can I delegate the main company domain casually?

No. Inventory all dependencies and use a dedicated approved boundary; Oracle warns about full-domain traffic implications.

Where do the nameserver values come from?

The actual account’s supported branded-domain conversion workflow, not a generic example.

What if NS delegation is not possible?

Obtain a supported account-specific alternative from Oracle Support.

Can I add DKIM in the parent zone after delegation?

First establish DNS authority. Records beneath a delegated zone normally need to be served by its authoritative nameservers.

Does the conversion email prove DMARC passes?

No. Test a received campaign and inspect the authenticated domains and their alignment.

Do working tracked links prove email authentication?

No. Link, reply and authentication tests are distinct.

Is the original configuration topic fully covered?

No. Exact SPF and DKIM issuance and activation remain a scope hold, along with all live verification and human approval gates.

[ Sources ]

Sources

  1. Responsys converting to a branded domain

    Sections Converting to a Branded Domain

  2. RFC 7208 Sender Policy Framework

    Sections §3.2 Multiple DNS records · §4.6.4 DNS lookup limits

  3. RFC 6376 DomainKeys Identified Mail

    Sections §3.5 DKIM-Signature header field · §6 Verifier actions

  4. RFC 9989 Domain-based Message Authentication Reporting and Conformance

    Sections §4.4 · §5.3.5 · §7.4

[ Glossary ]

Glossary

Visible From
The author address shown in the message From header.
Envelope sender
The SMTP sender identity normally represented by Return-Path after delivery.
DKIM selector
The s= value used with the signing domain to locate a public key in DNS.
Alignment
The relationship between an authenticated domain and the visible From domain required by DMARC.

Enterprise provenance

Why top financial institutions and governments retired their email security dashboards.

Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.

EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard,, with human-in-the-loop auditability.

Governments Large enterprises Tier-1 financial institutions

SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption

Knowledge Base