Your invoices are in the spam folder because of DNS
Order confirmations that never arrive are almost never a WordPress problem. Three DNS records decide it, and alignment is where it goes wrong.
A shop that cannot deliver its own order confirmations has a revenue problem, not a technical curiosity. The cause is nearly always in DNS, and the fix is nearly always a day’s work.
The three records
- SPF lists who may send for your domain. Every service that sends on your behalf has to be in it — your server, your relay, your newsletter tool, your invoicing system.
- DKIM signs the message so the receiver can verify it was not altered. The signature has to match the key published in DNS.
- DMARC tells receivers what to do when the first two disagree, and asks them to report back.
Alignment is the part people miss
Passing SPF is not enough. The domain that passes has to match the domain in the visible From address. Relay your mail through a provider and it is entirely possible to pass SPF on the provider’s domain while failing alignment on yours — which reads to the receiver as a message pretending to be you.
The double-signing trap
If your server signs with DKIM and your relay signs again, you can end up with two signatures where only one validates. On a domain routed entirely through the relay, the right answer is to stop signing locally and let the relay own it. This one is easy to miss because nothing errors: the mail sends, and quietly lands in junk.
Verify by sending, not by reading
Publish the records, then send real messages to real mailboxes at the big providers and read the received headers. Then turn on DMARC reporting and actually look at the reports for a fortnight. A validator that parses your DNS confirms syntax; only a delivered message confirms delivery.