How to Improve Email Deliverability Without Guessing

01

Delivery and deliverability are not the same thing

A customer books an appointment through your website. The page confirms it worked, the database contains the booking and the application records that the confirmation email was sent. The customer receives nothing.

That small gap can create a surprising amount of work. They book again, contact support or assume the business is unreliable. If the missing message was a password reset or payment receipt, the customer may be unable to continue at all.

An email platform may report that a message was delivered when the receiving mail server accepted it. That is useful, but it does not tell you where the message finished. The receiving provider may place it in the inbox, move it to spam, route it to another tab, delay it or later reject it.

The application asking the provider to send, the provider accepting the request, the recipient server accepting the message and the recipient engaging with it are separate facts. A log entry saying email sent often confirms only the first or second step.

The first improvement is visibility. Store the provider's message identifier, process delivery and bounce events, and make those events available to the people handling customer problems. You cannot improve a delivery route you cannot see.

02

List every system that sends as your domain

Authentication becomes messy when a business thinks it has one email sender but actually has six.

The main mailbox may use Microsoft 365 or Google Workspace. A marketing platform sends newsletters. The website sends form notifications. The application sends password resets and receipts. An invoicing service, CRM and support desk may also send messages that appear to come from the same domain.

Before changing DNS, list every legitimate sender, the type of message it sends and the address recipients see in the From field. Remove systems that are no longer used and identify anything sending through a developer's personal mailbox or an old server nobody owns.

This inventory prevents a common mistake: adding a new email service while leaving an incomplete SPF record or an old sending route behind. It also shows which messages are critical. A password reset and a monthly newsletter do not need the same speed, controls or tolerance for complaints.

03

Set up SPF, DKIM and DMARC properly

Email authentication gives receiving providers evidence that a message is allowed to use your domain.

SPF publishes which services may send email for a domain. It is a DNS record, and a domain should have one valid SPF policy that includes all authorised senders. Adding several separate SPF records is not the same as creating one correct record.

DKIM adds a digital signature to each message. The receiving server can use a public key published in DNS to check that an authorised sender signed the email and that important parts were not changed in transit.

DMARC connects the visible From address to SPF or DKIM. This is called alignment. It also tells receiving servers how to handle mail that fails the checks and can send reports showing which services are using the domain.

Google's current sender guidance requires all senders to personal Gmail accounts to use SPF or DKIM. Senders delivering more than 5,000 messages a day to Gmail accounts must use SPF, DKIM and DMARC, meet alignment requirements and provide one-click unsubscribe for marketing and subscribed messages. Yahoo publishes similar requirements for bulk senders.

Do not jump straight to a strict DMARC rejection policy without understanding every sender. A safer rollout starts with reporting, checks the legitimate traffic, fixes alignment and then increases enforcement in controlled steps.

04

Separate transactional and marketing email

Transactional messages happen because a person did something: booking confirmations, password resets, invoices, account alerts and security codes. They are normally time-sensitive and closely connected to the service.

Marketing messages are campaigns, newsletters, offers and announcements sent to a wider audience. They naturally receive different engagement and complaint patterns.

If both types share the same sending stream, a weak marketing campaign can affect the reputation of critical application email. The clean approach is to separate them using distinct sending streams and, where appropriate, separate subdomains such as notify.example.com and news.example.com.

That creates an operational boundary. Transactional events can be monitored for speed and failures, while marketing traffic can be managed around consent, engagement and unsubscribe behaviour.

Tools such as Postmark and Mailchimp can play different roles. Postmark is built around application and transactional email, while Mailchimp focuses heavily on marketing lists, campaigns and automation. The important decision is not the logos. It is giving each type of message a delivery route suited to its job.

05

Sender reputation is earned through behaviour

Correct authentication is necessary, but it does not make every message wanted.

Inbox providers also consider sending patterns, bounce rates, spam complaints and recipient behaviour. A domain that suddenly sends a large batch to old or purchased addresses looks very different from a domain that sends predictable messages to people who expect them.

Build reputation by sending only to people with a clear reason to receive the message. Remove hard bounces quickly. Honour unsubscribes. Avoid repeatedly emailing contacts who never engage, and do not quietly turn a service notification list into a marketing list.

When starting with a new domain or subdomain, increase volume gradually. Begin with the messages and recipients most likely to be legitimate and engaged. A large overnight jump gives the receiving provider no history from which to judge the sender.

A dedicated IP address is not an automatic upgrade. Low or irregular volume may perform better on a well-managed shared service because a dedicated address has no useful reputation of its own and needs consistent traffic.

06

Make each message easy to trust and act on

Content still matters, but it should be reviewed after the sending foundation is sound.

Use a From name and address that the recipient can recognise. Keep the subject accurate. Make the reason for the message obvious near the top, and use your own trusted domains for links rather than hiding destinations behind a generic URL shortener.

HTML email should be simple enough to render across common clients. Include a useful plain-text version. Add meaningful text rather than relying on one large image, and make sure the main action still makes sense when images are blocked.

Marketing email needs a clear unsubscribe route, including the technical one-click mechanism required by major mailbox providers for bulk subscribed messages. An unsubscribe is healthier than a spam complaint.

Transactional email needs a different check. Ask whether the message contains the information the customer needs, whether a reply reaches somebody useful, and whether sensitive information has been kept out of places where it does not belong.

07

Handle failures as part of the application

An email provider should return events for bounces, complaints, deliveries and other message activity. Those events need somewhere sensible to go.

For the booking system, a permanent bounce should stop repeated attempts to the invalid address and create a visible issue against the customer record. A temporary failure may be retried according to the provider's behaviour, but it should not disappear into a log nobody checks.

A spam complaint should suppress future marketing and trigger a review of how that address joined the list. Keep enough event history to answer a support question without exposing message content for longer than the business needs.

Monitoring should focus on change as well as totals. A sudden rise in bounces, complaints or deferred messages can reveal a damaged form, stale import, DNS change or campaign problem before customers report it.

Test alerts and ownership too. A dashboard that turns red while everybody assumes somebody else is watching it is mostly decoration.

08

Test the whole journey before blaming the inbox

When an email goes missing, test the route in order.

First, confirm that the business event happened once. Then check that the application created the right email with the right recipient. Confirm that the provider accepted it and inspect the provider's delivery events. Check authentication results, bounce details and recent changes to DNS, templates, links or sending volume.

Send controlled tests to several mailbox providers, but do not treat your own inbox as universal proof. Gmail, Outlook and Yahoo can make different placement decisions, and business gateways may add another layer of filtering.

Also test what the customer can do when email fails. Can they request another password reset without creating ten valid tokens? Can support confirm a booking through another route? Is there a visible in-app record of the receipt?

Email is useful, but a critical business process should not become unknowable because one message was delayed.

09

Improve the system, not only the subject line

The missing booking confirmation looked like an email problem. In reality, it exposed a chain with unclear status, mixed message types and too little evidence for support to act.

Improving deliverability means treating email as part of the business system. Authenticate the domain, separate messages with different jobs, protect reputation, handle failures and monitor the result. Then improve the wording and design on top of a route that can be understood.

None of these steps guarantees a primary inbox placement. The recipient's provider makes that decision, and its filters change over time. The aim is to remove avoidable doubt, create useful evidence and give legitimate email the strongest sensible route.

If important customer email is unreliable, start by mapping every sender and one critical journey. That small review usually reveals whether the next job is DNS, list quality, application logic, provider configuration or all four in a sensible order.