The Four Horsemen of Email Deliverability

Why your emails end up in spam — and how to stop it

You wrote the email. You hit send. And it vanished — straight into spam, or never arrived at all. No opens, no replies, no idea why.

If that sounds familiar, you’re probably missing one or more of four DNS settings that most small website owners have never had to think about. Fix them, and your emails start landing where they’re supposed to. Leave them broken, and even your best content goes nowhere.

And fair warning: even when everything is set up correctly, email deliverability isn’t always a simple fix. Reputation takes time to build, some problems live on the recipient’s side, and occasionally there’s no obvious explanation at all. This guide will walk you through everything you can actually control.

Why This Keeps Happening

Every email you send travels via SMTP — Simple Mail Transfer Protocol. It’s the delivery system of the internet, the set of rules that moves an email from one server to another until it reaches someone’s inbox.

The problem is that when you use a tool like MailerLite, Mailchimp, or Constant Contact, those platforms send emails from their servers — but with your domain name in the From field. Your subscriber sees hello@yourbusiness.com, but the email actually came from MailerLite’s infrastructure.

Gmail and Outlook have no way of knowing that’s legitimate. As far as they’re concerned, some random server is claiming to be you. That’s exactly what a spammer does. So they treat it like spam.

The four settings below fix this. They’re added to your domain’s DNS — the same place you’d point your domain to a web host. They tell receiving servers: “Yes, I authorised these systems to send on my behalf.”

A Practical Example

Say your domain is hosted at Dreamhost and your business email runs through Google Workspace. You also send newsletters through MailerLite and use MailPoet on your WordPress site for automated emails.

That’s three different systems all sending email as you. Every one of them needs to be authorised — and the four settings below are how you do it.

The Four Horsemen

1. MX — Where Your Incoming Mail Goes

MX stands for Mail Exchange. It tells the internet which server should receive emails sent to your domain.

If your business email is on Google Workspace, your MX record needs to point to Google’s servers (smtp.google.com). In Dreamhost, you set this in their Custom MX Records panel. Get it wrong and replies to your emails bounce — or disappear entirely.

This is the foundation. Everything else is about proving outgoing emails are legitimate, but MX is what makes sure replies actually find you.

2. SPF — Who’s Allowed to Send as You

SPF stands for Sender Policy Framework. It’s a list of servers that are officially allowed to send email from your domain.

Think of it as the guest list at the door. If an email arrives from a server that isn’t on the list, inbox providers treat it with suspicion.

If you use Google Workspace, MailerLite, and Mailchimp, all three need to be on that list — merged into a single SPF record:

v=spf1 include:_spf.google.com include:_spf.mlsend.com include:servers.mcsv.net ~all

The most common mistake: adding a second SPF record instead of editing the existing one. You can only have one. Two SPF records cancel each other out and break everything.

3. DKIM — Proof the Email Wasn’t Tampered With

DKIM stands for DomainKeys Identified Mail. It adds an invisible signature to every email you send — like a wax seal on a letter. The recipient’s mail server checks the seal to confirm the email genuinely came from you and hasn’t been altered in transit.

Every sending platform generates its own DKIM key. Google’s goes in as a long TXT record in your DNS — a wall of random characters that you copy and paste exactly as given. MailerLite does it differently: they give you a CNAME record that points to their servers, where they host the key themselves. That means if MailerLite ever updates their keys, your DNS stays the same. Both approaches work fine — the receiving server just needs the signature to check out.

In Dreamhost, you’ll end up with a mix: a TXT record named google._domainkey and a CNAME named litesrv._domainkey. That’s normal and correct.

To generate your Google DKIM key:

Go to admin.google.com
Go to Apps → Google Workspace → Gmail
Click Authenticate email
Select your domain from the dropdown
Click Generate new record
Copy the value it gives you — it’ll start with v=DKIM1; k=rsa; p=...

Then add it to your Dreamhost DNS as a TXT record with the name google._domainkey.

4. DMARC — What Happens When Something Fails

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It tells receiving servers what to do when an email fails the SPF or DKIM checks — and it emails you reports so you can see what’s going on.

Start with a monitoring-only policy:

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

This doesn’t block anything yet — it just collects data and sends you reports. Even so, having it in place improves your standing with Gmail and Outlook. It tells them you’re paying attention.

After a few weeks, once you’ve confirmed your legitimate emails are all passing cleanly, you can tighten it to p=quarantine (suspicious emails go to spam) or p=reject (they’re blocked outright).

One Thing That Catches Everyone: DNS Propagation

Once you’ve added or changed a DNS record, it doesn’t take effect immediately. Changes can take anywhere from a few minutes to 48 hours to propagate across the internet — and during that window, some servers will see the new record and some won’t.

This is normal and there’s nothing you can do to speed it up. If you’ve made changes and things still look wrong, wait a few hours and check again before assuming something is broken. Use MXToolbox SuperTool to verify what’s live.

With the Four Horsemen in Place, Google Workspace Is All the SMTP You Need

WordPress’s built-in email system is unreliable. Contact form notifications, order confirmations, and password resets often go missing because WordPress sends them with no authentication. The usual fix people reach for is an SMTP plugin that bolts on a third-party sending service like Mailgun, Postmark, or SendGrid — adding another account to manage and another thing that can break.

But if your DNS is properly set up and you’re already on Google Workspace, you don’t need any of that. Point MailPoet at Google’s SMTP server directly. Because Google is already authorised in your SPF record, already has DKIM configured, and your domain has an active DMARC policy — everything sent through Google passes cleanly. No extra plugin, no third-party service, no additional cost.

The four horsemen are what make Google’s SMTP trustworthy. Without them, even Google’s servers can’t fully vouch for your domain. With them in place, Google Workspace is all the sending infrastructure most small sites will ever need.

One caveat: Google Workspace limits you to around 2,000 emails per day. For most small sites that’s plenty. If your list grows much larger, you’d move bulk campaigns to MailerLite or Mailchimp and keep transactional emails — confirmations, receipts, welcome sequences — running through Google.

API Keys: The Other Thing You’ll Need

Sorting out your DNS records proves your domain is legitimate. But connecting a newsletter platform to your website requires one more thing: an API key.

An API key is a long unique string that acts like a password — it lets a platform like MailerLite or Mailchimp communicate with your site without needing your actual login. You’ll paste it into your WordPress plugin settings, which is perfectly fine. It’s stored server-side, invisible to visitors, and only accessible to people with admin access.

What you want to avoid is accidentally putting it somewhere public:

A GitHub repository
A shared Google Doc
A support forum post
A screenshot on social media

A leaked API key can give someone access to your subscriber list or let them send emails as you. It’s not about someone hacking your server — it’s about being careless with something sensitive in a place you didn’t think about.

Most platforms keep API keys under Integrations, Developer API, or Account Settings. If one gets exposed, regenerate it immediately.

Test Before You Send

Before blasting out a campaign, send a test email to Mail Tester. It gives you a spam score out of 10 and tells you exactly what’s passing or failing — DNS records, content issues, blacklist status, all of it in one place. Aim for 9 or 10 before sending to a real list.

It’s also worth sending a test to both a Gmail address and an Outlook address. The two platforms have different filtering behaviour and what lands cleanly in one doesn’t always land cleanly in the other.

Still Not Arriving? Work Through This List

DNS records solve the authentication problem, but emails can go missing for other reasons too. If you’ve got the four horsemen in place and things still aren’t working, go through these one by one.

Start with the obvious

Ask the recipient to check their spam or junk folder — it might be there waiting
Ask them to whitelist your domain or add your address to their contacts
Check your own sent folder in Google Workspace to confirm the email was actually sent
Check whether the action that triggers the email actually fired — form submissions, order completions, and sign-ups can silently fail

Verify your DNS is actually working

Run your domain through MXToolbox SuperTool to check your MX, SPF, DKIM, and DMARC records are all present and valid. DNS changes can take up to 24 hours to propagate — if you just made changes, give it time and check again.

Check if your sending IP or domain has been blacklisted: MXToolbox Blacklist Check. If you’re on a shared host, another site on the same IP may have caused the problem — this is more common than people realise.

WordPress and WooCommerce specifics

WordPress has no built-in email log, so you often can’t tell whether an email was sent at all. Install WP Mail Logging or Email Log — these capture every email WordPress attempts to send, including headers and delivery status. This is the fastest way to diagnose whether the problem is WordPress not sending, or emails being sent but rejected
WooCommerce emails have individual on/off toggles. Go to WooCommerce → Settings → Emails and check that the specific email type (new order, order complete, etc.) is actually enabled and pointed at the right address
Check your contact form plugin settings — Gravity Forms, WPForms, and Contact Form 7 all have their own notification configurations. The “to” address may be wrong, or the form may not be submitting at all
Make sure the From address in WordPress matches your actual domain. Sending from a generic Gmail address while using a custom domain is a red flag for spam filters — keep them consistent. The same goes for using a free email address like @gmail.com or @yahoo.com as your sender — inbox providers expect business email to come from a real domain

Watch out for same-domain sending

This catches a lot of people on shared hosting like Dreamhost. If you’re sending from hello@yourdomain.com to hello@yourdomain.com — say, a contact form notification going to the same address it’s sent from — Gmail in particular gets confused. It sees the email as coming from itself and can silently drop it or loop it. Use a different address as your notification recipient, or route to a separate inbox entirely.

Watch your email content too

DNS authentication proves you’re who you say you are — but spam filters also score the content of your emails. Things that hurt your score include heavy image-to-text ratios, lots of links, certain trigger words, and emails with no plain text version. Mail Tester will flag these.

Check for conflicts

If you use Wordfence, check Wordfence → Tools → Live Traffic around the time an email should have fired — it may be blocking a request that triggers the send. Also check Wordfence → Tools → IP Blocking to make sure your own server IP hasn’t been flagged
Caching plugins occasionally cause form submission issues
If SMTP isn’t configured and WordPress is falling back to PHP mail, it’ll almost always get flagged or dropped — this is the most common root cause on new or cheap hosting

Sender reputation takes time

Even with everything configured correctly, a brand new domain or one that hasn’t sent email in a long time will start with no reputation. Inbox providers don’t know you yet. Expect some deliverability friction for the first few weeks, and build gradually — small sends first, then larger ones as your reputation establishes itself.

Corporate recipients

If emails are reaching most people but not someone at a specific company, their IT department may be running aggressive server-level filtering that happens before anything reaches their inbox. There’s not much you can do about that from your end — they’d need to whitelist your domain on their mail gateway. Some corporate mail systems are locked down so tightly that even perfectly authenticated email from trusted senders gets blocked.

The Short Version

Your DNS records tell the world your emails are legitimate. Your API keys connect your tools together. Neither one replaces the other — you need both.

Get the four horsemen right and you’ll stop fighting the spam filter. Your newsletters will land in inboxes, your contact form emails will actually arrive, and your domain’s sending reputation will build steadily over time.

It’s a one-time setup. Do it once, do it properly, and then forget about it. And when something does go wrong — because sometimes it will — you’ll know exactly where to start looking.