Substack SMTP Settings and Configuration (2026)

People land on “Substack SMTP settings” with one of four real jobs: branding the From address, adding SPF and DKIM for Substack, sending transactional mail from the same brand, or moving the list into a tool that does have a relay. This page answers all four. If the From line is why you are here, the closest editorial substitute is beehiiv, which includes a custom domain on every plan and lets it be the real sending domain; Kit, MailerLite and Flodesk authenticate a sending domain too. If you only need a pipe for receipts, keep Substack and add Postmark, Resend or Amazon SES under your own subdomain.

Quick reference

What a developer normally copies out of an SMTP tab, and what Substack puts there instead. Values marked Not offered are architectural, not undocumented.

Why Substack has no SMTP relay

Substack sells the publication, not the pipe. It takes 10% of each paid subscription plus Stripe’s fees and charges nothing for volume, publishing is free “no matter how many subscribers you have.” A company paid on conversion has no reason to meter or sell sending capacity, so there is no relay product to price and no tier that unlocks one. That is the opposite of the economics at Amazon SES or SMTP2GO, where the message is the unit of revenue and credentials are the product.

The second reason is reputational. Every newsletter leaves from Substack-controlled domains and IPs, which lets the company pool the reputation of hundreds of thousands of publications, police abuse centrally, and put a writer with no sending history into the inbox on day one. Handing out SMTP credentials would invert that: anyone could borrow that shared reputation for arbitrary mail. Substack is consistent at every layer: no relay or sending-IP article in the help centre, deliverability guidance that offers only reader-side remedies, Developer API Terms scoped to public profile data with no send endpoint, and an editor that blocks custom HTML, CSS and raw iframes. The absence of a relay is a decision, not a roadmap gap.

What you actually need instead

Three intents account for nearly every “Substack SMTP” search, and each has a concrete path that does not involve waiting for a feature Substack is not building.

Sending transactional email

Receipts, password resets, order confirmations, onboarding drips and app notifications cannot go through Substack at all. Its entire native automation surface is four welcome emails, free, paid, imported and founding subscribers, plus a manual broadcast to a filtered segment. No trigger, no template API, no event hook. Run this stream on a relay under a subdomain such as mail.example.com: Postmark when inbox placement on receipts is the priority, Resend or MailerSend for a modern API alongside the relay, Amazon SES when volume economics dominate.

Connecting a CMS, an app or a form

WordPress, Laravel, Django, Rails and every plugin asking for “SMTP host, port, username, password” expect exactly the four values Substack does not issue. There is nothing to paste and no workaround; a plugin claiming to send “through Substack” is either driving a copied session cookie or mislabelled. Point those applications at a real relay – SMTP2GO and Brevo are the usual picks for a CMS plugin. Keep Substack for the newsletter and let the application own its sending identity.

Routing notifications and automation

Substack exposes no webhooks and has no official Zapier app. The only stable unauthenticated read interface is the publication RSS feed, which a generic RSS trigger can watch for new posts, outbound only, no subscriber event, no write-back. To react to subscriber activity, export the list to CSV and run the lifecycle logic somewhere with an event model: Kit and MailerLite expose automations, an authenticated API and your own sending domain.

Sending domain authentication

There is nothing to authenticate for Substack itself. That is worth spelling out precisely, because the DNS records people go looking for do exist, they just belong to a different provider.

SPF and DKIM setup

Substack never asks for an SPF include or a DKIM selector, because your domain never appears in the SMTP envelope or the DKIM d= tag. The message is signed by substack.com, so a Substack-specific record in your zone would authorise nothing. The custom domain flow requests web records only, and no MX appears anywhere in the setup.

# 1. What Substack asks for (web only, never mail)
example.com.       3600 IN A     3.231.35.217          # root domain, documented value
www.example.com.   3600 IN CNAME <target-from-your-dashboard>   # issued per publication

# 2. What Substack never asks for, and you must not invent:
#    no MX, no SPF include, no DKIM selector for Substack.

# 3. What you DO publish when you pair a relay on a subdomain.
#    Take the exact include token and selector from that provider.
mail.example.com.  3600 IN TXT   "v=spf1 include:<provider-spf-host> -all"
<selector>._domainkey.mail.example.com. 3600 IN CNAME <provider-dkim-target>

Read that as two zones of responsibility. Block (1) makes your website resolve to Substack; block (3) lets a relay you control sign mail as mail.example.com. They never overlap, and keeping the relay on a subdomain rather than the root is what stops one stream inheriting the other’s history.

DMARC alignment

Substack newsletters cannot be aligned to your domain, and cannot be broken by its policy either. Because the envelope sender and the DKIM signature both belong to substack.com, a DMARC record at p=reject on your brand domain has no effect on them. That is the most useful thing for a deliverability owner to know: tightening DMARC will not damage the newsletter, and loosening it will not help it.

Where DMARC does matter is the mail you send yourself. Publish one policy on the organisational domain, let the relay subdomain inherit it, and move to enforcement once the reports are clean:

# Monitor first, and read the reports for two to four weeks
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1"

# Tighten once every legitimate stream passes SPF or DKIM alignment
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=s"

# No subdomain exception is needed for Substack: that mail is not sent
# from example.com, so it is out of scope entirely.

One consequence: a strict DMARC posture puts your authentication story on transactional mail while the newsletter keeps arriving under Substack’s identity. If brand consistency across both streams is a requirement rather than a preference, that is the argument for moving the newsletter to a platform where the sending domain is yours, such as beehiiv.

Sending limits

Substack publishes no numeric sending limits of any kind. The table records that explicitly, because every figure circulating for these fields is third-party guesswork.

Common mistakes

Pairing Substack with an SMTP provider

Running both is the normal end state, not a compromise: Substack keeps the editorial newsletter, a relay handles everything transactional. The trick is keeping the two streams from colliding on reputation or DMARC.

The recommended setup

Delegate a dedicated subdomain to the relay – mail.example.com or send.example.com – and authenticate it there with the SPF and DKIM values that provider issues. Never authenticate it on the bare root domain if the root also hosts your Substack site: separating them keeps a transactional incident from contaminating what you send from the root later. Warm the subdomain over a couple of weeks rather than cutting full volume across in one evening, and point reply-to at a mailbox you actually monitor, since Substack replies land elsewhere.

Keep the lists separate too. Export the subscriber CSV only when you genuinely need it downstream, and do not load it into the transactional relay as a marketing audience: those addresses consented to a newsletter on Substack, not to mail from a second sender, and blending them is how a clean subdomain acquires complaint rate it did not earn.

Keeping the two systems from double-sending or conflicting

Two failure modes account for almost every problem here. The first is double-sending: a relay automation firing a welcome message to someone who already got Substack’s built-in one. Those four welcome emails cannot be disabled per source, so decide once which system owns onboarding, usually Substack for list subscribers, the relay for product signups, and make sure no sync copies people across the boundary. With no webhooks, any such sync is a manual CSV or a scraper, and easy to run twice by accident.

The second is DMARC confusion during an audit. Substack newsletters never appear in your aggregate reports, and a colleague reading them will conclude the newsletter is not being sent at all. Document it: Substack is out of scope for _dmarc.example.com by design, the relay subdomain is in scope, so a failure line always refers to the relay or an unauthorised sender, never to the newsletter.

Frequently asked questions