Fixing Website Email Deliverability in 2026: A Practical Checklist for Business Sites

By Greg Nowak. Last updated 2026-06-24.

Your website is already part of the mail stack

If your site sends contact form alerts, quote requests, booking confirmations, receipts, password resets, account approvals, or support notifications, it is already part of your email operation. That is true whether the message leaves through WordPress, Drupal, a booking tool, a CRM, Microsoft 365, Google Workspace, or a transactional email provider.

The business problem is simple: when website email fails, leads disappear, customers get locked out, support teams waste time, and agencies get pulled back into old projects without a clean diagnosis. In 2026, the fix is rarely just another SMTP plugin. The useful work is tracing the full path from website event to DNS identity to sending provider to mailbox result.

What has to be true in 2026

Gmail now sets a practical baseline for mail sent to personal Gmail accounts. All senders need SPF or DKIM, valid forward and reverse DNS, TLS, sensible message formatting, and low spam complaint rates. Senders that reach roughly 5,000 messages a day to personal Gmail accounts have stricter obligations: SPF and DKIM, DMARC, alignment between the visible sender domain and the authenticated domain, and one-click unsubscribe for marketing or subscribed mail. Gmail also treats a domain that crosses the bulk threshold once as a permanent bulk sender.

For business websites, the important distinction is transactional versus promotional mail. Password resets, receipts, booking confirmations, and form confirmations should be narrow, predictable, and easy to trust. Campaign mail should have unsubscribe handling and should not be allowed to damage the reputation of operational messages. Microsoft’s DMARC guidance is useful here because it shows a common failure: SPF can pass for a provider’s bounce domain while DMARC still fails because that domain does not align with the visible From domain.

One newer wrinkle: DMARC’s current IETF standard is RFC 9989, published in May 2026. The practical rollout still starts with p=none and aggregate reports, then moves toward enforcement only after real senders are known and aligned. Do not treat old percentage rollout recipes as a substitute for reading the reports.

Where business sites usually fail

• The CMS sends through local server mail or an old SMTP plugin nobody owns.
• A contact form uses the visitor’s email address as From instead of using it only as Reply-To.
• Checkout, campaigns, forms, helpdesk replies, and booking tools all send as the same domain with no separation by purpose.
• DNS has drifted: multiple SPF records, missing DKIM selectors, stale vendor includes, or an SPF include chain that exceeds the 10-lookup limit.
• DMARC exists at p=none, but nobody reviews reports or knows which systems should be allowed to send.
• Old staging sites, cron jobs, and abandoned integrations can still send as the brand.

A practical cleanup plan

1. Inventory every sender. List each message type, trigger, CMS plugin or service, visible From, technical sender, DNS records, and business owner. Agencies should do this before changing DNS; owners should do it before blaming the hosting company.
2. Separate mail by function. Keep transactional website mail separate from marketing. Use subdomains when a third-party system needs its own reputation or alignment path, especially for campaigns, CRMs, and helpdesks.
3. Fix authentication deliberately. Publish one valid SPF record per domain or subdomain, keep SPF lookup depth under control, enable DKIM for every real sender, and publish DMARC with aggregate reporting. Parked domains and unused subdomains should have defensive records rather than being left open for spoofing.
4. Repair the application layer. Standardize From, Reply-To, return path, and message headers. Contact forms should send from a controlled address such as [email protected], with the visitor in Reply-To. Move fragile default mail paths to authenticated SMTP or API delivery where appropriate.
5. Monitor what actually happens. Review DMARC reports, provider dashboards, server logs, and real message headers. A password reset that fails silently is an operations incident even if most mail appears to work.

Checks that save time

When inheriting a WordPress, Drupal, or custom build, these checks usually reveal whether the issue is DNS, infrastructure, or application behavior:

dig TXT example.com
dig TXT _dmarc.example.com
dig TXT selector1._domainkey.example.com
dig -x 203.0.113.25

Then 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 and confirm that the SPF or DKIM domain aligns with the visible From domain.

A safe observation record often starts like this:

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

That is not the finish line. It is the controlled way to discover who is really sending before you tighten policy to quarantine or reject unauthenticated mail.

Where Greg fits

This work often falls between the website team, DNS provider, hosting provider, CRM vendor, and mailbox platform. Greg is useful when the business needs one person to trace the path end to end, clean up old decisions, fix the website and DNS pieces, and leave behind a setup the team can maintain.

For owners and operations leads, the outcome is fewer lost enquiries, cleaner support flows, and less guesswork. For agencies, it is a practical remediation and handoff piece that reduces post-launch risk. If website email affects sales, support, bookings, or account access, ask Greg to audit the mail path.

Related on GrN.dk

• Form Spam Is a Lead-Quality Problem: A Practical Hardening Playbook for Business Websites
• Sending Mail with Drupal: Reliable Setup for Modern Sites
• When URL Parameters Become an Operations Problem: Fix Crawl Waste, Cache Fragmentation, and Duplicate URLs

Need help with this kind of work?

Get a mail-path audit Get in touch with Greg.

Sources

• Gmail Help: Email sender guidelines
• Gmail Help: Email sender guidelines FAQ
• Microsoft Learn: Set up DMARC to validate email in Microsoft 365
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance
• RFC 7208: Sender Policy Framework