The ticket always reads the same way. Students say the welcome message never arrives. Password resets stopped working this week. Some get it, some do not, Gmail users mostly. Nothing broke in the LMS. The course works, the payment processed, the enrolment record exists. The message was generated, handed off, and quietly discarded somewhere between your server and the mailbox that was supposed to receive it.
Deliverability for transactional course mail is not mysterious. It is a chain of about six configuration decisions, most of them defaulted badly by WordPress itself, and each failure looks identical from the admin dashboard: silence. Here is the chain, in the order I debug it.
Default WordPress sending is the first problem, not the last
Out of the box, WordPress hands mail to wp_mail, which passes it to the mail facility on the web host. The documentation is explicit that a successful return value only means the request was processed without errors, not that anybody received anything. That facility identifies your server by hostname, sends unauthenticated, and originates from an IP shared with however many other accounts the host packed onto that machine. Reputation is inherited, and shared hosting reputations are usually mediocre at best.
Worse, the default envelope sender is often something nobody authorised, which fails alignment against your actual domain before you have done anything wrong. So the first fix is not a plugin tweak. It is stopping local delivery entirely and routing through a real sending service with its own authenticated SMTP or API credentials. This single change resolves the majority of tickets in this category.
The From address is where identity is decided
Two addresses live in every message and admins only ever see one. The From header is what the student reads. The envelope sender, often surfaced as Return-Path, is what the receiving server actually authenticates against, and it is what receives bounces. Confusing the two causes most of the strange cases.
Send transactional course mail from an address on a domain you control, ideally a dedicated subdomain so your human correspondence and your automated system do not share a reputation. The important part is that the domain in the From aligns with the domain whose signature the message carries. Misalignment, meaning a branded From with a third party envelope sender and nothing signed, is exactly the pattern filters are trained to distrust. Getting this right is the difference between mail that merely leaves your site and mail that presents as verifiable business email to the receiving provider.
Alignment, and the third party in the middle
SPF authorises the addresses permitted to send for a domain. DKIM signs the message so tampering is detectable. DMARC states what to do when neither aligns with your domain. All three are DNS records, all three are free, and skipping any of them is now a visible deficiency to the major providers.
The trap specific to LMS stacks is indirect mail. When a third party sends on your behalf, your CRM, your payment gateway receipts, an affiliate tool, the message may carry that service signature but fail alignment against yours. Multi-domain signing solves it, and it is usually a checkbox in the sending provider dashboard that nobody clicked. Publish a DMARC record in monitoring mode first, so reports start arriving and you learn what is being sent in your name before you enforce anything.
Transactional and marketing must not share a stream
Sending a promotional newsletter from the same subdomain and IP pool that sends password resets is how account recovery mail ends up quarantined. Marketing drives complaints, complaints damage the reputation of everything sharing the infrastructure, and the casualty is the message a student needs in order to finish a purchase.
One click unsubscribe is becoming expected
Bulk senders are increasingly required to support the one click unsubscribe mechanism described in RFC 8058, and mailbox providers reward it regardless. For genuinely transactional enrolment mail there is nothing to unsubscribe from, but if your system appends announcements or digests, honour the header and honour it immediately. Suppressing at the provider level within seconds beats a nightly job, because the alternative to instant suppression is a complaint, and complaints are the currency filters trade in.
Bounce and complaint hygiene compounds in both directions
Providers publish their own reputation dashboards, and on the Outlook side Smart Network Data Services shows per address reputation and complaint data for ranges you control. Check it before blaming a customer filter.
Launch spikes are self-inflicted incidents
Enrolling a large cohort on a Monday morning means thousands of messages in a couple of minutes from a pool that has never sent before. Receiving providers read sudden volume from a low history source as the signature of a compromised account, and throttle accordingly. The welcome messages then arrive on Thursday, and the ticket says they never arrived.
Warm up deliberately. Send in batches with sane concurrency, stagger cohorts across a day or two, and use the provider warm-up feature during the first weeks if one exists. This costs nothing except a little patience, and it prevents the most common self-inflicted launch outage in course platforms.
Test as a student, not as an admin
Create real student accounts on the big consumer providers and on a corporate domain with aggressive filtering. Enrol, buy, reset your password, complete a lesson. Check where each message actually landed, view the raw headers, confirm authentication passes and aligns, and confirm the From name is your brand rather than a server hostname.
Do it monthly. Twenty minutes, and it converts an entire category of support tickets from a mystery into a five minute comparison. Students never file a ticket when mail quietly stops arriving. They assume the course is broken and they leave.
