For Dotdigital Marketing, authenticate a custom from address (CFA) on a dedicated sending domain. Choose either Dotdigital-managed DNS through delegation or an approved self-hosted arrangement. Self-hosted customers must publish the exact account-provided records, run verification and complete the final confirmation. A generic SPF include copied into your company root domain is not a substitute for CFA setup.
On this page
- Choose the right domain and route
- Decide who manages DNS
- Configure self-hosted authentication
- Understand SPF and DKIM ownership
- Protect existing DMARC policy
- Verify public records and actual mail
- Troubleshoot CFA verification
- Frequently asked questions
Choose the right domain and route
This article covers the Marketing product's CFA sending route, formerly associated with the dotmailer name. It does not configure a Personalization content domain or authenticate a separate mailbox provider. Start with the actual Marketing account and region, not just the company name on a contract.
Dotdigital requires a new sending subdomain or supported separate domain rather than repurposing an existing subdomain. The CFA is exclusive to this service; it is not a general-purpose shared sender domain. Parent-domain DNSSEC requires self-hosting under the documented product constraint. CFA sharing across accounts is limited to accounts in the same region. Dotdigital branded domains.
A useful design is a previously unused name such as news.example.com, with a From address such as updates@news.example.com. These are illustrative identities, not account values. Before reserving the name, check that it does not already host a website, old campaign links, mailboxes or another sender's bounce processing.
Inventory normal employee email separately. For help interpreting results, see EmailAuth's raw DKIM results versus aligned DKIM policy results. Keep that domain's working records intact while introducing the dedicated Marketing namespace.
Have the account owner or an authorized settings user, DNS administrator and DMARC policy owner participate. The reviewed public documentation does not give a complete role-by-role permission matrix or guarantee that every CFA purchasing option is enabled on every account. Confirm available controls and any commercial terms with Customer Success before scheduling rollout. No purchase is necessary merely to evaluate a subdomain you already own.
Decide who manages DNS
There are two operationally different choices:
| Route | Who publishes authentication records? | Main preparation |
|---|---|---|
| Delegated CFA subdomain | Dotdigital manages the delegated namespace | Obtain the assigned NS records and approve the delegation boundary |
| Approved self-hosted CFA | Your DNS administrator publishes and maintains Dotdigital's supplied records | Coordinate with Customer Success and get the CFA added to the account |
For delegation, obtain the exact name-server destinations for the account and region. Publish the instructed NS records at the chosen child-domain owner in the parent zone. For news.example.com within an example.com editor, that owner may be entered as news. Do not replace the entire organization's registrar name servers. Do not substitute MX records for delegation.
Dotdigital says self-hosting must be discussed with Customer Success, which adds the CFA to the account. Managed domains do not support arbitrary customer DNS changes. Create a CFA.
The native delegation procedure documents automatic creation of authentication TXT plus A records for web links and MX records for bounce/unsubscribe processing after NS delegation and CFA addition. Compare the exact assigned destinations and namespace consequences with the authorized routing plan before delegation or self-hosted publication. Approve any inbound-mail/forwarding destinations explicitly; an account packet is not permission to redirect existing traffic.
After the approved delegation is published, contact your Customer Success Representative to confirm any associated costs and next steps. Give them the delegated domain name and confirmation that it points to Dotdigital, the requested CFA local-part (the text before @), and the username of the account that needs the CFA. Obtain owner approval for any commercial commitment before proceeding. Dotdigital then adds and activates the CFA; the native procedure allows up to 48 hours. Successful NS publication alone does not mean the CFA is active or ready to send. Post-delegation activation.
The practical implication is important: delegation transfers DNS responsibility for the whole selected namespace, not only SPF. Inspect old records before approving it. If there is a collision with a live service, choose another unused name rather than deleting records to force this design through.
Do not disable DNSSEC merely to fit the delegated route. Use the documented self-hosted option and coordinate any product limitation with support. Capture who will receive provider DNS-change notices and who can implement them, particularly when an outside agency manages the zone.
Configure self-hosted authentication
Once Customer Success has added the CFA, open Account menu → Settings → Email → From addresses and choose Verify beside that address. The record set may take up to ten minutes to appear. Copy the complete displayed set, not just the DKIM row. After publication, select Verify again, review the confirmation information, obtain any required owner approval for the displayed acknowledgment, then select its checkbox and Confirm. DNS visibility can take up to 48 hours. CAA is optional for this verification. Self-hosted verification.
Use a DNS change sheet with one row per supplied record:
| Purpose | Owner / Name | Type | Value |
|---|---|---|---|
| SPF | Exact sending-domain owner supplied by Dotdigital | TXT when displayed | Complete supplied SPF policy, not a guessed include |
| DKIM | Exact supplied selector owner | TXT for the documented public key workflow | Entire account-provided public key record |
| DMARC | _dmarc beneath the CFA domain |
TXT | Policy-owner-approved record reconciled with Dotdigital's requirements |
| Supporting service records | Each supplied owner | A, MX or other displayed type | Exact destination and, for MX, priority |
If your generated set differs from this purpose summary, follow the current account's labels and resolve uncertainty with support. Do not invent an extra selector or manually generate a private key. Only public authentication material belongs in DNS.
For SELECTOR._domainkey.news.example.com, an editor for example.com may need SELECTOR._domainkey.news, while an editor for the separate news.example.com zone may need SELECTOR._domainkey. If _domainkey.news.example.com is separately delegated, use SELECTOR within that authoritative zone. Preserve existing delegation, DNSSEC and selectors; do not remove NS records simply to publish in the parent. The final public owner must be identical in every case. Use the DNS host's TXT editor to preserve the complete tagged value without smart quotes, truncation or accidental whitespace inside the key. A long DKIM value may be represented by multiple character strings in one logical TXT record, concatenated without inserted spaces. Do not turn those strings into separate TXT records or merge independent issued records. DKIM TXT key storage.
Export the old zone before making approved changes. If any requested owner already has data belonging to another service, pause and investigate the scope. Do not interpret provider verification errors as permission to delete unrelated records elsewhere in the organization.
Understand SPF and DKIM ownership
Dotdigital provides its CFA SPF and DKIM configuration. Its authentication documentation says the managed sending domain authorizes its own servers, not arbitrary additional senders. New CFAs default to 2048-bit DKIM keys; support handles upgrades or rotation for older configurations. Dotdigital authentication.
SPF evaluates the envelope MAIL FROM domain, or HELO for a null reverse-path, not merely the visible From address. Confirm the actual identity on a delivered message before deciding which DNS owner to inspect. A root-domain SPF lookup does not establish whether a distinct CFA subdomain is authenticated.
At any owner you manage, keep one SPF policy and preserve legitimate authorization. SPF's ten lookup-causing-term limit includes nested mechanisms; adding another v=spf1 TXT record creates an error rather than extending the first record. Ordinary unrelated TXT verification tokens are not duplicate SPF records. The evaluated budget includes nested include, a, mx, ptr, exists and redirect, not ip4, ip6 or all. Any all mechanism makes redirect ineffective: SPF ignores the redirect when all is present. Preserve the existing qualifiers and redirected authorization design; do not add all while merging without understanding that change. Qualifiers do not guarantee delivery or rejection. SPF redirect rule. SPF standard.
For DKIM, take the message's selector s= and signing domain d= and resolve s._domainkey.d. This checks the key actually used, rather than a selector someone remembers from an old ticket. A public key existing in DNS does not prove signing is active or that the signature survived transit. DKIM standard.
Protect existing DMARC policy
Before provisioning the CFA, tell Dotdigital whether your organization already enforces DMARC. Its documented default is monitoring with provider reporting, and support handles policy/reporting adjustments. Do not allow an unreviewed local CFA record to weaken a policy inherited from the parent.
Inspect _dmarc.news.example.com and the applicable parent policy. Preserve established p, subdomain policy, alignment requirements and reporting recipients unless the policy owner approves a change. Do not paste a second DMARC record at the same owner.
Where there is no established applicable policy and monitoring is appropriate, the policy owner can arrange a record such as:
Owner: _dmarc.news.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:APPROVED_REPORT_ADDRESS
This is a policy illustration, not a replacement for Dotdigital's required report destinations. Replace APPROVED_REPORT_ADDRESS with the real mailbox address only, not another mailto: prefix. For _dmarc.news.example.com, use _dmarc.news in the parent zone or _dmarc in a separately delegated news.example.com zone; for _dmarc.example.com, use _dmarc in its parent zone. Compare the Organizational Domain of the domain where the policy was found with the Organizational Domain of the reporting URI host. When they differ, the report-generating receiver must check destination DNS authorization. A destination within the same Organizational Domain is excepted even when the hostnames differ. RFC 9990 section 4. That protocol check is separate from the domain owner's data-sharing/privacy approval for the recipient and report contents. Do not publish the placeholder. Dotdigital verification can also require ruf, which requests individual-message failure reports rather than the aggregate reports requested by rua. Reconcile that requirement with support and obtain privacy approval for the data and recipient before enabling it. Never copy a sample failure-report destination; receiver support for these reports varies.
DMARC needs either an aligned SPF pass or an aligned DKIM pass. Relaxed alignment permits the same organizational domain; strict alignment requires exact matching. For a hypothetical From news.example.com, an intended passing signature with d=example.com aligns in relaxed mode but not strict mode. A passing d=news.example.com exactly matches that From in either mode. These are illustrative identity comparisons, not measured delivery results. The current RFC 9989 replaces RFC 7489 and removes pct; do not rely on percentage settings shown in older examples as a safety control. Review legitimate traffic before enforcement. Current DMARC specification.
Verify public records and actual mail
For a delegated setup, check that the parent points to the assigned name servers and the child answers authoritatively. For self-hosting, compare every expected owner, type and value with the generated set. These commands are illustrative; replace all uppercase placeholders:
dig NS news.example.com +short
dig TXT ACTUAL_MAIL_FROM_DOMAIN +short
dig TXT SELECTOR._domainkey.SIGNING_DOMAIN +short
dig TXT _dmarc.news.example.com +short
A blank short answer is not enough to diagnose a missing record. Read the full response and distinguish NXDOMAIN, SERVFAIL and timeout. Check authoritative answers and a recursive resolver, noting TTLs and the time of change. Confirm the CFA is usable in the account after the final confirmation step.
Then send through the intended campaign or automation using the CFA. At a direct receiving mailbox, use receiver-controlled diagnostics or results created inside its known processing boundary. Confirm the receiving service's documented removal or isolation of externally supplied Authentication-Results, or have its mail administrator establish that handling. A familiar authserv-id or header position alone is not proof; ignore attacker-inserted/untrusted fields. Capture the From address, smtp.mailfrom, DKIM header.d, selector and results. Require SPF pass and a branded, aligned DKIM pass for the intended direct route, plus dmarc=pass. A provider-only DKIM signature does not satisfy this branded-signing acceptance gate even if another identifier supplies DMARC alignment. Investigate any identity that differs from the approved design. Do not trust a sender-inserted copy of this header. Receiver authentication results.
Investigate SPF fail as an authorization or route issue, permerror as malformed/duplicate policies or exceeded evaluated lookup limits, and temperror as a temporary DNS/resolver issue. An aligned DKIM-based DMARC pass does not close an unresolved direct-route SPF defect. A rewritten unrelated From is not successful authentication of the intended brand.
Keep a dated acceptance record per account and route. A same-region shared CFA still needs a representative message from each account; sharing DNS does not prove every campaign selected the correct From address. Authentication success is not a guarantee of inbox placement.
Troubleshoot CFA verification
Missing records: Compare all supplied TXT, MX and A rows, not only SPF and DKIM. Check the correct authoritative zone and suffix handling.
Extra MX or A records: Verify that the CFA namespace is truly dedicated. Identify ownership before removing anything; an unexpectedly populated subdomain is a design problem, not just clutter.
MX priority mismatch: Match the generated priorities exactly. Do not “improve” the order from memory.
DMARC validation errors: Reconcile required reporting fields and policy values with support and your policy owner. Do not weaken enforcement to make a check green.
DNS verifies but the message fails: Confirm final CFA activation, selected campaign From address, actual DKIM selector and any intermediate message modification. Test the affected workflow, not an unrelated preview.