How I Fixed My Emails Landing in Spam (And Why You're Probably Missing DNS Records)

Software Engineering
#google-workspace#email#dns#devops#entrepreneurship

My emails were going to spam. Not some of them—most of them. Client correspondence from keithgstewart.com, transactional emails from stackday.app, even basic replies from adhdcoachmatch.com. All spam folder material, despite paying for Google Workspace.

Turns out, having Google host your email doesn't mean Google trusts your email. You need to prove it with three DNS records (SPF, DKIM, DMARC) that I'd completely neglected, plus a handful of other spam filter requirements I didn't know existed.

Here's how I went from spam folder to 10/10 mail-tester.com score, what I got wrong initially, and why managing multiple domains isn't as expensive as you think.

The "Wait, Do I Need Multiple Google Workspace Accounts?" Revelation

First confusion: I have three domains (keithgstewart.com, stackday.app, adhdcoachmatch.com). Do I need three separate Google Workspace accounts at $7-14/month each?

No. Google Workspace charges per user, not per domain. You can add unlimited domains as "domain aliases" and every user automatically gets email addresses on all domains. One $7/month Business Starter account gets you keith@keithgstewart.com, keith@stackday.app, and keith@adhdcoachmatch.com from a single inbox.

The catch? Each domain needs its own authentication records. Google won't just trust your aliases because you added them in the admin panel.

What Actually Authenticates Your Email

Three DNS records prove your emails aren't spoofed:

SPF (Sender Policy Framework) - Lists which servers can send email for your domain
DKIM (DomainKeys Identified Mail) - Digital signature proving emails weren't tampered with
DMARC (Domain-based Message Authentication) - What to do with emails that fail the above checks

Here's why this matters: email's SMTP protocol has no built-in sender verification. Anyone can connect to a mail server and claim to be from any domain—it's trivially easy to spoof without these records. SPF, DKIM, and DMARC exist to cryptographically prove domain ownership. Spam filters treat missing authentication as a phishing signal because attackers spoofing protected domains will fail these checks. Google reports a 65% reduction in unauthenticated messages reaching Gmail users after enforcing these requirements in 2024.

The Resend Mistake I Made First

I use Resend for some transactional emails. Early guidance I found said to add include:_spf.resend.com to my SPF record.

That include doesn't exist. I spent 30 minutes debugging SPF validation failures before realizing Resend doesn't work that way.

Resend uses a subdomain approach: you configure something like send.stackday.app with its own SPF and MX records. Your main domain's SPF never mentions Resend. The subdomain handles it independently.

# Wrong - this breaks SPF validation
v=spf1 include:_spf.google.com include:_spf.resend.com ~all

# Right - Resend goes on a subdomain
# Main domain: v=spf1 include:_spf.google.com ~all
# send.stackday.app subdomain: v=spf1 include:amazonses.com ~all

Always check the actual service documentation. Third-party email services handle authentication differently—some use includes, some use subdomains, some use custom domains entirely.

The Three-Step Fix (Per Domain)

1. SPF - Who Can Send Email

Add this TXT record to each domain:

Type: TXT
Host: @
Value: v=spf1 include:_spf.google.com ~all

The ~all at the end means "softfail" - mark suspicious emails but don't reject them outright. Google recommends this over -all (hardfail) because misconfigurations won't completely break your email.

Critical: If you use other email services (SendGrid, Mailchimp, etc.), add their includes before ~all:

v=spf1 include:_spf.google.com include:amazonses.com ~all

2. DKIM - Cryptographic Proof

Navigate to Google Admin Console → Apps → Google Workspace → Gmail → Authenticate email

For each domain:

  1. Select the domain from the dropdown
  2. Click "Generate new record"
  3. Choose 2048-bit key length (1024-bit only if your DNS provider can't handle longer keys)
  4. Copy the TXT record Google provides
  5. Add it to your DNS with host google._domainkey
  6. Wait for DNS propagation (15-30 minutes usually)
  7. Return to Google Admin and click "Start authentication"

The gotcha: You need to generate a separate DKIM key for each domain alias. They can't share keys. Set up your primary domain, then repeat this entire process for every alias.

3. DMARC - Enforcement Policy

Add this TXT record to each domain:

Type: TXT
Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100

Start with p=none (monitor only). This lets you collect reports for 1-2 weeks without risking legitimate email getting blocked.

After verification that everything passes:

  • Week 2-3: p=quarantine; pct=10 (quarantine 10% of failing emails)
  • Week 4-5: p=quarantine; pct=100 (quarantine all failing emails)
  • Week 6+: p=reject (reject all failing emails)

The rua email will get a lot of reports. Use a dedicated mailbox or a third-party DMARC monitoring service, not your personal inbox.

The MX Record Update (Simplified in 2023)

Google changed their MX recommendation in April 2023. Old docs show five separate MX records. New recommendation: one record.

Type: MX
Host: @
Priority: 1
Value: smtp.google.com

If you already have the five legacy records (ASPMX.L.GOOGLE.COM, ALT1-4.ASPMX.L.GOOGLE.COM), they still work fine. Google supports both indefinitely. But for new setups, just use the single record.

Testing: Headers Over Diagnostic Tools

Google Admin Toolbox (toolbox.googleapps.com) is useful but throws false positives. I had everything configured correctly and it still showed warnings.

The real test: Send yourself an email, view the original message, and check the headers.

Look for these three lines:

SPF: PASS
DKIM: PASS
DMARC: PASS

If all three say PASS, you're good. Everything else is noise.

Also useful: mail-tester.com gives a spam score out of 10. Aim for 9-10.

Beyond DNS: The Other Signals That Matter

Getting SPF, DKIM, and DMARC passing brought my mail-tester.com score from failing to about 7/10. Still not great. Turns out authentication is necessary but not sufficient—spam filters check a lot more than just DNS records.

Here's what else I had to fix to hit 10/10:

Subject Line Spam Triggers

SpamAssassin (the spam detection engine) flags certain words as suspicious. I was using "Claim Your Profile" and "Confirm Opt-Out" in subject lines. Both failed.

Spam trigger words I removed:

  • "Claim" (sounds like a prize/scam)
  • "Verify" (phishing red flag)
  • "Confirm" + "Opt-Out" together (double negative pattern)

What worked instead:

❌ "Claim Your Profile" 
✅ "Your ADHD Coach Match Profile is Ready"

❌ "Confirm Opt-Out from Directory"
✅ "ADHD Coach Match Profile Settings"

The pattern: be specific, be positive, avoid words that scammers overuse. "Settings" beats "opt-out." Your actual product name beats generic "your profile."

CAN-SPAM Compliance

The CAN-SPAM Act (yes, it's actually called that) requires commercial email to include:

  1. A physical mailing address in the footer
  2. Clear opt-out instructions
  3. Accurate sender information

Missing any of these is both illegal and will tank your spam score.

Plain text and HTML versions required. The physical address can be your office, a registered agent, or a PO Box—just needs to be a valid mailing address where you can receive postal mail.

List-Unsubscribe Headers

Gmail and Outlook show an "Unsubscribe" button at the top of emails if you include proper headers. This is good for you—users can unsubscribe without marking you as spam, which preserves your sender reputation.

Add these headers to every marketing/bulk email:

List-Unsubscribe: <https://yoursite.com/unsubscribe?token=xyz>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

The List-Unsubscribe-Post header enables one-click unsubscribe (RFC 8058). When someone clicks "Unsubscribe" in Gmail, it POSTs to your URL immediately instead of making them click through to a page.

Don't skip this. Gmail and Yahoo now require one-click unsubscribe for bulk senders. Missing it = rejected mail.

Sender Name Format

I was sending from just support@adhdcoachmatch.com. Spam filters prefer the RFC 5322 format with a display name:

From: ADHD Coach Match <support@adhdcoachmatch.com>

Consistent sender branding across all emails. Pick one format and stick with it—changing your "From" name frequently looks suspicious.

The 10/10 Result

After all these changes:

  • ✅ Authentication: SPF/DKIM/DMARC passing
  • ✅ Subject lines: No spam triggers detected
  • ✅ CAN-SPAM: Physical address + opt-out present
  • ✅ List-Unsubscribe: One-click enabled
  • ✅ Sender format: RFC 5322 compliant
  • ✅ SpamAssassin: 0.0 spam score
  • ✅ Mail-Tester: 10/10

DNS authentication gets you in the game. These other signals actually get you in the inbox.

The Domain Alias Authentication Trap

Here's what bit me: I set up SPF, DKIM, and DMARC on keithgstewart.com (my primary domain) and assumed the aliases would inherit the authentication.

They don't.

Each alias needs:

  • Its own SPF TXT record
  • Its own DKIM key (generated separately in Google Admin)
  • Its own DMARC TXT record

For DMARC alignment with aliases, DKIM is your friend. SPF alignment will fail for alias domains because the Return-Path uses your primary domain—this is expected and fine. DKIM alignment is what gets you DMARC compliance on aliases.

What This Actually Cost

DNS Authentication:

  • Time: ~2 hours from discovery to fix
  • Money: $0 (just DNS configuration)
  • DNS propagation: 15-30 minutes per domain

Additional Deliverability Improvements:

  • Time: ~3-4 hours (subject line testing, footer updates, header implementation)
  • Money: $0 (code changes only)
  • Testing iterations: 5-6 mail-tester.com runs to dial everything in

Total investment: One afternoon of work, zero dollars. Google Workspace at $7/month handles unlimited domains via aliases.

Final Checklist (Copy This)

For each domain you own:

DNS Authentication:

☐ SPF record: v=spf1 include:_spf.google.com ~all
☐ DKIM key generated in Google Admin Console
☐ DKIM TXT record published to DNS
☐ DKIM authentication started in Google Admin
☐ DMARC record: v=DMARC1; p=none; rua=mailto:dmarc@domain.com; pct=100
☐ MX record: smtp.google.com (priority 1)

Email Content & Headers:

☐ Subject lines free of spam triggers (no "claim", "verify", "confirm")
☐ Physical mailing address in email footer (CAN-SPAM)
☐ Clear unsubscribe instructions in footer
☐ List-Unsubscribe header with one-click support
☐ Sender format: "Your Brand <email@domain.com>" (RFC 5322)
☐ Plain text and HTML versions of all emails

Testing:

☐ Test email sent and headers checked (SPF/DKIM/DMARC: PASS)
☐ mail-tester.com score ≥ 9/10
☐ SpamAssassin score = 0.0
☐ No blacklist warnings

What I'd Do Differently

Start with DMARC on p=none immediately, even before full configuration. The reports would have shown me exactly which records were missing instead of me guessing at SPF syntax.

Also: run mail-tester.com BEFORE deploying to production. I assumed DNS authentication was all I needed. One test email would have caught the subject line spam triggers and missing CAN-SPAM footer immediately, saving me from sending potentially flagged emails to real users.

And don't trust third-party guides about email service configurations. Resend's own docs were accurate; random blog posts about "how to configure Resend with SPF" were not.

If You're Still Landing in Spam

Check these in order:

  1. View actual email headers - Ignore diagnostic tools until you see what's actually failing
  2. Run mail-tester.com - Shows everything at once: authentication, spam triggers, blacklists
  3. Check subject lines - Search your subject text + "spam trigger" to see if you're using flagged words
  4. Verify CAN-SPAM compliance - Physical address in footer? Unsubscribe link present?
  5. Test List-Unsubscribe headers - Send yourself an email in Gmail, verify the unsubscribe button appears
  6. Verify each domain alias separately - Your primary domain working ≠ aliases working
  7. Wait for DNS propagation - 48 hours for DKIM activation is normal
  8. Check blacklists - MXToolbox will show if your domain/IP is listed
  9. Review DMARC reports - They'll tell you exactly what's failing authentication

The inbox is a much better place for your emails than the spam folder. DNS authentication gets you halfway there—the rest is subject lines, footers, and headers.

Having issues with email authentication? Run mail-tester.com first. The actual error messages beat guessing every time.