Order confirmations are disappearing into spam folders. Shop owners blame their hosting. Designers blame the theme. But the real culprit is almost always email authentication: missing or misconfigured DKIM, SPF, or DMARC records (DNS records).

The underlying problem is that most people test it wrong. They send an email from their WooCommerce website to their own email account, see it arrive, and assume the problem is solved. But their email provider has already seen traffic from that domain, so anti-spam systems deliver it normally, even if the DNS records are incomplete or misconfigured.

This article shows you how to test it properly, identify what’s actually failing, and fix it. It’s a functional guide you can work through step by step, whether you’re a designer troubleshooting for a client or a shop owner trying to solve this yourself.

Why order confirmations disappear

Email authentication is how Gmail, Outlook, and other providers decide whether to trust an email. Three standards do most of the work:

SPF (Sender Policy Framework) tells the world which servers are allowed to send email from your domain. Without it, anyone can send emails claiming to be from your domain.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every email, proving it actually came from your domain and hasn’t been tampered with.

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM together and tells email providers what to do if an email fails both checks (deliver it anyway, quarantine it, or reject it outright).

If any of these are missing or wrong, email providers get suspicious. They might deliver the email to spam, or reject it entirely. Your shop owner loses the order confirmation, the customer never knows their order went through, and you’ve got a problem.

Why the self-test doesn’t work

Here’s what most people do:

Set up SPF and DKIM records in DNS
Send a test email from the website to their own Gmail account
See it arrive in the inbox
Assume the problem is solved

This test is a false positive. Google’s servers have already seen emails from your domain (maybe from your own email account, or from previous tests). Gmail’s anti-spam system recognises the domain and delivers the email normally, even if the authentication is broken.

A real test needs to simulate what happens when a stranger receives an email from your domain for the first time, with no prior relationship or history.

How to test it properly: three steps

Step 1: Send a test email to Gmail and read the headers

Send a test email from your WooCommerce site to a Gmail account (ideally one you don’t use for anything else, so Gmail has no history with your domain).

Once the email arrives, open it in Gmail and click the three dots in the top right. Select “Show original”. You’ll see the full email headers, including authentication results.

This is what you’re looking for:

GMail headers passed deliverability checks — All three checks should pass (SPF, DKIM & DMARC)

If any of them say FAIL or NEUTRAL, that’s the problem. Gmail delivered it anyway (because it’s Gmail and it’s lenient), but other providers might not be so forgiving.

What each result means:

PASS: The check succeeded. The email is authenticated.
FAIL: The check failed. The email is not authenticated.
NEUTRAL: The check couldn’t be completed (usually because the record is missing entirely).
SOFTFAIL: The check failed, but the domain owner says to deliver it anyway.

If you see FAIL or NEUTRAL on any of them, move to Step 2.

Step 2: Check your DNS records with mxtoolbox

Go to mxtoolbox.com and use their tools to validate your DNS records.

For SPF:

Click “MX Lookup” in the left menu
Enter your domain
Scroll down to “SPF Record”
You should see a single SPF record that includes your mail server and any third-party services (like Mailgun, SendGrid, or your hosting provider)

For DKIM:

Click “DKIM Lookup”
Enter your domain
Enter the selector (usually “default”, “mail”, or “website” — check your hosting provider’s documentation)
You should see a valid DKIM public key

For DMARC:

Click “DMARC Lookup”
Enter your domain
You should see a DMARC policy record

If any of these are missing or show errors, that’s what you need to fix.

Common issues mxtoolbox will flag:

SPF record is missing: Your domain has no SPF record at all. You need to add one.
SPF record has a syntax error: The record exists but it’s malformed (typo, wrong format, etc.).
DKIM record is missing: The selector doesn’t exist. Check that you’re using the right selector, or create one.
DKIM record has a syntax error: The record exists but it’s malformed.
DMARC record is missing: Your domain has no DMARC policy. You should add one.

Step 3: Fix the issues and re-test

Once you know what’s broken, fix it:

If SPF is missing or broken: Contact your hosting provider or email service and ask for the correct SPF record. Add it to your domain’s DNS. SPF records typically look like this:

v=spf1 include:_spf.headwall-hosting.com ~all

Note: If you’re hosting your website with Headwall Hosting, use include:_spf.headwall-hosting.com . For other providers, ask their support team for the correct SPF record.

If DKIM is missing or broken: This is where the WP Mail DKIM Signing plugin comes in. It lets you set up a proper DKIM selector without interfering with your hosting provider’s email setup.

Install the plugin, configure it with a selector (e.g., “website”), and it will generate a public key. Add that key to your DNS as a DKIM record. The plugin will then sign every email WooCommerce sends with that key.

If DMARC is missing: Add a basic DMARC policy to your domain. A simple one looks like this:

v=DMARC1; p=quarantine; rua=mailto:admin@yourdomain.com

This tells email providers to quarantine emails that fail both SPF and DKIM checks, and send you a report.

After you’ve made changes: Wait 5-10 minutes for DNS to propagate. Then go back to mxtoolbox and re-check your records. They should now show as valid.

Finally, send another test email to Gmail. Open it and check the headers again. All three should now say PASS.

Real example: a failing email

Let’s walk through a real scenario.

A WooCommerce shop owner sets up SPF and DKIM records, sends a test email to their own Gmail account, sees it arrive, and publishes the site. But customers start complaining that order confirmations aren’t arriving.

The shop owner sends a test email to a Gmail account they don’t normally use. It arrives, but when they check the headers, they see:

SPF: PASS
DKIM: NEUTRAL
DMARC: FAIL

DKIM is NEUTRAL because there’s no DKIM record (or the selector is wrong). DMARC is FAIL because DKIM failed.

They go to mxtoolbox and check DKIM. The tool says “No DKIM record found for selector ‘default'”. They check their hosting provider’s documentation and find that the correct selector is “mail”, not “default”.

They check again with selector “mail” and find a valid DKIM record. But their WordPress site is still signing emails with selector “default”, which doesn’t exist.

They install wpmail-dkim-sign, configure it with selector “mail”, and add the public key to DNS. They wait 10 minutes, send another test email, and check the headers again:

SPF: PASS
DKIM: PASS
DMARC: PASS

Problem solved. Order confirmations now arrive in customers’ inboxes.

When to reach out for help

If you’ve worked through all three steps and everything checks out, but emails are still going to spam, the problem might be:

Your domain’s reputation (if you’ve been sending a lot of spam, email providers will distrust it regardless of authentication)
Your hosting provider’s server reputation (perhaps due to other users on the same server)
A misconfiguration at the server level that requires hosting support to fix

At that point, it’s time to contact your hosting provider or a specialist. But 90% of the time, working through these three steps solves the problem.

Key takeaways

Test properly. Don’t just send an email to yourself. Use Gmail and read the headers.
Validate your records. Use mxtoolbox to check that SPF, DKIM, and DMARC are present and correct.
Use the right tools. The wpmail-dkim-sign plugin makes DKIM setup simple without interfering with your hosting provider’s email.
Wait for DNS to propagate. Changes to DNS records can take 5-10 minutes to take effect.
Re-test after changes. Don’t assume it’s fixed until you’ve sent another test email to a fresh Gmail account and verified all three checks pass in the headers.

If you’re a designer troubleshooting this for a client, you can hand them this guide and walk them through it step by step. If you’re a shop owner, work through it yourself or ask your designer to help. Either way, this is a problem you can solve without paying for expensive email services or switching hosting providers.

Email deliverability for WooCommerce: why order confirmations land in spam