Laptop displaying email headers, notepad with DNS checklist and a small parcel on a desk, soft natural light.

This article focuses on one goal: reliably getting transactional emails (order confirmations, password resets, invoices) into customers’ inboxes without over‑engineering. It assumes you’ll pick one clear first phase—authenticate your sending domain, use a dedicated transactional stream, and add simple monitoring—rather than a long list of half‑implemented fixes.

Decision flow: which sending approach to choose

  • Use your regular business email (Google/Microsoft Workspace) only for human correspondence. Don’t send automated transactional mail from the same addresses people use with Gmail/Outlook for day‑to‑day conversation; it risks reputation and deliverability issues. Major providers recommend adding SPF/DKIM/DMARC if you do send programmatic messages from workspace domains (Google).
  • Use a transactional ESP (SendGrid, Mailgun, etc.) as the primary sending service for automated messages if you cannot reliably operate and monitor a mail server. ESPs provide bounce/complaint webhooks, suppression lists and reputation tooling that are designed for transactional streams (SendGrid docs).
  • Run your own mail server only if you have hosting control, experienced sysadmin support and clear monitoring. For most small businesses a verified ESP or SMTP relay is a lower‑risk first phase.

Minimum DNS and authentication checklist (implement first)

The UK NCSC and GOV.UK recommend publishing SPF, DKIM and DMARC to reduce spoofing and improve delivery; start with monitoring mode for DMARC and inspect reports before enforcing policies (NCSC, GOV.UK).

  • SPF: add an SPF TXT record that includes your ESP’s servers or SMTP relay. Keep it short and avoid multiple SPF records for the same domain.
  • DKIM: enable DKIM signing in your ESP or mail server and publish the public key as a TXT record on the sending domain or subdomain.
  • DMARC: publish a DMARC TXT record with p=none initially and a reporting address so you can collect aggregate reports and forensic data.
  • Subdomain for transactional mail: use tx.example.com or mail.example.com for sending. This keeps transactional reputation separate from primary business inboxes.

Practical deliverability controls

  • Envelope‑from should use the sending subdomain (bounces route correctly; prevents accidental delivery to your primary inbox).
  • TLS: require TLS where possible. ESPs and modern MTAs support opportunistic or enforced TLS.
  • MTA‑STS (optional first phase): helpful for receiving domains, but not required to get started. Prioritise SPF/DKIM/DMARC first.

Operational musts

  • Bounce and complaint webhooks: configure webhooks so your application updates order status and stops retrying addresses that hard bounce.
  • Suppression lists: sync your app’s unsubscribe/complaint state with the ESP suppression list daily.
  • Rate limits and throttling: avoid sudden bursts from launches—throttle sends if your ESP or host warns of limits.
  • Headers to check: when testing, examine Delivered‑To, Received, Authentication‑Results and DKIM‑Signature in Gmail/Outlook message headers to confirm auth and routing.

Launch checklist and 72‑hour triage playbook

  • Run test sends to Gmail, Outlook and one corporate mailbox; inspect headers for SPF/DKIM pass and DMARC alignment.
  • Enable DMARC reporting and monitor reports for 48–72 hours; look for unexpected senders and alignment failures.
  • If customers report missing mail: (1) confirm the address and check suppression lists; (2) ask customer to search spam/promotions and provide a header from a later related mail; (3) check ESP activity feed and bounce webhook logs; (4) if the ESP marks messages as delivered but recipient lacks them, escalate using delivered‑header evidence to the recipient’s provider.
  • Keep a public “email outage” status page and an internal incident log for each event.

When this approach is NOT a good fit

  • If you cannot edit DNS or delegate that task to your provider, you cannot properly deploy SPF/DKIM/DMARC and should instead use an ESP that supports verified subdomains you control.
  • If you lack any developer or hosting contact for webhook integration, you’ll miss bounce handling and should budget for setup help.
  • If you must send very high volumes immediately (hundreds of thousands/day) start with a specialist deliverability consultant and phased ramp‑up—this guide is for small businesses and modest transactional volumes.

What to agree in writing before work starts

  • Who edits DNS (customer or agency) and which domain/subdomain will be used for sending.
  • Which service sends mail (ESP name or host) and who configures DKIM keys.
  • Webhook endpoints and how bounces/complaints will be handled by the application.
  • Acceptance tests: list of recipient addresses (Gmail, Outlook, corporate) and required header checks.
  • Monitoring and escalation: who watches DMARC reports for the first 72 hours and who acts on them.

Hypothetical business scenario

(Hypothetical) A small online gift shop uses Google Workspace for staff email but had customers report missing order confirmations. The shop sets up a transactional subdomain tx.shop.example, provisions SendGrid as the ESP, publishes SPF/DKIM for tx.shop.example, configures bounce webhooks to update order records, and starts DMARC in monitoring mode. After 48 hours of DMARC reports and a few header checks, delivery stabilises and support tickets drop.

If you want a short, studio‑ready commissioning brief and a copyable DNS record checklist to hand to your host or agency, we can draft that next and include the exact DNS TXT record examples for a transactional subdomain.

Need help implementing this for your shop? Our team can assist with the DNS and ESP setup.

Digital Pegas

We build business websites, online stores and focused custom software for UK businesses. These guides explain the decisions involved in planning and launching a project.