When invoices and confirmations don't reach your customers

Transactional emails are the messages a system sends automatically in response to something a customer does, as opposed to marketing email. Order confirmations, invoices, appointment reminders and password resets are part of the service your customers pay for. When one of them does not arrive, or lands in spam, the customer may not be able to finish what they started. In many companies nobody is explicitly responsible for these messages arriving, so the problem only becomes visible when customers start to complain.

Online shop: the order confirmation and the tracking number. Without them, customers call, order a second time or refuse the parcel.

Bookings at a hotel, restaurant, clinic or salon: the confirmation and the reminder. Without them, no-shows and double bookings increase.

Invoicing and subscriptions: the invoice and the payment reminder. Without them, payments arrive late.

Sign-up and login: the email confirmation and the password reset. Without them, customers cannot log in, so they call support or give up.

Quotes and logistics: the quote from the CRM and the order status notification. Without them, deals slow down and the team answers calls the automatic message was meant to prevent.

A message can be lost in three ways. The recipient's server can reject it. Then at least there is a signal, because a bounce message comes back, provided someone is watching for it. It can delay it for hours, which for a reminder or a login code is almost the same as losing it.

The third way costs the most. The server accepts the message and files it in spam. The system reports it as delivered, nobody in the company notices, and the customer assumes you never wrote.

The typical scenario starts with a provider's free or cheapest plan. Messages leave from IP addresses shared by many senders. When one of them sends unwanted mail, the addresses can end up on blacklists, and mail from everyone in the pool can start being rejected or filed as spam.

SPF, DKIM and DMARC, the domain's DNS records, are often missing or misconfigured. SPF and DKIM confirm that a message was sent with the domain's authorisation, while DMARC tells the receiving server what to do when it does not, and sends reports. Sometimes mail leaves directly from the hosting server, and invoices share a domain with marketing campaigns. A campaign that draws many complaints then affects the invoices as well.

Today Gmail and Outlook rely heavily on the reputation of the sending domain and on authentication, not only on IP addresses. Gmail and Yahoo since 2024, and Microsoft since 2025, require SPF, DKIM and DMARC from senders of high volumes of mail.

This happens in small and large companies alike. A small business usually runs on a free plan, set up once when the website launched. A large company sends from dozens of systems, configured by different people over the years. In both cases nobody is explicitly responsible for delivery. Marketing relies on IT, IT relies on the provider, and the provider reports that it accepted the message.

A good paid provider solves the problem of shared addresses with a poor reputation, and that is an important step. Mail, however, rarely leaves from one place. The CRM, the invoicing software, the booking system and the website form often send from their own servers on behalf of your domain, and each one has to be authorised and authenticated separately.

Most such services have an "authenticate your domain" step during setup. It is often skipped, because nothing stops working straight away. Messages simply start landing in spam more often.

The provider also reports whether the recipient's server accepted a message. Whether the message landed in the inbox or in spam does not show in its standard reports.

Large companies often do not monitor this, because the individual systems were introduced by different teams. When such a company first turns on DMARC reports, it often finds more places sending on its behalf than anyone had assumed.

Customers say they never received a confirmation, or found it in spam.

Support answers questions the automatic message was meant to answer.

The problem looks random, because one message arrives and the next does not.

Nobody in the company can say which systems and providers send mail on behalf of the domain. If that is the case, the risk is already there.

One owner. A named person in the company, or an external partner, is responsible for delivery and has access to the providers' reports.

Separate streams. Staff mail stays on the main domain, while notifications and marketing campaigns go out from separate subdomains, each with its own reputation. A problem with one campaign is then much less likely to affect the invoices.

The right infrastructure. A plan with an isolated pool or a dedicated IP address, sized to the volume. A dedicated address only makes sense with enough volume and after a gradual warm-up.

An authenticated domain. SPF, DKIM and DMARC configured so the domain in the From address matches the signature, with the DMARC policy tightened step by step.

If staff, campaigns and notifications all send from the same domain, a reputation problem also affects your staff's own emails. A quote or contract to an important client can land in spam. Moving notifications and campaigns to separate subdomains reduces this risk.

Authentication protects against something else as well. Without DMARC set to reject, anyone can send a message that appears to come from your domain, for example a fake invoice with a different bank account sent to one of your clients. DMARC stops such messages from your exact domain at the servers that honour it. It does not protect against look-alike domains (such as firma-bg.com), so changes to bank details should always be confirmed through another channel.

Daily: the delivery rate, bounces and complaints, with an alert when delivery drops.

Monthly: DMARC reports, the domain's reputation in Google Postmaster Tools, and a blacklist check of the domain and, with a dedicated IP, of that address.

Quarterly: a list of every system that sends mail on behalf of the domain, and a check that each one is authenticated.

For every new system or provider: authentication before it sends its first message.