Home » Exchange Server » Emails from Website Not Received in Exchange or Exchange Online

Emails from Website Not Received in Exchange or Exchange Online

A lot of businesses have one or more contact forms on their public website that are used by customers to get in touch with the company for sales, customer service, and other enquiries.

What I frequently encounter with customers is the case where all other emails are being received by the company just fine, but they are not receiving any of the contact form submissions from their website. If the company is busy enough with enquiries coming in via phone or direct email, they might not notice this for quite a while, and it can be quite alarming to suddenly discover that opportunities have been missed simply because an email was never received.

There are three common causes of this problem:

  • Web hosting problems
  • Spam filters
  • SPF records

Web Hosting Problems

It’s very common for businesses to register a domain name and host their public website with the same web hosting provider. DNS hosting is usually included for free with such a package, and the web host helpfully adds a bunch of DNS records to the zone that they host to point things at their servers. This is fine, it’s helpful for their customers and reduces the friction with establishing a web presence for businesses that can’t afford specialist assistance.

Email hosting is often also included in those web hosting deals. The problems begin when the customer decides to host their email elsewhere, such as in Office 365 or an on-premises Exchange server. Things start to go wrong when:

  • The MX record is changed to point somewhere other than the web hosting company servers
  • The DNS zone has been delegated to other name servers (not always, but tends to be a factor in most of the cases I deal with)
Why would a company delegate their DNS zone to other servers, when their web hosting is offering free DNS hosting? Often it’s due to a need for more reliable DNS than the web host provides, or additional features that the web host doesn’t provide, such as the health checks, automatic failover, and geo-DNS that AWS Route 53 and others can provide.

What tends to happen is the web host is configured to always deliver email locally, while the rest of the world uses the MX record to determine where email should be delivered. In effect, the web hosting server ignores what is in DNS in favour of its own local configuration. The customer either ends up with a bunch of emails sitting in a “catch all” mailbox on the web hosting server, or the emails just error and get dropped by the server completely (but nobody ever finds out until someone notices a lack of website enquiries).

web-server-sending-to-wrong-mx

Fortunately, the solution is often as simple as making a configuration change in your web hosting control panel. The exact steps will be different, depending on the control panel that your provider is using. If you can’t find the correct options, or some guidance in their help documentation, then you should contact your web hosting customer support for more assistance.

Spam Filters

Another common cause of emails from website contact forms not delivering is spam filters. Most web sites will simply make use of an SMTP instance on the local server to send emails. Others will use various SMTP functions built in to the language or platform that the website runs on.

Either way the result is the same – the emails are coming *from* the web server’s IP address. The IP space for a lot of web hosts, particularly low cost shared web hosting providers, tends to have a pretty bad reputation in the eyes of spam filters around the world. This tends to result in either:

  • SMTP connection attempts being outright rejected by connection filtering
  • Emails submitted from those IP addresses receiving a high spam score

The outcome is that the emails do not arrive in the recipient’s inbox, and either get rejected entirely, filtered into a quarantine, or delivered to a junk email folder.

In Exchange on-premises and Exchange Online we can add a rule to bypass spam filtering for emails arriving from specific IP addresses.

spam-bypass-rule

On the Exchange Server Pro Podcast, MVP Brian Reid explained that Exchange Online Protection will still block malware coming from a white-listed IP address, and may block the SMTP connections if it becomes obvious that the IP address is a source of malware or actual spam.

If you’re running a third party email security appliance or service, look in the configuration of that product for an equivalent bypass rule.

Another option, which removes the dependency on the web server IP address remaining the same, is to route emails from the website through an SMTP service such as Amazon Web Services SES.

SPF Records

The last root cause I want to mention here is SPF records. This ties in to the topic of DNS above, but deserves a specific mention. Organizations that have implemented SPF (which you should), and who are filtering inbound email based on SPF results, will often discover that emails originating from an IP address that is not included in the SPF record are not being received.

spf-rejection

If the web form needs to use your domain as a “From” address, then the solution is to add the web server IP address to the SPF record for your domain. You can learn more about SPF in my SPF primer for Exchange admins.

Alternatively, as with the problem of web server IP addresses looking spammy, you can use third party SMTP services such as AWS SES to send your web form emails, which often simplifies compliance with SPF and other frameworks like DKIM.

amazon-ses

Summary

In this article I’ve covered three common causes of emails sent from websites not being delivered to recipients. Web forms are widely used and are usually critical to a business, so Exchange admins need to make sure that emails are being successfully delivered. Aside from the technical solutions mentioned in this article, it’s also a good idea to periodically test your website contact forms to catch any other issues that might come up from time to time.

Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Exchange Server

2 comments

  1. Lister says:

    Another issue is when the application is set to use and internal address as the from address. The spam filters catch it as a spoofed address.

  2. Arrowmax says:

    Another reason is the website code which generates the email “helpfully” uses the person who completed the webform’s address as the From address of the email generated. This is to allow the recipient to just reply to the webform email to reach person who filled it in. What it actually does is create a spoofed email that spam filters are designed to pick up. If, for example, the person who filled in the webform has a Gmail address then the email generated will not match Gmail’s SPF record and all the other systems designed to determine an email’s authenticity.
    Please, website coders, stop doing this!

Leave a Reply

Your email address will not be published. Required fields are marked *