Guide
How Email Routing Actually Works
Your Outlook sends email fine. Your website's order confirmations land in spam. Here's why those are two completely separate problems.
You run a small online store. You set up Google Workspace so your team can send email from hello@yourstore.com. Everything works. Customers reply, you reply back, life is good.
Then a customer mentions they never got their order confirmation. You check, and sure enough, WooCommerce sent it. You test it yourself and find the confirmation sitting in your spam folder. Which is confusing, because email from your domain works perfectly well when you send it from Gmail.
This is probably the single most common email authentication problem for small businesses, and it comes down to something that isn't obvious at all until someone explains it: your domain has one inbound path for receiving email, but it can have many separate outbound paths for sending email. And each of those outbound paths needs its own authentication set up in your DNS, independently of the others.
One door in, many doors out
When someone sends an email to you, email routing is simple. Their mail server looks up your domain's MX record (MX stands for "mail exchanger" - it's a DNS record that says "deliver mail for this domain to this server"). That record points to one destination. If you use Google Workspace, it points to Google's mail servers. If you use Microsoft 365, it points to Microsoft's. One record, one destination. Done.
Outbound email - mail sent from your domain - is where things get complicated. Because you probably send email from your domain through several different systems, and each one goes out through a completely different server.
Inbound vs. Outbound Email Paths
Inbound mail (simple)
One path. One destination.
Outbound mail (complicated)
Each path needs its own SPF + DKIM.
Think of it this way: when you compose an email in Gmail and click send, that email leaves through Google's servers. When your WordPress site sends an order confirmation, that email leaves through your web host's mail server (or through whatever SMTP plugin you've configured). When Mailchimp sends your newsletter, it leaves through Mailchimp's servers. These are all separate systems, run by separate companies, on separate infrastructure.
The receiving mail server - the one at your customer's end - checks each incoming email against your domain's DNS records to decide whether that particular server was actually authorized to send on your behalf. If it wasn't, the email looks like a forgery, and it goes to spam. That authorization comes from two DNS records called SPF and DKIM.
SPF (Sender Policy Framework) is a DNS record that lists every server allowed to send email for your domain. DKIM (DomainKeys Identified Mail) is a cryptographic signature that each sending service stamps onto the email, with a matching public key published in your DNS. Together, they tell the receiving server: "Yes, this email really came from a system we authorized."
Here's the thing: you need both of these set up for every outbound path. If you only set up SPF and DKIM for Google Workspace, then only emails sent through Google are authenticated. Your website emails, your CRM emails, your newsletter emails - they're all flying without a seatbelt.
A real-world example
Let's say you run a small business with this setup, which is extremely common:
Google Workspace for day-to-day email (you and your team send from Gmail), WooCommerce on WordPress for your online store (sends order confirmations, shipping updates, password resets), and Mailchimp for your monthly newsletter.
That's three outbound email paths. Each one needs its own records.
Three Services, Three Sets of DNS Records
| Service | SPF Include | DKIM Record |
|---|---|---|
| Google Workspace | include:_spf.google.com | google._domainkey TXT |
| WooCommerce via Brevo | include:sendinblue.com | Brevo CNAME records |
| Mailchimp | include:servers.mcsv.net | Mailchimp CNAME records |
All three SPF includes go into the same single SPF record. DKIM keys are separate DNS records, one per service.
Your finished SPF record ends up looking something like this:
v=spf1 include:_spf.google.com include:sendinblue.com include:servers.mcsv.net ~allOne SPF record containing all three includes. Then three separate DKIM records, one for each service. If you skip any of them, that particular outbound path fails authentication.
The website path is the one that breaks
In practice, the outbound path that's most commonly unauthenticated is the website. Google Workspace walks you through SPF and DKIM setup when you activate it. Mailchimp asks you to verify your domain and gives you the DNS records. These services make you do the work up front.
Your website, on the other hand, just starts sending email the moment you install WordPress or Shopify. Nobody prompts you to set anything up. WordPress, by default, uses PHP's built-in mail() function, which sends email through whatever mail server your hosting provider runs. That server almost certainly isn't listed in your SPF record, and it almost certainly isn't signing emails with a DKIM key for your domain.
So your website's emails - order confirmations, contact form submissions, password reset links, the emails your customers actually need - go out unauthenticated. The receiving server sees an email claiming to be from yourstore.com, checks the SPF record, doesn't find the hosting server listed, checks for a DKIM signature, doesn't find one, and flags the email as suspicious. Spam folder.
This is why someone can say "email works fine for me" while customers report never getting their order emails. The person saying it works is sending from Gmail, which is authenticated. The website is sending through a completely different path that isn't.
The fix is to either configure your hosting provider's mail server properly in your DNS (which is often not possible on shared hosting) or - more reliably - install a plugin like WP Mail SMTP that routes your website's email through a dedicated transactional email service like Brevo, SendGrid, or Amazon SES. Then you add that service's SPF include and DKIM key to your DNS, and the website path becomes authenticated.
Before and After: Fixing the Website Path
Before
Marked as spam
After
Delivered to inbox
Frequently asked questions
If I set up Google Workspace, isn't my email already authenticated?
It's authenticated for email sent through Google's servers. So when you or your team hit send in Gmail, yes, that's covered. But your website, your CRM, your newsletter tool - those send through their own servers, not Google's. Google's SPF and DKIM records don't help those emails at all. Each service needs its own.
Do I need SPF and DKIM for every service I use to send email?
Yes. Every service that sends email using your domain name needs to be listed in your SPF record and should have its own DKIM key published in your DNS. If even one service is missing, emails from that service will fail authentication checks.
My hosting provider says they handle email. Does that mean my website emails are authenticated?
Probably not in the way you need. Most shared hosting providers can send email on your behalf, but they rarely set up DKIM signing for individual customer domains. Your SPF record might not include their mail server either. "We handle email" usually means "we have a mail server running," not "we've configured authentication records for your domain." It's worth checking specifically, or better yet, scanning your domain to see what the receiving servers actually see.
I installed WP Mail SMTP. Am I done?
The plugin is half the job. WP Mail SMTP reroutes your website's email through a service like Brevo or SendGrid instead of your host's mail server, which is good. But the service only becomes authenticated once you've added its specific DNS records - the SPF include and the DKIM key - to your domain. The plugin tells your website where to send email. The DNS records tell the rest of the world that the new destination is allowed to send on your behalf. You need both pieces.
How many outbound services is too many?
There isn't a hard limit on services, but there's a practical one. SPF records are checked through DNS lookups, and the SPF specification caps you at 10 DNS lookups per record. Each include: in your SPF record uses at least one lookup, and some services use nested includes that consume more than one. If you go over 10, your entire SPF record fails - for every service, not just the extra one. Most small businesses with two to four services are fine. If you're running more than that, it's worth counting your lookups.
What about transactional email services like Brevo or SendGrid?
They're another outbound path, same as everything else. When you sign up, they'll give you specific DNS records to add - usually an SPF include and one or two CNAME records for DKIM. Until you add those records, emails sent through the service will fail authentication for your domain. The good news is that these services are designed for deliverability, so once you do set up the records, your website emails typically land in the inbox much more reliably than they would through a shared hosting server.
If you're not sure which outbound paths are authenticated and which ones aren't, the fastest way to find out is to scan your domain. The scanner checks your SPF record, your DKIM keys, and your DMARC policy, and tells you exactly what's set up and what's missing.
Check Your Domain