WooCommerce sends transactional emails at every stage of an order, and they fail more often than store owners realise, silently, because neither you nor the customer is told when a message does not arrive.
The customer simply concludes the order did not go through, and contacts you or does not.
Configure the sender first
Under WooCommerce email settings, set the "from" name and address to something on your own domain.
An address on a different domain than the site is a strong spam signal. So is a no-reply address, which also tells customers you do not want to hear from them at the moment they most want to reply.
Do not use the server's basic mail function
This is the single largest cause of WooCommerce email problems.
By default WordPress hands mail to the server's mail function, and many receiving providers distrust that route. Messages land in spam or are refused outright, and nothing reports it back.
Configure WooCommerce to send through authenticated SMTP using a real mailbox on your domain. That route authenticates properly and is dramatically more reliable, and it is a fifteen-minute change.
Then publish SPF, DKIM and DMARC
Without all three, major providers treat your mail as suspect regardless of what it says. With them, order confirmations arrive.
This is not optional for a store. A customer who does not receive a confirmation assumes the payment failed. Understanding SPF, DKIM and DMARC deals with publishing them.
Which emails matter
Not all of them are equally important, and the defaults are reasonable.
To the customer: order received, order processing, order completed, and any refund. These are the ones that must arrive.
To you: new order. This is how you find out to fulfil something, so it should go to an address someone actually watches, and preferably not one on the same domain, so a mail problem does not hide new orders from you too.
Password reset and new account are WordPress emails rather than WooCommerce ones, and they fail for the same reasons.
Test properly
Place a real order and confirm each message arrives. Do not rely on a plugin's test button; those frequently bypass the path a real notification takes and pass while real emails fail.
Test to a major provider's mailbox specifically, and check the spam folder there. Mail that arrives in spam is failing, even though it technically arrived.
Then read the received headers, which report whether SPF, DKIM and DMARC passed. A pass on all three is what you are aiming for.
Customising the templates
The settings screen covers the header image, colours and footer text, which is enough for most stores.
For structural changes, copy the template into your theme rather than editing the plugin's files, or the next update overwrites your work. Use a child theme so a theme update does not do the same.
Keep the content brief. An order confirmation needs the order number, what was bought, the total, and what happens next. Marketing content in a transactional email increases the chance of it being filtered as marketing.
When emails stop
Check in this order.
Is the account over quota? A full account rejects mail and stops the site writing, and none of the errors mention it.
Does other mail work? Send a message from webmail. If that works and WooCommerce mail does not, the problem is the sending method instead of the mailbox.
Are orders actually being created? No order means no email, and the real problem is the payment callback rather than mail. There is more in the troubleshooting guide.
Did it break after a migration? SPF and DKIM reference the old host and need regenerating. This is why mail from a freshly moved store so reliably goes to spam.
Shipping choices appear in those emails, so they are worth settling first. How to Set Up Shipping Zones and Methods walks through the zones.
Confirm the messages are actually arriving
Store notifications fail silently, and the first sign is usually a customer asking where their confirmation is.
wp eval 'echo wp_mail("[email protected]","test","govde") ? "kabul edildi\n" : "reddedildi\n";'
tail -20 ~/logs/example.com.error.log
exim -bp 2>/dev/null | wc -l
Acceptance means the application handed the message over. It says nothing about delivery, which is why the queue and the mail log matter more than the return value.
Place a real order to a real address as the check rather than sending a test message, since the order path exercises the templates, the triggers and the recipient list, and a test message exercises none of them.
Check which notifications are enabled
The default set is not what most shops want, and the gaps are only visible when somebody does not receive something.
wp db query "SELECT option_name FROM wp_options WHERE option_name LIKE 'woocommerce_%_settings' AND option_name LIKE '%email%' LIMIT 20;" 2>/dev/null
Read which are active and which recipient each uses. The administrative notifications frequently point at an address created during setup that nobody monitors, so failed orders and stock warnings go nowhere.
Decide per message whether it goes to the customer, to you, or to both. A shop where the owner receives every customer notification stops reading them, which is the same as not sending them.
Watch the ones that arrive late
Notifications sent by the scheduled task rather than immediately are delayed on a quiet site, sometimes by hours.
wp cron event list --fields=hook,next_run_relative 2>/dev/null | head wp option get siteurl
A site relying on visitor triggered scheduling sends nothing until somebody visits, which on a low traffic shop means a confirmation arriving the following morning.
Moving that to a proper scheduled job on the server fixes it and is a small change. Why scheduled tasks do not run covers the arrangement.