How to set up DMARC/DKIM/SPF for Dotdigital
Published 29 Jul 2026
Updated 29 Jul 2026
14 min read
Summarize with
Set up 
Dotdigital Marketing authentication by creating a dedicated Custom from address (CFA), delegating a new sending subdomain to Dotdigital or publishing the exact self-hosted DNS records it supplies, and then verifying SPF, DKIM, and DMARC. Delegation is the cleanest route because Dotdigital creates and maintains the authentication records.
Dotdigital Marketing authentication by creating a dedicated Custom from address (CFA), delegating a new sending subdomain to Dotdigital or publishing the exact self-hosted DNS records it supplies, and then verifying SPF, DKIM, and DMARC. Delegation is the cleanest route because Dotdigital creates and maintains the authentication records.A branded CFA supports a custom Return-Path and DKIM signing domain, so both SPF and DKIM can satisfy DMARC domain matching. Dotdigital's authentication documentation confirms that new CFA domains use a 2048-bit DKIM key and start with DMARC monitoring.
Keep the sending domain exclusive
Use a new subdomain such as email.example.com. Do not delegate the apex domain, an existing mail subdomain, or a subdomain used by another sender. Dotdigital expects exclusive control of a delegated CFA.
Add your domain
Create the CFA before changing campaign settings. The normal path is a fresh subdomain delegated to Dotdigital. Self-hosting is the fallback when the parent domain uses DNSSEC or the DNS provider cannot delegate a subdomain.
- Choose the domain. Create a new sending subdomain such as email.example.com. Keep normal staff mail on the parent domain.
- Pick the route. Use NS delegation unless DNSSEC or provider restrictions prevent it. Get Dotdigital approval before self-hosting.
- Publish the NS set. Add all three Dotdigital name servers at the new subdomain with a 3600-second TTL. Remove other NS records at that subdomain.
- Request the CFA. Give the Customer Success representative the delegated subdomain, the alias before the @ sign, and the Dotdigital account username.
- Confirm the address. In Dotdigital Marketing, open Account menu > Settings > Email > From addresses. Confirm the CFA after its DNS status passes.
Dotdigital can take up to 48 hours to activate a delegated CFA. For self-hosting, the CFA must already exist in the account before the Verify action exposes the required DNS records.
Dotdigital From addresses screen with a CFA awaiting verification
The NS records belong on the subdomain label, not the apex. If the chosen name is email.example.com, many DNS consoles want email in the Name field. A provider that expects a fully qualified name wants email.example.com instead.
After delegation, Dotdigital creates the web, inbound-mail, SPF, DKIM, and DMARC records inside that child zone. Do not duplicate those records in the parent zone.
Dotdigital subdomain delegationdns
Name: email Type: NS Value: ns0.dns.dotdigital.com Name: email Type: NS Value: ns1.dns.dotdigital.com Name: email Type: NS Value: ns2.dns.dotdigital.com TTL: 3600
If self-hosting is approved, open Verify for the CFA and publish every required TXT, MX, and A record exactly as shown. CAA records are optional in Dotdigital's verification. Return to the same screen, select Verify, accept the confirmation checkbox, and select Confirm.
NS delegation
- DNS ownership. Dotdigital manages the child zone.
- Authentication. Records are created and maintained automatically.
- Best fit. A new, exclusive sending subdomain.
Self-hosted DNS
- DNS ownership. Your team maintains every record.
- Authentication. Copy only the values shown in Verify.
- Best fit. DNSSEC or failed subdomain delegation.
Set up SPF
A delegated CFA already has its SPF record. For a self-hosted CFA, publish the exact SPF TXT value displayed by Dotdigital. Do not infer the record from another customer's DNS because regions and infrastructure change.
- Open the CFA. Go to Account menu > Settings > Email > From addresses and select Verify for the pending address.
- Find the SPF row. Copy its host, TXT value, and any stated TTL without editing the include or all mechanism.
- Check for one record. The Return-Path domain must have one SPF record. Merge authorized senders only when that exact hostname is shared.
- Publish and wait. Save the TXT record, allow DNS propagation, and use Verify again.
- Test domain matching. Send through the CFA and confirm the Return-Path shares the organizational domain used by the visible From address.
Dotdigital CFA verification screen highlighting the SPF record
SPF authenticates the envelope sender, also called the Return-Path. It does not authenticate the visible From address by itself. DMARC counts SPF only when the authenticated Return-Path domain matches the visible From domain under the active DMARC matching mode.
Dotdigital supports custom Return-Path matching through a correctly configured CFA. If a different sending source cannot set a custom Return-Path, expect SPF domain-matching failures there. That source can still pass DMARC when DKIM passes and its signing domain matches the visible From domain.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
Run the check against the exact Return-Path domain, not only the parent domain. Confirm one SPF record, valid syntax, a terminating all mechanism, and no more than ten DNS-causing lookups.
A passing lookup does not prove DMARC matching. Send a real campaign test and inspect Authentication-Results for both the SPF result and the domain used in that result.
Never add a second SPF record
Two SPF TXT records at one hostname cause a permanent error. If a self-hosted hostname already has SPF, build one combined record and recheck the ten-lookup limit.
Set up DKIM
Dotdigital signs CFA mail with DKIM. Delegated domains receive the key automatically. Self-hosted domains must publish the selector and public key shown on the CFA verification screen.
- Open Verify. Find the pending CFA under Settings > Email > From addresses and select Verify.
- Copy the selector. Use the full host Dotdigital displays. Do not guess a selector or copy one from another CFA.
- Copy the public key. Publish the complete TXT value without smart quotes, line breaks, or missing characters.
- Avoid duplicated names. If the DNS console appends the zone automatically, enter only the selector and _domainkey labels.
- Verify the signer. Send a test and confirm DKIM passes with a signing domain that matches the visible From domain for DMARC.
Dotdigital verification page showing the DKIM selector and public key
New Dotdigital CFA domains default to 2048-bit DKIM. Some older CFAs still use 1024-bit keys. Ask Dotdigital support to upgrade or rotate an older key, then publish the replacement before the old selector is retired.
The selector in a received message appears in the DKIM-Signature header after s=. The signing domain appears after d=. Check the key at that exact selector and confirm the d= domain has the required relationship to the visible From domain.
DKIM record shapedns
Host: <selector>._domainkey.email.example.com Type: TXT Value: v=DKIM1; k=rsa; p=<public-key-from-Dotdigital>
DKIM is the forwarding-safe path
Forwarding often changes the envelope sender and breaks SPF domain matching. A valid Dotdigital DKIM signature normally survives forwarding when the message body and signed headers remain unchanged.
Set up DMARC
If the organizational domain has no DMARC record, start with p=none and collect aggregate reports. If it already has p=quarantine or p=reject, keep that policy and fix Dotdigital authentication instead of weakening enforcement.
- Check the current record. Query _dmarc.example.com and confirm there is no existing DMARC TXT record before publishing a new one.
- Keep one policy. Update the existing record when one exists. Multiple DMARC records make DMARC evaluation fail.
- Start with monitoring. For a new deployment, publish the p=none record below and replace the example report mailbox with a real address.
- Coordinate the CFA. Dotdigital creates DMARC on delegated CFAs. Contact its support team before changing that child-domain policy or when the parent already enforces DMARC.
- Preserve enforcement. If the domain already uses quarantine or reject, leave it in place and validate Dotdigital with test messages and reports.
Starting DMARC recorddns
v=DMARC1; p=none; rua=mailto:dmarc@example.com
Use the DMARC record generator to build a record with a real aggregate-report mailbox and any required subdomain policy. Publish it as TXT at _dmarc on the domain in the visible From address.
Dotdigital CFA verification screen highlighting its DMARC record
Dotdigital's delegated CFA normally starts at p=none and sends reports to its configured reporting address. To add another report destination or change the CFA policy, contact Dotdigital support because it controls that delegated DNS zone.
A parent-domain DMARC policy applies to subdomains that lack their own record. Tell Dotdigital when the organizational domain already has enforcement so the CFA can receive an explicit child policy where needed.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Run the embedded check against the visible From domain. The result should show one parsed policy, a valid rua destination, and no syntax errors. The DMARC checker also gives a shareable result for a DNS administrator.
DMARC passes when either SPF passes with matching domains or DKIM passes with matching domains. Aim for both on Dotdigital, but treat matched DKIM as the durable path for forwarded mail.
Do not replace active enforcement
Changing p=reject or p=quarantine to p=none exposes the whole domain while solving a single sender. Correct the Dotdigital CFA, then prove that its authenticated domains match.
Verify and troubleshoot
Verification has two layers: Dotdigital must accept the CFA's DNS records, and a real message must pass authentication with domains that match the visible From address. Complete both before sending a live campaign.
- Verify in Dotdigital. Open Settings > Email > From addresses, select Verify, then select Verify again at the bottom of the DNS page.
- Confirm the CFA. Read the confirmation notice, select the acknowledgement checkbox, and select Confirm.
- Send a real test. Use the new CFA as the campaign From address and send through the same account and stream intended for production.
- Inspect the headers. Check Authentication-Results, Return-Path, DKIM-Signature d= and s=, and the visible From domain.
- Require DMARC pass. Confirm SPF or DKIM passes with the required domain match. A raw SPF pass on an unrelated domain does not count.
Dotdigital From addresses screen showing an active verified CFA
Dotdigital says records can take about ten minutes to appear on its verification page, while DNS propagation can take up to 48 hours. A newly added CFA also has a four-hour no-send window after creation. Repeated changes during these windows make diagnosis harder, so compare authoritative DNS with the exact expected values first.
When verification fails, check for missing TXT, MX, or A records, unexpected MX or A records, unequal MX priorities, invalid DMARC policy values, and missing p or rua tags. Also check whether the DNS console appended the zone name twice.
|
|
|
|---|---|---|
SPF pass | Envelope authorized | Check domain match |
DKIM pass | Signature valid | Check d= domain |
DMARC pass | Matching auth | Ready to monitor |
DMARC fail | No matching pass | Fix SPF or DKIM |
Compact authentication result guide
The quickest end-to-end check is a message sent through Dotdigital to the test address below. Use the exact CFA, campaign path, and account region planned for production.
The report separates DNS publication from message behavior. That distinction catches cases where SPF and DKIM records exist but the live campaign uses a different Return-Path, signing domain, or selector.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Treat a clean DNS check as necessary but incomplete. Save the received headers from the email test as deployment evidence and compare them after any CFA, DNS, or account-region change.
If DKIM fails, query the selector found in the actual message. If SPF fails, query the actual Return-Path domain. If both pass but DMARC fails, the problem is domain matching rather than authorization.
Get alerted when it breaks
DNS checks prove the configuration only at one moment. Suped is our DMARC reporting and email authentication platform, and it is the best overall fit for this Dotdigital workflow because it detects source and matching changes, sends real-time alerts, and gives specific steps to fix each issue.
- Add the report address. Put the aggregate-report mailbox generated for the domain into the existing rua tag without creating a second DMARC record.
- Verify Dotdigital. Mark the Dotdigital source as authorized only after its live SPF or DKIM result matches the visible From domain.
- Enable real-time alerts. Send sudden failure, new-source, and policy-change notifications to the team that owns DNS and campaign operations.
- Review issue steps. Use the detected Return-Path, DKIM selector, and failure samples to correct the exact record or Dotdigital setting.
- Watch reputation. Review blocklist (blacklist) signals and deliverability changes beside DMARC rather than treating authentication as an isolated check.
Suped combines DMARC monitoring with SPF, DKIM, blocklist, and deliverability diagnostics. Automated issue detection is useful here because a Dotdigital CFA can appear healthy in DNS while a changed sender path stops matching in live mail.
For agencies and managed service providers, the multi-tenant dashboard keeps each client's Dotdigital domain, alert recipients, policy stage, and verified sources separate. Weekly summaries give a slower review cycle, while real-time alerts cover abrupt failures.
Alert on changes that require action
- New source. Investigate before authorizing it.
- DKIM collapse. Check the active selector and message changes.
- SPF lookup failure. Inspect the Return-Path record and lookup count.
- Policy drift. Restore the approved DMARC policy and reporting tags.
Secure your domain with p=reject
Move to p=reject only after every legitimate sender has a matching SPF or DKIM pass. For Dotdigital, prioritize DKIM because forwarding can break SPF. Keep an already enforced domain at its current policy while correcting any CFA failure.
- Collect full coverage. Monitor at least one complete business sending cycle, including scheduled campaigns, automations, low-frequency transactional mail, and test sends.
- Classify every source. Authorize Dotdigital only when the CFA passes. Remove obsolete senders instead of adding broad SPF permission.
- Fix legitimate failures. Require matching DKIM on important streams and retest forwarding, list redistribution, message modification paths, and gateway rewriting.
- Stage quarantine. Apply p=quarantine to a small percentage, review failures, and raise the percentage only when legitimate mail remains unaffected.
- Apply reject. Move to p=reject after authorized volume stays above a 99% matching pass rate and all remaining failures are understood.
- Keep monitoring. Watch new sources and failure spikes after enforcement because sender configurations continue to change.
The 99% level is a readiness signal, not a substitute for source review. A small failure percentage can contain important password resets or receipts. Identify the business owner and message type behind every material source.
Example enforcement stagesdns
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.com v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Do not publish these example records inside a Dotdigital-delegated child zone. Ask Dotdigital to change that CFA policy. For a self-managed organizational domain, update the single existing DMARC record and retain every required reporting tag.
Suped's hosted DMARC supports policy staging without repeated direct TXT edits. Its source classification, issue steps, and alerts make the move to reject easier to control, while Dotdigital support still owns changes inside a delegated CFA zone.
Stop the rollout on legitimate impact
Pause percentage increases when an authorized source loses matching authentication, a business-critical stream appears unknown, or recipient rejection rises. Fix and retest before continuing.
Dotdigital authentication FAQ
These checks cover the details that usually surface after the first CFA test, including infrastructure identifiers found in SPF records and reverse DNS.
Treat an identifier as evidence, not authorization. Confirm the sending account, live headers, and DMARC aggregate data before changing DNS.
