Stop rewriting the launch email that went to spam. Check SPF, DKIM and DMARC first.

Launch week, you send the email to your waitlist. A few people reply, most don't, and a friend messages you two days later: "found it in spam btw."

The usual reaction is to rewrite the subject line. Fewer exclamation marks, drop the word "free", try again. Sometimes that's the problem. But a lot of the time the inbox provider never got far enough to read your subject line. It looked up your domain in DNS, didn't like what it found (or found nothing), and made its decision there.

So before you touch the copy, check three records. It takes about five minutes and it's the part most small teams never look at until something breaks.

The three records, in plain words

• MX says where mail to your domain goes. It doesn't prove anything about mail you send, but a domain with no MX looks half set up, and replies to your launch email need somewhere to land.
• SPF is a TXT record that lists which servers are allowed to send mail as your domain. Your email provider, your newsletter tool, your support desk, your app's transactional mail service. If a sender isn't on the list, receivers can treat that mail as suspicious.
• DMARC is a TXT record at _dmarc.yourdomain.com that tells receivers what to do when a message fails the checks (p=none, p=quarantine or p=reject) and where to send reports about it (rua=).

There's a fourth, DKIM, which is a signature your sending service adds to each message, with the public key published in DNS under a "selector". More on that one below, because it's the one people check wrong.

This isn't optional hygiene anymore. Since February 2024 Gmail has asked everyone sending to Gmail addresses to set up SPF or DKIM, and bulk senders (around 5,000+ messages a day to Gmail) need SPF, DKIM and DMARC. Yahoo announced the same, and Microsoft started enforcing similar rules for high-volume senders to Outlook.com in 2025. You're probably not a bulk sender on launch day. You're still being judged by a system built around those rules.

Check 1: is there exactly one SPF record?

Look up the TXT records on your root domain and find the one that starts with v=spf1.

The mistakes I'd look for, in order:

1. No SPF record at all. Common on domains where someone set up Google Workspace years ago and then added a newsletter tool without touching DNS.
2. Two SPF records. Each new tool's setup guide says "add this TXT record", so you end up with v=spf1 include:_spf.google.com ~all and a second v=spf1 include:sendgrid.net ~all. That's not two permissions. The SPF spec says more than one record is a permanent error, so neither counts. Merge them into one record with both include: parts.
3. Ending in +all or ?all. +all means "anyone on the internet can send as me", which defeats the point. ?all means "no opinion". You want ~all (soft fail) or -all (fail).

Check 2: are you under the 10-lookup limit?

This is the one that bites growing products. SPF allows at most 10 DNS lookups while evaluating your record. Every include:, a, mx, exists and redirect costs one, and includes inside includes count too. ip4: and ip6: don't.

Each tool you add brings its own include, and some of those includes pull in more. Go past 10 and SPF returns a permanent error, which to a receiver looks a lot like having no SPF at all. Nothing on your side tells you. Mail just quietly gets worse.

If you're close to the limit, remove includes for tools you stopped using (there's always one), and ask whether your newsletter tool can send from a subdomain like news.yourdomain.com with its own SPF record instead of piling onto the root.

Check 3: does a DMARC record exist, and what does it say?

Look up TXT at _dmarc.yourdomain.com. A lot of small domains simply have nothing there, and you won't notice until you look.

If you're starting from zero, a sane first record is:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Be honest with yourself about what that does: p=none is monitoring only. It tells receivers "don't do anything different, just send me reports". That's the right first step, because the reports show you which services are sending as your domain that you forgot about. It isn't protection. Once the reports show your real senders passing, move to p=quarantine and later p=reject. You can use pct= to apply the policy to a share of failing mail while you ramp, and sp= sets the policy for subdomains if they should differ.

About DKIM: you need the selector

DKIM keys live at <selector>._domainkey.yourdomain.com, and there's no DNS query that lists the selectors a domain uses. Each provider picks its own name. So any checker that says "no DKIM found" without asking you for a selector is guessing.

Find the selector in your provider's DNS setup page (it's the part before ._domainkey in the record they told you to add), or open a message you sent, view the original, and read the s= value in the DKIM-Signature header. Then check that exact name.

The five-minute version

Checking all this with dig and a browser tab of RFCs gets old fast, so we built a small free email DNS checker on Uno Directory, one of my sites. You type a domain or an email address and it looks up MX, SPF (with the count against the 10-lookup limit and flags for missing, duplicate, +all or ?all records) and DMARC (reading p=, sp=, pct= and rua, and flagging p=none as monitoring only). DKIM is optional and only runs if you type your selector, because it doesn't guess. No signup.

Two real results from when it went live, to show what good and empty look like:

• google.com: MX points to smtp.google.com, SPF is v=spf1 include:_spf.google.com ~all using 1 of the 10 top-level lookups, and DMARC is p=reject with reporting turned on.
• neverssl.com: no MX (only A/AAAA records, so some senders may fall back to those), no SPF, no DMARC.

Most small product domains I'd expect to sit somewhere between those two. Use whatever tool you like, dig works fine. The point is to look before you rewrite the email.

What DNS won't fix

Passing all of this gets you considered, not delivered. A few things records can't help with:

• A list full of throwaway addresses. Bounces and dead inboxes hurt you with every provider. I wrote about checking a waitlist for temp-mail before launch day, and it's worth doing before the same send.
• Mailing people who never asked. Gmail's guidelines want spam complaint rates kept under 0.3%. A brand new domain blasting a scraped list will burn regardless of DNS.
• Sending everything at once from a cold domain. If the domain has never sent mail, ramp up over a few days rather than sending to the whole list at 9am launch morning.
• No unsubscribe link. Bulk senders need one-click unsubscribe now, and even small senders get marked as spam by people who can't find the way out.

My order of operations before a launch email

1. Look up SPF. Exactly one record, ends in ~all or -all, every tool that sends as you is in it.
2. Count lookups. Under 10, with some room for the tool you'll add next month.
3. Look up DMARC. If nothing's there, add p=none with a rua address today, so you have a week of reports before launch.
4. Check DKIM with the real selector for each sending service.
5. Send a test to a Gmail address you own, open "Show original" and confirm SPF, DKIM and DMARC all say PASS.
6. Then, and only then, argue about the subject line.

Which one was missing on your domain when you last checked: SPF, DKIM or DMARC? And did you find a forgotten tool still sending as you?