Why Your Course Launch Emails Land in Spam

You spend three weeks building a launch sequence, hit send to 1,800 subscribers, and the open rate crawls in at 9%. The subject line is fine. The offer is fine. The real problem is that a chunk of those emails never reached an inbox at all — they were filed as spam before anyone read the first word. For course creators, deliverability is the least glamorous part of a launch and the one most likely to quietly cap what you earn from it.

Here is the part almost nobody explains up front: deliverability is split responsibility. Your course platform authenticates the mail it sends from its own servers. But the moment you send from your own domain — a custom “from” address, your own email tool, a connected sending domain — the technical burden shifts to you. This guide is about that half. What the DNS records actually prove, what Gmail and Yahoo now demand from anyone sending at volume, and how to tell whether your platform already covers you or you are the one on the hook.

Why good emails get filed as spam before they are read

Mailbox providers decide where a message lands mostly on who sent it, not what it says. Every sending domain and IP carries a reputation score built from past behavior: how many recipients marked it as spam, whether the mail was authenticated, whether the sending patterns look human or bot-like. Content filtering (the “spammy words” people worry about) is a small, late step. If your domain sends unauthenticated mail, the inbox has no way to confirm the message really came from you, so it treats it with suspicion — and a single bad launch can dent a reputation that takes weeks to rebuild.

This is why the fix is almost always structural, not editorial. Rewriting your subject line will not help if the underlying domain cannot prove it is allowed to send. That proof lives in three DNS records.

The three records that vouch for your mail

SPF, DKIM, and DMARC are not interchangeable and they are not optional extras. Each answers a different question the receiving server asks before it decides where your email goes.

• SPF (Sender Policy Framework) lists which mail servers are allowed to send on behalf of your domain. If mail arrives from a server that is not on the list, that is a warning sign.
• DKIM (DomainKeys Identified Mail) adds a cryptographic signature so the receiver can confirm the message was not altered in transit and really came from an authorized signer.
• DMARC (Domain-based Message Authentication) tells the inbox what to do when SPF or DKIM fail, and — just as usefully — sends you reports on who is sending mail using your domain.

Here is what each one does and who sets it up, with a minimal working example. These values were confirmed against the providers’ own documentation (checked September 2026); yours will differ because the servers named depend on your platform or email tool.

Record	What it proves to the inbox	Who configures it	What a minimal record looks like
SPF	Which servers may send for your domain	You publish it; your platform/ESP tells you the value	v=spf1 include:_spf.google.com include:sendgrid.net -all
DKIM	The message was not altered and came from an authorized signer	Platform/ESP generates the key; you publish the record it gives you	selector._domainkey → TXT/CNAME value from your sender
DMARC	What to do on failure, plus where to send reports	You publish it in DNS	v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
Reverse DNS (PTR)	The sending IP maps back to a real hostname	Your host/ESP (already handled on shared sending IPs)	Set by the mail host, not by you

Start DMARC at p=none. That policy changes nothing about how your mail is treated — it just switches on the reports so you can see every source sending under your domain before you tighten to quarantine or reject later.

What Gmail and Yahoo now require

Since February 2024, the two largest consumer inboxes enforce a baseline, and they split it by volume. According to Google’s email sender guidelines (checked September 2026), every sender must authenticate with SPF or DKIM, have valid reverse DNS, transmit over TLS, and keep the spam-complaint rate below 0.3% as measured in Postmaster Tools.

Cross about 5,000 messages a day to Gmail addresses and you become a “bulk sender,” with stricter rules: SPF and DKIM both, a published DMARC policy (p=none is enough to satisfy it), alignment between your “from” domain and your SPF or DKIM domain, and one-click unsubscribe in marketing mail. Yahoo’s sender best practices (checked September 2026) mirror this almost exactly, and add that you should honor unsubscribe requests within two days and include a rua reporting tag on your DMARC record.

The 5,000-a-day line matters more than it looks. A creator with a 10,000-person list who emails the whole list twice during a launch week can clear that threshold on those days even if their normal volume is tiny. The rules apply to the day, not your average.

Does your course platform handle this, or do you?

This is the question that decides how much of the above is your problem. There are three common setups, and they are not equal.

1. You send from the platform’s own sending domain

If your emails go out with a “from” address on the platform’s infrastructure, the platform authenticates them. SPF, DKIM, and reputation are theirs to manage. You benefit from that shared reputation and you have almost nothing to configure. This is the safest default for a new creator with a small list, and there is no shame in staying here.

2. You use a custom “from” address on your own domain

The moment you brand the sender — the same instinct behind mapping a custom domain to your school — you take on authentication. The platform will hand you SPF and DKIM values to publish in your DNS; if you skip that step, your branded mail sends unauthenticated and lands in spam faster than the platform’s default ever would. A custom sender that is not authenticated is worse than no custom sender.

3. You send through an external email tool

If a dedicated tool sends for your domain, you publish that tool’s SPF and DKIM records plus your own DMARC. Whichever email marketing tool you choose will document the exact records; the work is real but one-time. This is the setup most serious creators end up in, because it is also where the deliverability reporting is best.

So who actually needs to care? If you are on setup 1 with a list under a few thousand, you can defer almost all of this. If you are on setup 2 or 3, or your list is large enough that a launch pushes you past 5,000 sends in a day, it is not optional — it is the difference between a launch and a launch nobody sees.

A one-hour setup that survives your next launch

You do not need to become a DNS expert. You need to do six things once, in order, and then leave them alone.

1. Find out what domain your mail really sends from. Open a recent email you sent and check the “from” and the signing domain. That tells you which of the three setups above you are in.
2. Publish the SPF and DKIM records your platform or tool gives you. Copy them exactly into your DNS host; a single stray character breaks the record.
3. Add a DMARC record at p=none with a rua address so reports start flowing. Read a week of them before you tighten the policy.
4. Warm up gradually if the domain or list is new. Sending to 10,000 cold addresses on day one from a fresh domain is the single fastest way to earn a spam reputation.
5. Send a seed test to your own Gmail, Yahoo, and Outlook addresses before every launch and confirm placement, not just delivery.
6. Watch your spam rate in Postmaster Tools and keep it under 0.3%. If it climbs, stop and diagnose before the next send, because reputation damage compounds.

If your launch mail is built as automated email sequences, run this check once against the sending domain and it protects every campaign that flows through it afterward.

When “it works on my end” is not enough

Deliverability is a setup task disguised as a maintenance chore. Configure the three records correctly, keep your list clean, and stay under the complaint threshold, and it stops being something you think about. Ignore it, and you will keep paying an invisible tax on every launch — a slice of your audience that never sees the offer, and a sender reputation that quietly gets harder to repair each time. For a creator whose income depends on a few launches a year, that is the last place to leave money on the table.