The Definitive Guide to Bulletproof Website Email for WordPress

Website email should be boring, reliable and almost invisible. But when it fails, it can break some of the most important parts of your WordPress site.

That sounds obvious, but it is also one of the easiest things to ignore until something stops working. A form enquiry does not arrive. A customer does not receive their password reset. A WooCommerce order confirmation lands in spam. A user cannot access gated content. A support notification silently disappears. A membership renewal email is delayed. A new lead fills in a form and nobody on the team ever sees it.

When website email fails, it rarely looks dramatic from the outside. The website still loads. The pages still work. The forms still submit. WordPress may even say the message has been sent.

But sent does not always mean delivered.

At Make Do, we see this problem regularly on WordPress websites, especially older sites, inherited sites, eCommerce sites, membership sites, brochure sites with important contact forms, and business-critical websites that have gradually become more important than anyone originally expected.

The issue is simple: most WordPress websites are not very good at sending email by default.

That is not because WordPress is broken. It is because website hosting and email delivery are different jobs. Your web server is designed to serve web pages. It is not usually the best place to send important transactional email from.

For low-risk websites, this might not matter much. For business-critical websites, it absolutely does.

What We Mean by Website Email

When people think about email, they usually think about Outlook, Gmail, Microsoft 365, newsletters, inboxes and marketing campaigns.

That is not what this guide is mainly about.

Website email means the automated emails generated by your website. In WordPress, this can include:

• Password reset emails
• New user registration emails
• Contact form notifications
• WooCommerce order confirmations
• Customer account emails
• Membership emails
• Booking confirmations
• Download links
• Admin notifications
• Lead generation form submissions
• Support request confirmations
• Security alerts
• Two-factor authentication messages
• Invoice and payment notifications

These are often called transactional emails. They are not newsletters. They are not general marketing messages. They are messages triggered by an action on the website.

A user asks to reset their password. A customer places an order. A visitor fills in a form. A staff member receives a notification. A client downloads a document. A member updates their account.

In many cases, website emails are not optional. They are part of the website’s core functionality. If password reset emails fail, users cannot access their accounts. If form notifications fail, enquiries can be missed. If WooCommerce emails fail, customers may lose confidence in the order process. If internal notifications fail, the business may not even realise that an important action has taken place.

That is why website email should be treated as part of the site’s technical infrastructure, not as a background feature or an afterthought. For any website that supports sales, enquiries, customer accounts, bookings, downloads or internal workflows, reliable email delivery is part of the website working properly.

The Common Problem: WordPress Sends Email from the Web Server

A default WordPress website will usually try to send email using the server it is hosted on.

That can work.

It often works well enough during early development, low-volume use or basic testing. Someone fills in a form, an email lands in the inbox, everyone moves on.

The problem is that “working once” is not the same as having a reliable delivery setup.

Many website servers are not configured as trusted mail-sending systems. They may not have the right authentication records. They may share infrastructure with other sites. They may send from a technical server address rather than a properly verified domain. They may not provide useful logs, bounce reporting or delivery information.

From the point of view of Gmail, Microsoft 365, corporate firewalls, spam filters and security tools, this can look suspicious.

An email might be sent from the website, but blocked before it reaches the recipient.

It might land in spam.

It might be delayed.

It might be accepted by one mailbox provider and rejected by another.

It might work for your team but fail for your customers.

It might work today and stop working after a DNS change, hosting move, security update or stricter filtering rule.

This is where website teams get caught out. WordPress reports that the email has been sent, but there is no simple guarantee that the message reached the inbox.

Why This Matters More Than It Used To

Email filtering is stricter than it used to be, and rightly so.

The volume of spam, phishing, spoofing and automated abuse means mailbox providers have to be more careful about what they accept. Microsoft 365, Google Workspace, Gmail, Outlook, corporate security gateways and anti-virus systems all make decisions about whether a message looks trustworthy.

They do not only look at the content of the email. They also look at where it came from, whether the sending domain is authenticated, whether the sending server is allowed to send for that domain, and whether the message aligns with modern email security expectations.

This matters for WordPress because many websites send email in a technically weak way.

A typical weak setup might look like this:

• The website is hosted with one provider.
• The organisation’s main email is managed by Microsoft 365 or Google Workspace.
• WordPress sends messages directly from the web server.
• The sending address looks like it belongs to the organisation.
• The domain’s DNS records do not clearly authorise that website server to send email.
• There is little or no logging when emails fail.

From the organisation’s point of view, this might seem harmless. The website is simply sending a form notification or password reset.

From the recipient’s mail system, it can look like a message claiming to be from a domain without enough proof that it is allowed to send from that domain.

That is where SPF, DKIM, DMARC and verified sending domains come in.

You do not need every member of the team to understand these records in detail. But you do need someone responsible for making sure they are in place, correct and tested.

The Real-World Symptoms of Poor Website Email

Poor website email delivery does not always announce itself clearly.

Sometimes the first sign is a customer complaint:

• “I tried to reset my password but nothing arrived.”
• “I filled in your form last week and nobody got back to me.”
• “I never received my order confirmation.”
• “I can’t access the download.”
• “I checked spam and it’s not there.”

Sometimes the signs are internal:

• Sales enquiries are down, but traffic looks normal.
• Customers keep calling instead of using the website.
• Support tickets increase because self-service account flows do not work.
• Staff stop trusting website notifications.
• The team starts manually checking form entries in WordPress because emails cannot be trusted.
• Someone creates a workaround, then another workaround, then another.

This is where a small technical weakness becomes an operational problem.

If your website supports lead generation, customer accounts, bookings, downloads, online sales, applications, memberships, support requests, risk assessments, safety documents or any other business process, email reliability matters.

The website does not need to be an eCommerce giant for this to be important. A simple contact form can still be commercially critical if it is where new work comes from.

Why Allowlisting (whitelisting) Is Usually Not the Full Answer

When email delivery problems appear, one of the first suggestions is often to allowlist the sender. This can help in specific cases, especially if an internal firewall, spam filter or corporate mailbox system is blocking messages from a known source. As a short-term workaround, it may be enough to get website emails flowing again for that organisation.

However, allowlisting is not usually a strong long-term fix. It only helps within the systems you control, and it does nothing for customers or users receiving email through Gmail, Outlook, Yahoo, iCloud or other external mail providers. It also does not properly authenticate the sending domain, improve reporting, or provide better visibility of bounces, failures and delays.

Most importantly, allowlisting does not solve the underlying issue: the website is still relying on basic server-generated email. For business-critical website email, the more reliable approach is to use a dedicated transactional email provider that is designed for authenticated delivery, monitoring and support.

The Better Setup: Use a Dedicated Email Delivery Service

A dedicated email delivery service sits between your WordPress website and the recipient’s mailbox.

WordPress still generates the email. The delivery service sends it. That distinction matters.

Your website can still trigger password resets, form notifications, order confirmations and user emails exactly as before. But instead of asking the basic web server to deliver those messages, WordPress passes them to a specialist email platform designed for sending, authenticating and reporting on email delivery.

Common providers include Mailgun, SendGrid, SMTP2GO, Postmark, Amazon SES and others.

At Make Do, we have used several of these platforms for clients. Our usual default is Mailgun because it is reliable, flexible and works well for the type of WordPress and web application projects we support.

The principle is the important thing, not the brand. For most serious WordPress sites, website email should be sent through a properly configured external email delivery service.

What Mailgun Does in This Setup

Mailgun is a transactional email delivery platform. In a WordPress context, it allows your website to send email through Mailgun’s infrastructure using a verified domain or subdomain. That means the website is no longer relying on the basic mail capabilities of the hosting server.

A typical setup might use a dedicated subdomain such as:

mail.example.com

or:

webmail.example.com

This subdomain is then verified in Mailgun using DNS records. These records prove that the organisation controls the domain and authorises Mailgun to send email for that subdomain.

Once verified, WordPress is configured to send transactional email through Mailgun, usually via an API connection or SMTP configuration.

The visitor, customer or user does not need to know any of this is happening. They simply receive the email from the website as expected.

Behind the scenes, the setup is cleaner, more reliable and much easier to diagnose if something goes wrong.

A Lightweight View of the Technical Setup

This is the short version of what usually needs to happen.

First, a sending subdomain is created. This is normally a subdomain of the main website domain, such as mail.example.com.

Second, that subdomain is added to the email delivery platform, such as Mailgun.

Third, the platform provides DNS records that need to be added wherever the domain’s DNS is managed. This might be Cloudflare, the domain registrar, the hosting provider or an IT-managed DNS system.

These records commonly include:

• SPF records, to show which service is allowed to send email for the domain.
• DKIM records, to cryptographically sign messages and prove they have not been tampered with.
• MX records, where required by the sending provider.
• CNAME records, often used for tracking, verification or provider-specific routing.
• DMARC alignment should also be reviewed as part of the wider domain email setup.

The exact values are unique to each domain and should be copied from the email delivery platform, not reused from another site.

Once the DNS records are added, the domain is verified. This can be quick, but DNS changes can sometimes take time to propagate.

Finally, WordPress is configured to use the delivery service. This may involve a Mailgun plugin, an SMTP plugin, an API key or a custom integration, depending on the website.

The final step is testing. Password resets, contact forms, order emails and admin notifications should be tested properly, not assumed to work.

Why We Prefer a Dedicated Sending Subdomain

Using a subdomain keeps website email separate from the organisation’s main human email system.

For example, your staff might use:

[email protected]

… through Microsoft 365 or Google Workspace.

Your website might send through:

mail.example.com

… via Mailgun.

That separation is useful.

It avoids unnecessary interference with the main business email setup. It gives the website its own authenticated sending route. It makes reporting cleaner. It helps distinguish transactional website email from normal staff email.

It also means that if the website email setup needs to change later, the impact on the organisation’s main inboxes is reduced.

This is especially important when an organisation has an external IT provider managing Microsoft 365, Google Workspace, DNS, security and email policies. The website team and IT team need to coordinate, but they should not be fighting over the same configuration.

Where WordPress Email Reliability Matters Most

Some websites can tolerate the odd missed notification. Many cannot.

A proper transactional email setup becomes more important when the website handles:

• Lead generation
• Sales enquiries
• WooCommerce orders
• Customer accounts
• Membership areas
• Online bookings
• Application forms
• Document downloads
• Safety data sheets
• Client portals
• Intranets or extranets
• Password-protected content
• Support forms
• Event registrations
• Payment confirmations
• Two-factor authentication
• Password resets

Password reset emails are worth calling out specifically.

If a user forgets their password and the reset email does not arrive, the account system is effectively broken for that user. It does not matter if the rest of the website is technically online. The user cannot access what they need.

That creates support work. It damages confidence. It can stop a customer, member, supplier or staff user from completing a task.

The same is true of form emails. A form that submits but does not notify the right person is worse than a form that visibly fails, because the user thinks the message has been sent and the business may never know it was missed.

The Difference Between Sending and Knowing

One of the biggest advantages of using a service like Mailgun is that it gives you visibility over what happens after WordPress sends an email. With basic server email, WordPress may confirm that a message was sent, but there is often very little information about whether it was accepted, delivered, delayed, bounced, rejected or blocked further down the chain.

A transactional email platform does not make email delivery perfect, and no provider can guarantee that every message will reach every inbox. What it does provide is a much stronger support position. Instead of guessing, repeatedly testing the same form, or relying on “WordPress says it sent”, you can check the delivery logs and see how the recipient’s mail system responded.

For support teams, this is a major improvement. It turns invisible email problems into diagnosable technical issues, giving everyone a clearer route to investigate and fix the problem.

Mailgun, SendGrid, SMTP2GO or Something Else?

Mailgun is not the only option.

SendGrid, SMTP2GO, Postmark, Amazon SES and other providers can all be valid choices. The right platform is usually shaped by the website’s requirements, volume, reporting needs, existing systems and who will manage the account.

For many WordPress websites, the decision is less about finding the perfect provider and more about moving away from basic server email.

A good setup should provide:

• Authenticated sending
• Clear DNS verification
• Reliable transactional delivery
• Useful delivery logs
• Bounce and failure visibility
• A clean WordPress integration
• A sensible cost model
• Ownership that is clear between the website team, client and IT provider

At Make Do, we tend to reach for Mailgun first because it fits our support model and we know how to configure, monitor and troubleshoot it. But we are not religious about it. The important thing is that the website has a proper email delivery layer.

What Can Go Wrong Without This

The most frustrating website email problems are often the inconsistent ones. A form might work for one person but fail for another. Password resets might arrive for Gmail users but disappear for people using Microsoft 365. Internal notifications might work reliably for months, then suddenly stop after an IT policy change, hosting migration, DNS update, plugin change or tighter mailbox filtering rule.

This is what makes the problem difficult to diagnose. A single successful test does not prove the setup is reliable. Someone can submit a form from their own email address, receive the notification, and assume the issue is fixed, while customers or staff using different mail systems are still affected. That is why website email needs to be tested and configured as a proper delivery system, not treated as something that is working just because one message arrived.

These problems are common because email delivery involves several systems at once:

• The WordPress website
• The web server
• The email plugin or form plugin
• The sending domain
• DNS records
• The transactional email provider
• The recipient’s mailbox provider
• Spam filtering and security tools
• Corporate firewall rules
• The recipient’s own mailbox settings

A reliable setup does not remove all complexity, but it gives you a proper foundation.

The Role of DNS

DNS is often where website email reliability is either solved or made worse.

DNS records tell the internet which services are allowed to do things for a domain. For email, this includes which systems can send on behalf of the domain and how those messages should be authenticated.

For a Mailgun setup, DNS records are generated inside Mailgun when the sending domain or subdomain is added. These records need to be copied into the domain’s DNS management system.

This is why the website team often needs help from whoever manages the client’s DNS. That might be the client’s IT provider, internal IT team, domain registrar, Cloudflare account holder or hosting provider.

The key point is this: DNS values should not be guessed.

They should be taken directly from the sending platform and added carefully.

Small mistakes matter. A missing character, wrong hostname, duplicated domain, incorrect proxy setting or old conflicting record can stop verification or reduce deliverability.

Once the records are added, they need to be verified and tested.

WordPress Plugins and Configuration

There are several ways to connect WordPress to an external email service.

For Mailgun, this can be done using the Mailgun plugin or another SMTP/API plugin that supports Mailgun. In more complex projects, the integration may be handled in a more controlled way within the website’s codebase.

The setup normally includes:

• The Mailgun domain name
• An API key or SMTP credentials
• A from address
• A from name
• Tracking settings, where appropriate
• A test email function
• Logging or reporting settings

The from address should be chosen carefully. It should make sense to the recipient and align with the domain setup. In many cases, it might be something like:

• [email protected]
• [email protected]
• [email protected]
• [email protected]

For some websites, the address does not need to receive replies. For others, replies need to go to a real mailbox or shared inbox.

That decision should be made intentionally.

A common mistake is letting forms, plugins and WordPress all use different from addresses. This can create authentication and deliverability issues. A more controlled approach is to set a consistent website sending address, then use reply-to fields where needed.

For example, a contact form notification can be sent from [email protected], but the reply-to address can be the email address submitted by the user.

That keeps the sending authenticated while still allowing the team to reply to the enquiry easily.

Testing Website Email Properly

A proper test is more than pressing submit on one form and checking one inbox.

For a business-critical website, we would usually test the key email flows. These might include:

• A password reset email
• A contact form notification
• A customer-facing form confirmation
• A WooCommerce order email
• A new user registration email
• An internal admin notification
• Any membership, booking or download email
• Any custom application or integration email

Testing should include different mailbox providers where possible, especially Microsoft 365 and Gmail.

The delivery platform logs should also be checked. The question is not only “did the email arrive?” but also “did the system send it through the correct route, with the correct authentication, and can we see the delivery event?”

Once tested, the setup should be documented.

That documentation should include which service is used, which domain or subdomain sends email, who owns the account, where the DNS is managed, which WordPress plugin or integration is used, and what the expected from address should be.

That may sound basic, but it saves a lot of time later.

Costs and Ongoing Ownership

A transactional email setup is not usually a large cost, but it is still a real service that needs ownership.

There may be:

• A monthly provider fee
• Usage-based sending costs
• Setup time
• DNS coordination
• Testing time
• Support time
• Ongoing monitoring or troubleshooting

For many client websites, this is a modest monthly addition compared with the risk of lost leads, failed password resets or missed customer emails.

The larger question is ownership:

• Who owns the Mailgun, SendGrid or SMTP2GO account?
• Who has access?
• Who receives billing alerts?
• Who handles DNS changes?
• Who checks delivery logs if something fails?
• Who updates the WordPress integration if credentials change?
• Who tests email after a hosting migration, domain change or major plugin update?

If nobody owns these questions, the setup will eventually drift.

At Make Do, we usually prefer to make this part of the wider website support and hosting conversation. Website email is not separate from reliability. It is part of the reliability of the website.

When We Recommend Reviewing Website Email

We would usually review website email when:

• A website is being migrated to new hosting
• A WordPress site is being taken over from another agency
• A client reports missing form enquiries
• Password reset emails are unreliable
• A WooCommerce site is being stabilised
• A membership or portal site is being improved
• DNS or email provider changes are planned
• A site is moving to Cloudflare
• A business relies on website-generated enquiries
• A form plugin, CRM integration or automation workflow is being rebuilt
• A Reliability Sprint or technical audit is being carried out

It is also worth reviewing before a major campaign, product launch, recruitment push, event registration period or customer communication drive.

If you are about to rely on the website to generate leads, process orders, onboard users or send important notifications, you should know whether its email delivery is trustworthy.

Website Email and Forms

Contact forms are one of the most common places where this problem appears. A form can submit successfully, store the entry in WordPress and display a thank-you message to the user, while the email notification fails silently. This creates a dangerous false positive.

The user believes the enquiry has been sent. The business believes no enquiry has arrived. Both sides are acting on incomplete information.

A better form setup should include:

• Reliable email delivery
• Stored entries in WordPress or the CRM
• Clear admin notifications
• Customer confirmation emails where appropriate
• Spam protection
• A tested reply-to setup
• Integration logging where possible

Email delivery is only one part of the form workflow, but it is one of the most important.

For lead generation websites, this can directly affect revenue. A missed form enquiry is not just a technical issue. It is a missed commercial opportunity.

Website Email and WooCommerce

WooCommerce adds another level of importance.

Order confirmations, payment emails, account emails, password resets, renewal notifications and admin order alerts are all part of the customer experience.

If these emails fail, customers may contact support, duplicate orders, lose trust or abandon future purchases.

For WooCommerce sites, we would rarely want to rely on basic server email. The more orders the site processes, the more important proper transactional email becomes.

A dedicated delivery provider also makes troubleshooting easier when a customer says they did not receive an order email. You can check the email log and see whether the message was sent, delivered, bounced or rejected.

That is far better than guessing.

Website Email and CRM Integrations

Many WordPress sites now sit alongside CRM systems, marketing platforms, support tools and automation workflows.

A form might send an email, create a CRM lead, notify a sales inbox, trigger a Slack alert and send a confirmation to the user.

In that type of setup, email reliability is one part of a broader chain.

If email is weak, the whole process feels unreliable, even if the CRM integration is working.

This is why we prefer to think about website email as part of platform reliability. It connects to lead capture, support, operations, reporting and customer experience.

A good setup is not glamorous. It just quietly works.

That is the point.

The Make Do Approach

When we review a WordPress website, we do not assume the existing email setup is good enough just because emails appear to be sending.

We look at what the website needs to send, how important those emails are, how they are currently being delivered, and whether the current setup gives the client enough reliability and visibility.

For simple low-risk sites, the recommendation may be light-touch.

For important sites, we usually recommend a dedicated transactional email provider.

Our typical approach is:

• Identify the website’s important email flows.
• Check how WordPress is currently sending email.
• Review the from address and domain alignment.
• Set up or recommend a dedicated sending domain or subdomain.
• Coordinate required DNS records with the client or IT provider.
• Configure WordPress to send through Mailgun or another suitable provider.
• Test password resets, forms and key notifications.
• Check delivery logs.
• Document the setup.
• Include the configuration in ongoing support and hosting checks.

This is not about adding complexity for the sake of it. It is about removing a fragile dependency from the website.

A business-critical WordPress site should not rely on hope as its email strategy.

What Good Looks Like

A good WordPress email setup should be stable, authenticated and easy to support. The website should send from a verified domain, with SPF and DKIM configured correctly, DMARC considered as part of the wider email setup, and delivery handled separately from the basic web server.

It should use a consistent from address, sensible reply-to settings for forms, and tested delivery for key flows such as password resets, WooCommerce orders, membership emails and admin notifications. Delivery logs should be available, ownership should be clear between the client, agency and IT provider, and the setup should be documented so that, if something fails, there is a clear place to investigate.

That is the difference between basic website email and proper transactional email.

Website Email Is Infrastructure

Website email is easy to underestimate because it sits quietly behind the scenes. It is not usually visible on the homepage, it is not part of the design system, and it is rarely the feature stakeholders focus on during a redesign. But when it fails, the impact is immediate.

A website that cannot reliably send password resets, form notifications, order confirmations or customer emails is not fully reliable. It creates support issues, loses sales opportunities, weakens the customer experience, disrupts internal processes and damages trust.

WordPress is a capable platform, but the default server email setup is often not enough for serious websites. For important transactional emails, a dedicated provider such as Mailgun, SendGrid or SMTP2GO is usually the stronger long-term approach. WordPress can still generate the messages, but a specialist email service handles delivery, authentication and reporting.

This gives the business a more reliable setup, clearer visibility when something goes wrong, and fewer avoidable support issues caused by missing, delayed or undelivered website emails.