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, the publication's website can live at www.yourdomain.com or newsletter.yourdomain.com instead of yourpublication.substack.com. That is a web hosting change. Substack's own FAQ answers “Will having a custom domain send my newsletters from the domain?” with a flat no: the newsletters will always be sent from [publicationdomain]@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 genuinely sends (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, and allow up to 36 hours; past that, Substack says the configuration is probably wrong and can be deleted and redone without a second charge.

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 block your newsletter, and a missing DMARC record on your domain cannot hurt it. Substack's help center has no DKIM, SPF, or DMARC article 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, which is exactly what Substack's own troubleshooting article tells subscribers to ask their IT team to do. 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 Settings > Emails and make sure Who can reply to your emails is not set to No one. 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 genuinely 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.