Substack SPF and DKIM setup

What you are setting up

Substack is a newsletter and publishing platform, and it sends every post from an address it owns. Substack's help center states it plainly: all posts are sent from [subdomain]@substack.com, where the subdomain is your publication's name, and there is currently no option to change or customize the sending address. That single fact settles the whole question. Because the From address is on substack.com, SPF and DKIM are Substack's to publish, not yours. There is no include: for Substack, no substack._domainkey selector, and no return-path CNAME. Your domain does not appear in the message at all, so nothing in your DNS can make it pass or fail.

The thing people confuse this with is Substack's custom domain feature. For a one-time $50 USD fee per publication, the publication's website can live at www.yourdomain.com or newsletter.yourdomain.com instead of yourpublication.substack.com, and once the fee is paid you can add and remove custom domains at no extra cost. That is a web hosting change, and Substack says so: a custom domain does not change the address your newsletters are sent from, which stays on substack.com.

Publish SPF and DKIM

There is nothing to publish for Substack. Keep whatever SPF and DKIM records already authenticate the mail your domain does send (your Google Workspace or Microsoft 365 mailboxes, your transactional provider), and do not add a Substack entry to any of them. The only DNS record Substack ever asks for is the website CNAME behind the custom domain feature, and it has no bearing on email:

Type:  CNAME   (website only, optional, $50 one-time)
Host:  www                    (Substack requires a subdomain such as www)
Value: (the Target shown under Settings > Domain after you add the domain)

SPF:   no Substack include exists; leave your SPF record as it is
DKIM:  no Substack selector exists; nothing to add under _domainkey

To set up that website CNAME, the publication owner or a group administrator goes to the publication's Settings page, clicks Domain in the left navigation, and selects Add custom domain. Do this in Substack first: the CNAME name and target only appear after the domain is added. Substack calls the two fields Name and Target, which your DNS host may label Host and Points to. Substack requires the publication to sit on a subdomain such as www; the bare root domain is not accepted, so forward it with a 301 redirect instead. On Cloudflare, set the record to DNS only (gray cloud, not orange). Use Check status in the Custom Domain section to confirm it once DNS has spread; a record that still fails after a day or two is almost always pointing at the wrong target or proxied.

Add DMARC

Standard _dmarc TXT record, nothing Substack-specific. Publish it for your own domain regardless, because your mailboxes and other services do send as you. Start in monitor-only mode and ramp up:

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

Build it with our DMARC builder and progress past p=none once your reports are clean. Your DMARC policy never applies to Substack mail, in either direction: a p=reject on your domain cannot touch your newsletter, and a missing DMARC record on your domain cannot hurt it. Substack publishes no DKIM, SPF, or DMARC guide for publishers, and that is consistent with the design; the authentication it does for substack.com is not something you can see or tune.

The Substack gotcha

The custom domain is a website, not a sender. Paying for a custom domain feels like it should put your brand in the From address, and it does not. Readers still see yourpublication@substack.com, and any corporate recipients whose mail filters are strict need to allow that address, not yours. Do not add a Substack include to your SPF record hoping to cover the newsletter; Substack does not document one, and it would only spend lookups on mail that never mentions your domain.

Replies are where your domain enters the picture. Your Substack creator address is an alias to the email on your Substack account, so a reader's reply is forwarded to your inbox, or to whatever address you put under Settings > Community > Forward reader emails to. That forwarded mail is received by your domain, not sent by it, so it does not need Substack in your SPF either. If replies are not arriving, check the reply settings under Settings > Emails first. The last surprise is in your DMARC reports: a newsletter you send every week will be absent from them entirely, because reporters group by the domain in the From header and that domain is Substack's. An empty report is not a broken pipeline.

Confirm it worked

• Read the headers of a published post. Open one of your own posts in a mailbox you control and confirm the From address is on substack.com and the DKIM signature carries Substack's domain, not yours. Our header analyzer reads it back plainly. If it shows your domain, the message did not come from Substack.
• Check your own domain, not Substack. Substack has no DNS verification screen for email. Run our DMARC checker on your domain and make sure SPF and DKIM cover the services that do send as you, with no stray Substack entry.
• Watch the reports. Substack will not appear in your DMARC aggregate reports at all. If a source shows up claiming to be your newsletter under your domain, it is not Substack, and trustyourinbox will flag it as an unknown sender.