Your website is already part of your mail stack
If your site sends contact form alerts, quote requests, booking confirmations, receipts, password resets, account approvals, or support notifications, you are running an email operation whether you planned for one or not. The problem is that many business websites still treat this as a plugin setting or a host default. When those messages go missing, the symptom looks small but the cost is not: lost leads, delayed onboarding, broken checkout flows, and support teams chasing problems in the wrong place.
In 2026, deliverability is not just about whether a server technically sent a message. Mailbox providers now enforce clearer sender requirements, and even low-volume website mail gets judged inside that system. That matters for owners, operations leads, and agencies because the business impact usually lands far away from the technical cause.
What changed, and why it matters
Google's current sender rules set a baseline for mail going to personal Gmail accounts: at minimum SPF or DKIM, plus valid forward and reverse DNS, TLS, sensible message formatting, and low spam complaints. Once a sender crosses roughly 5,000 messages a day to personal Gmail accounts, Gmail treats that domain as a bulk sender permanently, and stricter requirements apply, including SPF, DKIM, DMARC, domain alignment, and one-click unsubscribe for marketing or subscribed mail. Yahoo is aligned on the broader direction and makes an important distinction that many teams miss: one-click unsubscribe is for promotional mail, not transactional messages such as order confirmations or password resets.
That distinction matters on business sites. Transactional email should be predictable, narrow, and trusted. Campaign mail should be easy to opt out of and should not be allowed to damage the reputation of the messages your customers actually need. If those streams share the same identity, plugins, infrastructure, or sending IPs, reputation problems spread.
Where business websites usually go wrong
- The CMS sends through local server mail or an old SMTP plugin nobody fully owns.
- The visible
Fromaddress uses your main domain, but the real sender is a SaaS platform, relay, or CRM that is not aligned correctly. - DNS has drifted over time: multiple SPF records, a bloated SPF tree that exceeds lookup limits, missing DKIM selectors, or a DMARC record that was never moved beyond observation.
- Marketing tools, forms, helpdesk replies, booking tools, and account notifications all send as the same domain with no separation by purpose.
- Old staging sites, cron jobs, or abandoned integrations still send mail as your brand.
Microsoft's current guidance is still the clearest practical framing: SPF, DKIM, and DMARC are interdependent. If one external service sends on your behalf without proper SPF coverage or DKIM signing, the whole chain becomes harder to trust.
A practical cleanup plan
- Inventory every sender. List each business event, the system that triggers it, the visible sender address, the technical sending path, and the owner inside the business. Agencies should do this before changing DNS; owners should do it before blaming the form plugin.
- Separate identities by function. Keep high-trust transactional mail distinct from promotional traffic. In many cases that means using a subdomain for marketing or for third-party tools you do not fully control, while preserving your main domain for core operational mail.
- Fix authentication properly. Publish one valid SPF record per domain or subdomain, enable DKIM for every real sender, and add DMARC reporting. For active cleanup work, start with a monitoring policy such as
p=none, review the reports, then move towardp=quarantineorp=rejectonce legitimate sources are accounted for. Also lock down parked domains and unused subdomains instead of leaving them open as spoofing gaps. On many sites this means cleaning records in Cloudflare or at the registrar, not just changing a plugin. - Repair the application layer. Standardize
From,Reply-To, and message headers. Make sure each message has a validMessage-ID. Move fragile default mail paths to authenticated SMTP or API delivery where appropriate. If you send directly from a server, make sure PTR and TLS are in place. - Monitor the system, not just the inbox. Watch DMARC reports, provider dashboards, logs, and sample headers from real messages. If a password reset fails silently, the issue is operational even if mail appears to work most of the time.
Simple checks that still save time
If you are inheriting a WordPress, Drupal, or custom build, a few checks usually surface the real problem faster than plugin guessing:
dig TXT example.com
dig TXT _dmarc.example.com
dig TXT selector1._domainkey.example.com
dig -x 203.0.113.25Then inspect a real delivered message. In Gmail, use Show original and look for spf=pass, dkim=pass, and dmarc=pass. In Microsoft 365 environments, check the Authentication-Results header. If you see misalignment, missing DKIM, SPF permerror, or failures tied to a third-party sender, you are usually dealing with architecture, not copy, forms, or user error.
A useful starting DMARC record for observation looks like this:
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:[email protected]"That is not the finish line. It is the safe way to discover who is really sending before you tighten enforcement.
Where Greg fits
This work often falls between the website team, hosting provider, DNS provider, CRM vendor, and mailbox platforms. Nobody sees the whole chain, so nobody wants to own the failure. Greg is useful when the business needs one person to trace the path end to end, clean up the old decisions, make the DNS and CMS changes, and leave behind something the team can actually maintain.
For owners and operations leads, the outcome is straightforward: fewer lost enquiries, cleaner support flows, and less time spent proving whether the website, DNS, or mail provider is the real problem. For agencies, it is a practical handoff and remediation piece that reduces reputation risk after launch.
If email from your website affects sales, support, bookings, or account access, it belongs in the same category as backups, uptime, and release management. If you need that stack audited and fixed, talk to Greg.
Need help with this kind of work?
Need someone to trace forms, plugins, DNS, and senders as one system? Greg can audit the stack and fix the parts that are costing you messages. Get in touch with Greg.