Dotdigital SPF and DKIM setup

What you are setting up

Dotdigital calls a sending domain a custom from address, or CFA. The rule that shapes everything else is that a CFA lives on a new subdomain (say email.yourdomain.com) or a new lookalike domain (say email-yourdomain.com). Dotdigital's docs are explicit that an existing subdomain cannot be used. On that subdomain Dotdigital wants to own the whole zone: A records for tracked links, MX records for bounces and unsubscribes, and TXT records for SPF, DKIM, and DMARC. The recommended way to hand that over is to delegate the subdomain with NS records. The alternative is to host the records yourself, which Dotdigital allows only with sign-off from your Customer Success representative. Either way, both SPF and DKIM end up on the same subdomain as your From address, so both align under DMARC.

Publish SPF and DKIM

Select the Account menu icon, then Settings > Email > From addresses, and add the address on your new subdomain. For the delegated route, add three NS records at that subdomain in your own DNS:

Type:  NS
Host:  email            (your new subdomain, e.g. email.yourdomain.com)
Value: ns0.dns.dotdigital.com

Type:  NS
Host:  email
Value: ns1.dns.dotdigital.com

Type:  NS
Host:  email
Value: ns2.dns.dotdigital.com

Dotdigital then publishes the SPF, DKIM, DMARC, MX, and A records inside that zone itself, and says to allow up to 48 hours for the CFA to activate. There is nothing for you to copy: the SPF record names only Dotdigital's own mail servers, and the DKIM public key is a 2048-bit TXT record for every new CFA (older ones may still be 1024-bit; support will upgrade or rotate on request). Dotdigital does not publish the SPF include hostname or the DKIM selector name in its help center, and with delegation you never need them.

If you self-host instead, the same From addresses page has a Verify link next to the address that lists the exact records for your account. They can take up to ten minutes to appear. The shape is:

Type:  TXT     (SPF)
Host:  email
Value: (the v=spf1 record shown on the Verify page)

Type:  TXT     (DKIM)
Host:  <selector>._domainkey.email
Value: v=DKIM1; k=rsa; p=... (the key shown on the Verify page)

Type:  TXT     (DMARC)
Host:  _dmarc.email
Value: v=DMARC1; p=none; rua=...; ruf=... (as shown on the Verify page)

Type:  MX
Host:  email
Value: (Dotdigital's inbound mail servers, all at the same priority)

Type:  A
Host:  email
Value: (Dotdigital's web servers, for tracked links)

Publish every record exactly as listed, return to the page, and select Verify at the bottom, allowing up to 48 hours for DNS to propagate. Once it verifies you must also read and tick the confirmation and select Confirm, or the address is not finished. CAA records are optional and are not checked.

Add DMARC

Two records matter here, and they are on different names. Your organizational domain keeps the standard _dmarc TXT record; start in monitor-only mode and ramp up:

Type:  TXT
Host:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

The CFA subdomain gets a second DMARC record that Dotdigital writes. By default it is p=none with adkim=r; aspf=r; pct=100 and both rua and ruf pointed at Dotdigital's own reporting address. If you want the policy changed or your own reporting address added, Dotdigital says to contact its support team. Build your root record with our DMARC builder and progress past p=none once your reports are clean.

The Dotdigital gotcha

The delegated subdomain's DMARC is not yours. A subdomain normally inherits the DMARC policy of its parent, and Dotdigital's docs say plainly that when it sets up its own record on the CFA it overwrites that inheritance. So your root p=reject does not apply to email.yourdomain.com, and the aggregate reports for that subdomain flow to Dotdigital, not to you, until support adds your address. If you run DMARC at the organizational level, Dotdigital asks you to tell them before you delegate. Do that, and give them your rua address in the same message, so your Dotdigital traffic shows up in your reporting alongside everything else.

Self-hosting is stricter than it looks. Dotdigital's verifier fails on extra MX or A records (ExtraDnsRecordError), on MX records with unequal priorities, and on a DMARC record missing any of p=, rua=, or ruf= (MissingDmarcTagValueError). A tidy DMARC record without a ruf tag will not verify, so publish the record as shown rather than your usual one. Two more traps from the docs: a parent domain with DNSSEC enabled cannot be delegated at all, so you must self-host; and a sending domain purchased through Dotdigital has to be verified within 15 days and rested for 30 days before you send from it.

Confirm it worked

• Check the From addresses page. Under Settings > Email > From addresses the custom address should show as verified and confirmed. If you delegated, a dig NS email.yourdomain.com should return the three dns.dotdigital.com servers.
• Send a test and read the headers. Send a test campaign, open it at the other end, and confirm the DKIM signature shows d=email.yourdomain.com and the result is dmarc=pass. Note the Return-Path host while you are there; Dotdigital does not document it, and the header is where you learn it. Our header analyzer reads it back plainly.
• Watch the reports. Once your address is on the subdomain's DMARC record, Dotdigital should appear as an aligned, passing source on both SPF and DKIM under email.yourdomain.com, labeled as a known sender in trustyourinbox. If it never appears, the reports are still going only to Dotdigital.