WooCommerce has two failure modes that look identical to a customer, and the fix for one does nothing for the other: the store never sent the email, or it sent it from a web server that nothing authenticated. This guide separates the two using WooCommerce's own transactional email log, then covers the From address default that puts a personal Gmail address on your receipts, why the SPF record on your domain does not cover your web server, and what an SMTP sender actually changes. Then you place one real test order to an Unspam seed address and read what the inbox saw.
WooCommerce's Email and SMTP providers doc describes what happens next: since WordPress is not an email server it delegates the task to PHP, and PHP then locates a local email server on your web server to dispatch the email.
The From address under WooCommerce > Settings > Emails defaults to the site administrator email set in Settings > General, which on most stores is a personal address from setup day (the From name defaults to your site title). WooCommerce's documentation is blunt about the consequence: using an @gmail.com or @yahoo.com public domain address is likely to cause emails to land in spam or be blocked. Its authentication guide lists removing a Gmail address from the From header among the sender requirements that took effect on 1 February 2024. Change it to an address on the domain your storefront runs on.
WooCommerce defines Pending payment as an order received with no payment made, and its email FAQ states that no email is triggered for orders sitting in that status. When a payment gateway cannot call back to your site, orders pile up in Pending payment and customers get nothing, which is indistinguishable from a spam problem when you are looking at it from the outside. Check the order status before you touch DNS.
Most stores publish something like v=spf1 include:_spf.google.com ~all for Google Workspace or Microsoft 365 mailboxes. The web server is not in that list, so a receipt with From: orders@yourstore.com sent by PHP from the hosting IP fails SPF for your domain. With no DKIM signature either, DMARC has no aligned identifier to pass on. Adding the hosting IP to your SPF record is not the fix, because a shared IP would then authorize every other site on that machine to send as you.
WooCommerce's SMTP guidance says shared and virtual hosting environments are typically not optimal for sending email, and its authentication guide tells store owners to check with their host whether store mail is authenticated at all rather than assume it is.
The notification list under WooCommerce > Settings > Emails now includes Abandoned cart recovery and Review request alongside the order emails, and both are off by default: Review request needs Customer review request (beta) switched on at WooCommerce > Settings > Advanced > Features, and abandoned cart emails shipped in WooCommerce 11.0 (4 August 2026) as an experimental feature that must be enabled first. Turn either on and marketing messages start leaving on the same unauthenticated path, from the same domain, as your password resets. Mailbox providers score the domain rather than the message type, so complaints earned by cart reminders are paid for by transactional mail nobody complains about.
WooCommerce does not sign anything. It hands the finished message to wp_mail(), PHP hands it to whatever mail transport exists on the web server, and authentication becomes a property of the route rather than of WooCommerce. Two settings decide everything downstream: the From address under WooCommerce > Settings > Emails, and whether you have put an authenticated SMTP sender in front of PHP.
| record | default | the problem | the fix |
|---|---|---|---|
| SPF | Your domain almost certainly has an SPF record for your mailbox provider, and it does not include the server your store runs on. | Mail sent by PHP leaves from an IP your SPF does not authorize, so SPF fails for the From domain. If your host rewrites the envelope sender to an address on the hosting company's own domain, SPF can pass for that domain instead and still not align with your From header, which is a DMARC failure either way. | Send through an authenticated SMTP provider and publish the include it gives you, for example v=spf1 include:_spf.google.com include:sendgrid.net ~all. Keep exactly one SPF TXT record on the domain, because two invalidate each other, and never add a shared hosting IP. |
| DKIM | Nothing in the store signs it. Neither WordPress nor WooCommerce holds a signing key, so any signature has to come from your host's mail server, and WooCommerce tells store owners to confirm with the host whether store mail is authenticated at all rather than assuming it is. | With no DKIM signature and no aligned SPF, nothing on the message is tied to your domain. WooCommerce's authentication guide notes that all senders need SPF or DKIM, and that senders of 5,000 or more messages a day to Gmail need both, confirmed by DMARC. | DKIM comes from the sending service, so pick an SMTP sender, complete its domain verification, and publish the selector records it issues (usually CNAMEs). Verifying a single email address at the provider is not the same as verifying the domain. Confirm on a real send that the DKIM d= value is your store domain, not the provider's. |
| DMARC | Most WooCommerce stores publish no DMARC record, and the store sends without one. | Publishing p=quarantine or p=reject before you have an authenticated route turns your own order confirmations into spam, because they have nothing aligned to pass on. Leaving DMARC off entirely means you never learn which of your senders (store, mailbox, invoicing app, newsletter tool) are failing. | Publish v=DMARC1; p=none; rua=mailto:dmarc@yourstore.com on _dmarc.yourstore.com, read the reports until the store's own mail shows an aligned pass, then tighten. WooCommerce tells store owners to confirm SPF, DKIM and DMARC with their host or email provider rather than assuming they are configured. |
| SMTP sender | Not configured. WooCommerce calls wp_mail(), which calls PHP, which uses whatever mail transport the web server happens to provide. | This is the piece that lives outside DNS and decides the other three rows. Without an authenticated relay there is no key to sign with and no IP worth authorizing, so no amount of DNS editing produces an aligned pass. | Install an SMTP plugin that reroutes wp_mail() to a provider. WooCommerce's own list of providers with WordPress.org plugins includes MailPoet (5,000 emails a month free, 500 unique recipients), Mailjet (6,000 a month free), Brevo (300 a day free) and WP Offload SES Lite on Amazon SES. WooCommerce also says Gmail can be used, but warns that Gmail will disable your account if you send to more than 500 unique recipients in 24 hours, counting both your own Gmail sends and everything your site sends. |
Once you have updated these records, confirm they pass with Unspam's free SPF checker, DKIM checker, and DMARC checker.
WooCommerce ships a Send a test email control on the email editing screen, and it is genuinely useful for checking layout. It is not a deliverability test: the developer documentation states the preview does not use the actual data from the database, and builds a dummy order, dummy products and a dummy address instead. It also skips the order status transition that fires the email in production. To learn anything real, place one real order addressed to an Unspam seed address.
Start a spam test or inbox placement test in Unspam and copy the seed address it generates. An inbox placement test also issues a Test ID. Paste it into the subject line or the body before you send, or the message reaches the seed mailboxes and is never matched to your test. In WooCommerce the clean place to put it is WooCommerce > Settings > Emails, open the notification you are testing, and append the Test ID to the Subject field or drop it into Additional content. Remove it once the test is done.
Check out on your own store, or create the order from WP Admin, using the Unspam seed address as the customer billing email. Use a real product, real currency and a real shipping method, because the order table, totals and links are part of what gets scored. Do not substitute Send a test email here: it renders a dummy order and tells you nothing about the message a customer receives.
Pending payment triggers nothing, by design. Set the order to Processing to fire the Processing order notification, or to Completed for the Completed order notification. The New order admin notification fires on the same transition and goes to the recipients listed on its own settings screen, so if that is the email you are chasing, add the seed address to its Recipient(s) field instead.
Go to WooCommerce > Status > Logs and open the transactional-emails source, added in WooCommerce 10.9. Every attempt is recorded as Sent, Failed, Disabled or Skipped. WooCommerce defines Sent as having handed the email to your site's mail system successfully, so anything missing after that is a deliverability problem, not proof the customer received it. Failed, Disabled or Skipped means it never left, and DNS changes will not help. If you see no entry at all, check WooCommerce > Status > Logs > Settings: the log follows your store's level threshold, which can hide INFO and NOTICE entries.
Check the spam score, then the authentication block: DKIM should be present and signing with your store domain, SPF should pass and align, and DMARC should show an aligned pass. Then read inbox placement per provider, the client previews including dark mode, and the eye-tracking heatmap. The AI fix assistant flags what to change before the next real order goes out.
The same test renders your campaign in 50+ real email clients, Gmail, Outlook, Apple Mail, iPhone, and Android among them, each in light and dark mode, via email client previews, so you confirm placement and rendering in one pass.
The email preview and its Send a test email control build a dummy order, dummy products, dummy variations and a dummy address. WooCommerce's developer docs say plainly that it does not use the actual data from the database. Because the message still travels your real sending route, an authentication failure it exposes is real, but a clean-looking test proves nothing about the content, totals or links a customer would receive.
The From name and From address under WooCommerce > Settings > Emails apply to the emails WooCommerce sends. WordPress core mail and other plugins fall back to WordPress's own default sender, which is wordpress@ your site's domain. So your receipts can go out as orders@yourstore.com while a core notification or a contact form message goes out as wordpress@yourstore.com, and mailbox providers build reputation on the two separately.
WooCommerce can move transactional emails out of the checkout request into a queue. It ships as Deferred emails under WooCommerce > Settings > Advanced > Features, off by default, described by WooCommerce as sending transactional emails asynchronously via Action Scheduler instead of during the current request, and code can force it with the woocommerce_defer_transactional_emails filter. WooCommerce documents Action Scheduler as relying on WP-Cron, which is dependent on site traffic. On a quiet store the receipt waits for the next visitor. Check WooCommerce > Status > Scheduled Actions for past-due actions.
Rerouting wp_mail() to a provider moves your mail off the web server onto an authenticated relay, and it usually fixes nothing-arrives. It does not automatically sign for your domain. Until you complete the provider's domain verification and publish its selector records, the message is signed with the provider's domain, your From header still says yourstore.com, and DMARC fails exactly as before, just from a better IP.
The deliverability problems WooCommerce senders hit most often, each with the fix that resolves it.
The admin notification is your store's domain mailing your store's own domain. WooCommerce sends it as orders@yourstore.com to a recipient at yourstore.com, over PHP on the web server, with no DKIM signature and from an IP that your SPF record does not authorize. An unauthenticated message claiming to be an internal sender is treated far more harshly than the same message arriving at an unrelated domain, and some providers hold it at the gateway rather than filing it to Junk, which is why you cannot find it anywhere. Customer mail scrapes through, admin mail does not.
The fix Put an authenticated SMTP sender in front of wp_mail(), complete the provider's domain verification, publish the DKIM selector records and add its include to your single SPF TXT record. As a stopgap while you set that up, change the Recipient(s) field under WooCommerce > Settings > Emails > New order to an address on a different domain so you can at least see orders arriving. Then place a real test order to an Unspam seed address, confirm the DKIM d= value is your store domain, and switch the recipient back.
Because PHP hands the message to a local mail server and WooCommerce's log records only that it handed the email to the mail system successfully, your log reads Sent and there is no bounce anywhere to read.
The fix Get off the PHP mail path entirely. Route wp_mail() through an authenticated SMTP provider, finish domain verification so the message carries a DKIM signature on your store domain, and add the provider's SPF include. The second thing the provider buys you is a bounce and suppression record, so silent drops stop being invisible. Then run an inbox placement test and confirm the message actually reaches an Outlook seed mailbox, not just a Gmail one.
Reset password is one of the notifications listed under WooCommerce > Settings > Emails, which means it can be switched off like any other, and it travels the same unauthenticated route as everything else. It is also the worst one to lose, because it is the only email the customer is actively waiting for and there is no order in your admin to tell you it failed. A disabled notification, a missing recipient and a filtered message all look identical from the storefront.
The fix Open WooCommerce > Status > Logs and filter the transactional-emails source. Disabled means the notification is off under WooCommerce > Settings > Emails > Reset password, Skipped means a precondition such as a recipient was missing, Failed means the mail service returned an error, and Sent means WooCommerce handed it off and it was filtered downstream. If nothing is logged at all, check where the reset was requested: WooCommerce warns that WordPress password reset emails and other WordPress admin emails might not appear in that log, and points you to your SMTP provider's logs instead. Fix the route first with an SMTP sender that signs for your domain, then re-test by requesting a reset for an account whose email address is an Unspam seed address.
SMTP solved the sending problem, not the identity problem. The provider now relays your mail from a reputable IP under its own Return-Path, so SPF passes against the provider's domain. Until you finish domain verification, the message is DKIM-signed with the provider's domain rather than yours. Your From header still says yourstore.com, nothing aligns to it, and DMARC fails exactly as it did before, just from better infrastructure.
The fix In the provider's dashboard, verify the domain rather than a single sender address, and publish every DKIM record it issues. Send one real order email to a seed address and read the DKIM d= value: if it is still the provider's domain, verification is incomplete. Keep a single SPF TXT record with the provider's include added, for example v=spf1 include:_spf.google.com include:sendgrid.net ~all, rather than publishing a second SPF record, which invalidates both.
This is the deferred email queue. WooCommerce can move transactional emails out of the checkout request so the customer is not waiting on the mail server: it is the Deferred emails feature at WooCommerce > Settings > Advanced > Features, off by default, and code can also force it with the woocommerce_defer_transactional_emails filter. The queue runs on Action Scheduler, and WooCommerce documents Action Scheduler as relying on WP-Cron, which is dependent on site traffic. A store with a quiet night has no visitor to trigger the queue, so the receipt waits for the next one.
The fix Open WooCommerce > Status > Scheduled Actions and look for past-due actions; a pile of them more than a day old confirms it. WooCommerce's own guidance is to set up a custom server-side cron job to run WP-Cron independently and bypass the traffic dependency, which fixes timing for every scheduled job in the store, not just email. If checkout was already slow before the deferral, the cause is usually the mail hop happening inside the request, and moving to an SMTP provider removes that too.
Open WooCommerce > Status > Logs and select the transactional-emails source, added in WooCommerce 10.9. Every attempt is logged as Sent, Failed, Disabled or Skipped. Sent means the message left your site, so the problem is deliverability. Failed, Disabled or Skipped means it never left, and no DNS change will help. WooCommerce also notes the log confirms only that wp_mail() reported success, not that anyone received the message.
For anything past a hobby store, yes. WooCommerce's own documentation says shared and virtual hosting environments are typically not optimal for sending email, and its authentication guide tells store owners to confirm with their host whether store mail is authenticated with SPF, DKIM and DMARC. An authenticated SMTP sender is what gives you a DKIM key for your domain, an IP with a reputation, and a bounce record you can read. Several of the providers WooCommerce lists have free tiers that cover a small store.
Start with the Recipient(s) field on WooCommerce > Settings > Emails > New order, which defaults to the site administrator email from Settings > General, then check WooCommerce > Status > Logs for a transactional-emails entry. If the log says Sent and the recipient is on your store domain, you are looking at your domain mailing your own domain: an unauthenticated message claiming to be an internal sender is the shape of a phishing attempt and is filtered much harder than the same message arriving at an unrelated domain, and some providers stop it at the gateway so it is not in your spam folder either. Fixing DKIM and SPF on the sending route fixes both directions.
The order status, not your DNS. WooCommerce defines Pending payment as an order received with no payment made, and its email FAQ states no email is triggered while an order sits there. Orders stall in that status when the payment gateway cannot communicate back to your site. Check for Pending payment or Failed, then check WooCommerce > Status > Logs, and only then start looking at authentication.
No. Unspam does not integrate with WooCommerce, WordPress or any platform API, and it never connects to your store. There are two integration points: a seed address you send to, and SMTP credentials you supply for automated tests. For WooCommerce that means placing a real order with the seed address as the billing email, which is the only way to test the exact message a customer receives.
Send transactional mail from the domain on your storefront, because that is the domain the customer just handed their card to and the one their filters have learned to associate with the purchase. If you also run campaigns, keep bulk marketing on a separate subdomain so a bad send cannot drag receipts down with it. Either way the From address has to be on a domain you control: WooCommerce warns that an @gmail.com or @yahoo.com address in the From field is likely to land in spam or be blocked.
WooCommerce platform details were verified against publicly available documentation in August 2026 and may have changed since. WooCommerce is a trademark of its respective owner. Unspam is not affiliated with or endorsed by WooCommerce.
