Your website is already running a mail operation
Most companies only notice this when something important disappears. A quote request never reaches sales. A password reset shows up too late. An order confirmation lands in junk. Support replies come from the wrong address and the thread breaks. On plenty of WordPress, Drupal, and custom sites, those messages still rely on aging SMTP settings, host-level mail, one plugin someone installed years ago, and DNS records nobody has touched since launch.
That used to be messy but manageable. In 2026 it is an operational risk. Google’s sender rules now set a baseline for anyone sending to personal Gmail accounts: authentication, valid forward and reverse DNS, TLS, proper message formatting, and low spam rates. For higher-volume senders, Google requires SPF, DKIM, and DMARC, and Google’s FAQ says enforcement on non-compliant traffic ramped up from November 2025. Yahoo is pushing in the same direction. Microsoft describes SPF, DKIM, and DMARC as layers that need to work together, not optional settings you add later if deliverability starts to wobble.
This matters even if your website only sends a modest number of emails. Contact forms, lead notifications, booking confirmations, receipts, and password resets may be low-volume, but they are high-consequence. If your customers, suppliers, or staff use Gmail, Yahoo, Outlook, or Microsoft 365, mailbox-provider policy is already part of the way your business operates.
Why this deserves attention now
The real cost is not just a few messages landing in spam. Website-generated email sits inside quoting, onboarding, e-commerce, support, security, and internal workflows. When it breaks, teams usually diagnose the wrong layer. Sales blames lead quality. Marketing blames the form. Support blames the plugin. Hosting blames DNS. Meanwhile nobody owns the full chain from CMS to transport to authentication to sending reputation.
- Lost enquiries when form alerts or CRM notifications never reach the people who need to act.
- Broken customer journeys when activation, password reset, invoice, booking, or order emails arrive late or not at all.
- Brand exposure when weak authentication makes it easier to spoof your domain.
- Reputation spillover when marketing and transactional mail share identity, infrastructure, or sending streams that should be separated.
- Quiet drift when old plugins, staging environments, cron jobs, or forgotten SaaS tools keep sending as your domain without anyone noticing.
The upside is straightforward. Once website email is treated like an operational service, response times improve, support noise drops, attribution gets cleaner, and every conversion path that depends on email becomes easier to trust.
Where problems usually hide
The common mistake is treating deliverability as a plugin decision. It is not. It is a chain. A WordPress form plugin may hand off to the local server mailer. A Drupal module may use a different transport. A CRM connector may sign correctly but send from a different return path. The sender your customer sees in the inbox may be your root domain, while the real sending system sits somewhere else. If SPF, DKIM, and the visible From identity are not aligned, receiving systems are left to guess whether the message is legitimate.
That is why quick fixes age badly. Adding one SPF record is not a mail architecture. Installing an SMTP plugin is not a strategy. Google and Yahoo both make an important distinction around one-click unsubscribe: it applies to subscribed marketing mail, not transactional mail. That nuance matters. Transactional messages should stay narrow, predictable, and trusted. Promotional mail should be easy to opt out of. When both are mixed through the same loose setup, reputation problems tend to spread into the messages the business actually depends on.
Yahoo also recommends separating content types into different streams, and Microsoft’s DMARC guidance starts with monitoring before enforcement. Those two points work well together. First work out what is actually sending. Then measure it. Then tighten policy. If you skip the inventory step, cleanup has a habit of breaking legitimate mail along with the bad stuff.
What a practical cleanup looks like
-
Map every sender using the domain. That means WordPress or Drupal forms, commerce plugins, CRM connectors, helpdesk replies, booking tools, servers, cron jobs, staging systems, and any SaaS platform using your domain in the visible sender address. The first useful deliverable is a map: what sends, from where, as which domain, for which business event.
-
Fix DNS and authentication properly. In practice, that usually means untangling SPF sprawl, enabling DKIM per sender, publishing DMARC with reporting, and making sure the visible sender identity lines up with approved infrastructure. It often also means cleaning records in Cloudflare or at the registrar, using subdomains with purpose instead of dumping everything onto the root domain, and starting DMARC with
p=noneso real traffic can be observed before stricter policy is applied. -
Repair the transport layer inside the site. On CMS builds, that often means replacing fragile default mail paths with authenticated SMTP or API-based delivery, standardising
FromandReply-Tobehaviour, and removing duplicate or contradictory mail plugins. On Linux-hosted systems, it may also mean checking PTR records, TLS, queue behaviour, rate behaviour, and logs where mail is self-hosted or partly self-hosted. -
Separate transactional from promotional traffic. Order receipts, password resets, lead confirmations, and operational alerts should not share reputation with campaign mail if that can be avoided. Separate domains, subdomains, or providers are often the cleaner answer.
-
Put monitoring and documentation in place. DMARC aggregate reports keep arriving whether anyone is watching or not, and parsing them by hand is a poor use of time. This is a sensible place for Bash or Python automation, basic dashboards, alerting, and a lightweight runbook so the client is not back in the same mystery state six months later.
Where Greg fits
This is the kind of assignment that falls between departments and between vendors. It touches DNS, Cloudflare, mailbox-provider rules, server configuration, CMS behaviour, plugins, APIs, and day-to-day business process. A site builder can launch the website. An email vendor can sell delivery. The gap is in tracing the whole path, stripping out the legacy noise, aligning the moving parts, and leaving the client with something measurable.
That is where Greg is useful. The work sits comfortably inside his actual service surface: coordinating across vendors when ownership is split, troubleshooting WordPress and Drupal when the site is part of the failure, handling Linux and web-server administration when the host layer is wrong, making Cloudflare and DNS changes when authentication needs fixing, and scripting repeatable checks or reports when manual monitoring is not good enough. For an owner or operations lead, the outcome is simple: fewer lost messages, fewer blind spots, and less time spent figuring out why a legitimate email never arrived.
Website email used to be treated as a side effect of having a contact form. It makes more sense to treat it like core operations. If leads, customers, or internal teams depend on those messages, deliverability belongs in the same category as uptime, backups, and release management.
Need help with this kind of work?
Need your website email stack audited and fixed? Get in touch with Greg.