My Email Newsletters Land in Spam

It's almost never your DNS.

If your newsletters go out through our email setup — how every Starter and Pro site works — the configuration can't be wrong in the way people usually suspect, because we don't let it be. Your newsletter went out authenticated, or it didn't go out at all. That leaves three real causes: your domain's reputation, who's on your list, and what's in the email.

If you send through your own Mailgun account, or your Ghost site is hosted somewhere else, none of that applies to you and the DNS records do matter. Skip to "if you handle your own email sending".

What can't be causing it on Magic Pages

Two things get blamed constantly and can't actually be the problem here:

An unverified sending domain. If your custom domain isn't verified, it never reaches Ghost. Your newsletters go out from yoursite@mymagic.page instead — a domain we authenticate and maintain. So an unverified domain means your emails aren't branded the way you wanted. It doesn't mean they're unauthenticated.

A mismatched sender address. Ghost won't save a "from" address that isn't on your sending domain. If one somehow gets through, it's replaced at send time with your default address, and your intended address becomes the reply-to. There's no version of this you can get wrong — it's checked for you on every send.

SPF and DKIM work the same way. Both ride on the CNAME records you pointed at us, so they're published on your behalf, and your DKIM keys rotate on their own. You have no SPF TXT record and no DKIM blob to maintain, and nothing there to misconfigure.

Reply-to is the one address you're free to change. Set it to whatever you like — Ghost sends a verification email to confirm it.

Sending from your main domain is fine, by the way. If your sending domain is send.yourdomain.com, both send.yourdomain.com and yourdomain.com are accepted as sender addresses, because a DKIM signature on the subdomain still satisfies DMARC for the parent. What isn't accepted is a sender on an unrelated domain.

None of that is true if you handle your own sending. That covers a Ghost site hosted anywhere else, and the custom plans here running their own Mailgun account. The next section is the one to read.

If you handle your own email sending

Some custom plans send through their own Mailgun account, and a Ghost site hosted elsewhere does its own sending by definition. Either way, nothing above holds: Ghost sends from whatever address you put in the settings, whether or not that domain can prove it's yours.

Which puts the DNS back on your plate, and makes it the first place to look rather than the last:

Your sender domain has to be the domain that signs the mail. If your DKIM signature is on mg.example.com, send from mg.example.com or example.com — not from some other domain you happen to own. A mismatch fails DMARC by itself, even when SPF and DKIM both pass.
SPF has to name whoever sends on your behalf. Our SPF generator builds the record.
DKIM has to be published for the sending domain at your provider, with a selector matching what the provider signs with.
DMARC goes on your main domain, and our DMARC generator covers it.

The quickest way to find which one is broken is to open a newsletter you received and look at the raw message behind it:

Gmail: open the email, click the three dots next to Reply, then Show original. The page that opens lists SPF, DKIM and DMARC with a pass or fail beside each one, so you don't have to read any headers yourself.
Outlook on the web: open the email, click the three dots, then View → View message source.
Apple Mail: View → Message → Raw Source, or press ⌥⌘U.
Thunderbird: View → Headers → All, or press Ctrl+U.

In the raw source, look for the Authentication-Results header. It spells out spf=, dkim= and dmarc= for that exact message, so there's nothing to guess at.

If your setup predates September 2025

Your sender address only became tied to your sending domain with the new sending domain setup in September 2025, and existing configurations weren't migrated.

An old setup still won't send unauthenticated mail — the sender gets corrected on the way out. What it does instead is quieter: your newsletters arrive from yoursite@mymagic.page rather than your own domain, which looks like a branding glitch rather than a configuration one. Subscribers who don't recognise the sender are more likely to ignore you, and that engagement drop does eventually cost you placement.

Open the customer portal, go to Newsletter → Email Configuration, and look for a warning reading "Email authentication issue detected" — it's there to catch exactly these old configurations. Running through the setup again applies the current rules.

DMARC is the one record we can't publish for you

Back to sending through us. SPF and DKIM can be published on your behalf because they live on the subdomain you pointed at us. DMARC has to sit on your own domain, so it isn't ours to add — and it's the one piece of authentication most domains are missing.

It tells providers what to do with mail that fails authentication while claiming to be from you. Gmail, Yahoo and Outlook require it above 5,000 messages a day to their users. Most newsletters are well below that, and it still helps.

Our DMARC generator builds the record in a couple of clicks. Start with the monitor-only policy and tighten it once you've confirmed your mail passes. When you set up a sending domain, the portal checks for a DMARC record and warns you if there isn't one — but it won't stop you. Easy to skip, easy to forget.

SPF is worth a look only if your main domain sends mail another way too, like Google Workspace or a helpdesk. Our SPF generator covers that case. It's not needed for newsletters sent through us.

A new sending domain has no reputation yet

This is the most common real cause, and it looks alarming because there's nothing visibly wrong.

A fresh domain means nothing to Gmail or Outlook. Your first two or three newsletters can land badly while they work out whether you're worth trusting. There's no way to buy your way past that — it resolves as real subscribers open your mail. Warming up a new sending domain covers what to expect.

If placement hasn't improved after three sends, that isn't warming any more. Write to us.

Your list is the most likely cause after that

Addresses that hard-bounce aren't your problem — Ghost stops sending to those by itself and leaves them out of every future send. The damage comes from addresses that accept your mail and never open it: abandoned inboxes, old work addresses that still resolve, subscribers from an import three years ago. Providers read a low open rate as "our users don't want this" and adjust placement for everyone on your domain.

In Ghost admin, go to Members and sort by open rate, then look at anyone who hasn't opened a thing in six months. Unsubscribing a few hundred dormant addresses tends to lift your open rate and your placement together.

One caveat worth saying plainly: if your list was purchased, rented, or handed to you by a third party, that's your answer — and it also breaks our anti-spam policy. The same applies to addresses that never gave you verifiable consent. We can disable sending on an account without notice over it, and no amount of DNS work will fix your placement in the meantime.

Importing a list you built yourself is fine. Ghost's signup flow handles double opt-in on its own, but a CSV or API import skips that step, so the consent becomes yours to stand behind — the terms ask you to keep records you can produce if we ask.

Then there's the email itself

Filters read your content as well as your headers. Four things reliably hurt: an email that's one big image with almost no text, link shorteners, a link to a domain that's already been flagged, and the vocabulary of a bad sales pitch — free, guaranteed, act now, rows of exclamation marks.

If a newsletter you've sent for years suddenly lands in spam, compare it to the last one that didn't. Usually your content changed, not your configuration.

Gmail and Outlook don't behave the same way

Gmail weights engagement above everything else. Opens, replies and "not spam" clicks from real subscribers pull you out of the spam folder faster than any record you can publish. If you send from your own domain, add it to Google Postmaster Tools — it's free, and it reports your spam-complaint rate and domain reputation straight from Gmail. It's the only place Gmail tells you what it thinks of you.

Outlook and Microsoft 365 lean harder on the sending IP and are stricter about authentication. The IPs are our side of the line, so if Outlook is junking your mail while Gmail is fine, tell us rather than changing your DNS.

When to write to us, and what to send

Get in touch if your placement is bad at one provider in particular, if it hasn't improved after three sends from a new domain, or if you've been through the above and nothing fits. Send us:

the Message-ID of a newsletter that went to spam — in Gmail, open it and click ⋮ → Show original; other email clients are listed above
the recipient's domain — gmail.com, outlook.com, a subscriber's company domain
roughly when it was sent
whether it hit spam for one subscriber or for many

The Message-ID lets us trace that exact message through Mailgun and read back what the receiving server said about it. That's the difference between us guessing and us knowing.

For the longer version of all of this, there's Email Deliverability in Ghost CMS: Avoiding Spam Filters on the blog.