Transactional Email for Receipts, Resets and Notifications

Transactional email is the mail your application sends to one person because of something they did. Order confirmations, password resets, shipping notices, account verifications, and receipts all count. It is triggered by an action rather than scheduled by a marketer, and the recipient is usually waiting for it, which is why a delay or a spam folder placement turns into a support ticket.

Marketing email goes to a list on a schedule and people can opt out of it. Transactional email goes to one person because they did something, and they cannot reasonably opt out of a receipt they are owed. The practical difference is tolerance. A newsletter landing in promotions is a missed opportunity, while a password reset landing there is a customer locked out of their account.

Usually because they leave your web server unsigned. WordPress sends through the host by default, from an address on your domain, with nothing proving that server is allowed to send as you. Mailbox providers treat that as possible forgery and filter it. Routing the same mail through an authenticated path with published records fixes most of the problem, and reputation work fixes the rest.

Deliverability is the share of your mail that reaches an inbox rather than a spam folder or a rejection. We track delivery rate, bounce rate, and complaint rate as the core numbers, then watch for placement problems those rates can hide. A message can be accepted by the receiving server and still land in spam, so acceptance on its own is not the measure that matters.

For transactional mail, above 99 percent delivered is normal, and anything under 98 percent deserves investigation. Bounce rate should sit below 2 percent and complaints below 0.1 percent, because both feed directly into how providers treat you. Marketing benchmarks are looser and do not apply here. Receipts go to people who just handed you their address, so those addresses should be good.

We recommend a subdomain and it is included. Keeping application mail on its own subdomain means its reputation is tracked separately from the address your staff email from. If a run of bad addresses causes trouble, it lands on the subdomain rather than your primary domain, so your team can carry on emailing customers normally while we sort it out.

They are three DNS records that prove your mail is really yours. SPF lists which servers may send for your domain, DKIM signs each message so tampering shows, and DMARC tells providers what to do when a message fails the other two. Publishing them is table stakes now. Getting all three aligned with each other is the part that trips people up.

Additional volume is one dollar per thousand delivered, added to the same monthly invoice. There is no cliff, no throttling, and no upgrade conversation to sit through. If your volume climbs far enough that a different arrangement would cost you less, we will tell you rather than quietly billing the overage every month.

Yes, and those are usually the emails that prompt the call in the first place. WooCommerce relies on the same WordPress mail function everything else uses, so once that is routed through the authenticated path, order confirmations, shipping notices, and customer account mail all travel it. We test each of those templates during setup rather than assuming they render.

Often, though it takes longer than starting clean. We audit what is actually published, correct the records, request delisting anywhere your domain has been flagged, and clear out the addresses causing bounces. Then volume goes back up slowly. If the domain has been mailing bad addresses for years, expect a few weeks before the numbers settle rather than a few days.

We need DNS access to publish the sending records, and administrator access to your site to route its mail through the authenticated path. If we already manage your WordPress, we have both. Otherwise we will tell you exactly which records to add and what to install, or you can grant temporary access and we will handle it ourselves.

Records go up within a day or two of getting DNS access, and templates are usually built the same week. The part that takes real time is warming, where volume rises gradually so providers learn your domain before live traffic depends on it. Plan on two to three weeks before everything is running at full volume.

Yes. Give us the address and roughly when the message should have gone out, and we will tell you whether it was accepted, bounced, or rejected, and what the receiving server said about it. This is the question that makes delivery logs worth keeping. Without them, the honest answer to it is a shrug.

Everything comes with you. Your DNS records stay on your domain because they were always yours, and we hand over your templates, suppression list, and sending history in a standard format. Thirty days’ notice ends the service. We will also tell you what to point your site at next so your mail does not simply stop.