Choose the Dotdigital sending route before touching DNS
Dotdigital authentication should be scoped to the exact product and sending identity. This guide concerns custom from addresses, or CFAs, in Dotdigital Marketing. It does not establish equivalent settings for every connected application, another Dotdigital product or an account whose feature access has not been checked. Start with the business flow, the proposed From address and the person responsible for its domain.
The provider's current branded-domain guidance describes NS-delegated and self-hosted approaches. It requires a dedicated new subdomain or lookalike domain and does not support using a CFA concurrently in another platform. That makes domain selection an architectural decision, not a cosmetic rename of a campaign address.
Inventory any existing use before approving the proposed name. Ask whether it carries transactional messages, bounce handling, tracking links or an older campaign archive. A proposed migration can affect more than the next message. Keep each dependency's owner and acceptable transition condition visible instead of assuming that all services using a similar domain belong to the same workflow.
Decide who will manage the sending DNS
Creating a CFA includes using an owned subdomain, purchasing a sending domain or adding an alias to an existing sending domain. The documented subdomain option requires a DNS provider that permits the necessary delegation. A purchase or account charge is a separate approval decision; this manuscript makes neither one.
For the hosting choice, preserve the provider's DNSSEC qualification. Its branded-domain page says that a parent using DNSSEC must use the self-hosted approach rather than delegating the subdomain to Dotdigital Marketing. Do not turn this compatibility constraint into advice to weaken the parent's security. Confirm the organization's intended arrangement with the domain owner and the actual product support scope.
An internal handoff should specify who maintains each record after setup. A delegated zone and a self-hosted zone have different change responsibilities. The useful deliverable is a responsibility boundary and recovery contact, not an assumption that a green status removes the need for future ownership.
Follow the self-hosted verification sequence precisely
For a self-hosted CFA, the verification guide requires the address to exist in Marketing first. The documented path is Account menu, Settings, Email, From addresses, then Verify for the chosen address. That view supplies the DNS records for the sending domain. Values must come from that account rather than from an example in this article.
After the approved records are published, the documented workflow returns to Verify and then includes a confirmation step. Read the displayed acknowledgement and obtain any required approval before accepting it. The source says CAA records are optional and excluded from that verification check; a successful status therefore should not be described as exhaustive DNS validation.
When verification fails, preserve the exact error and compare the expected record set with what is published. The provider lists missing records, additional MX or A records and formatting issues among its checks. Do not respond by deleting every unfamiliar record. First establish whether the proposed sending domain was genuinely dedicated and whether an unexpected record supports an active dependency.
Distinguish provider verification from aligned mail
Provider verification and a receiver's DMARC evaluation answer different questions. The first concerns the service's expected setup; the second concerns an actual message and its authenticated identities. RFC 9989 section 4.4 supplies the alignment framework. Keep the visible From domain, authenticated SPF identity and every relevant DKIM signing domain separate until the relationship is established.
A passing DKIM signature does not necessarily identify the author-domain owner. RFC 6376 sections 1.2 and 3.5 distinguish the signing identity and signature fields. Inspect the actual d and s values and the trusted receiver's result rather than translating a branded display name into evidence of customer-domain signing.
Similarly, SPF evaluates an SMTP identity rather than simply reading the visible From address. RFC 7208 section 2.4 explains that identity. Do not add generic authorization to the parent domain solely because Dotdigital appears in an inventory. Determine which envelope identity the configured route uses and follow the applicable product-generated instructions.
Design the message check around the business flow
The proposed acceptance test should originate from the same Marketing workflow that will send the real campaign. A hand-built message from a different system does not establish the CFA's behavior. Use a non-sensitive test message and an approved receiving mailbox, then retain enough raw header evidence to reconstruct the identity comparison without creating unnecessary copies of message content.
Keep publication, provider verification, message authentication, alignment and final handling as separate rows. For every row, record the expected outcome, actual observation, timestamp and reviewer. Leave unavailable observations explicitly empty. A recipient seeing the brand's name is not a substitute for these checks, and an inbox result is not a promise about all future campaigns.
Define a stop condition before changing anything: unexplained identity differences, a conflicting domain dependency or a verification error that cannot be reconciled with the intended records. Escalate the specific issue to the responsible owner. Avoid solving uncertainty by weakening the organization's broader DMARC policy or moving unrelated services during the same change.
Fictional domain-selection exercise and release gate
In a fictional planning session, a team proposes reusing a subdomain already assigned to transactional mail. Its review instead selects a new dedicated sending-subdomain proposal and asks the DNS owner to evaluate the self-hosted arrangement because the parent is signed. No domain is delegated, no records are generated and no message is sent. The exercise explains the decision, not its execution.
The original evidence gate remains: Current Dotdigital first-party setup evidence and a received-message identity table from the exact product and route. The commissioning gate is: Confirm current product identity and provider-owned documentation; test a real message or published records. State unsupported custom-domain features honestly. Current documentation is retained, while account applicability, original observations, human SME approval, live visual review and publication authorization remain open.