Why won’t your WordPress form emails send?

 If email were a kitten, he’d be slacking and scratching stuff instead of doing what he’s told.

Email is such a long standing tradition that you’d think we’d have it under control by now, right? Well, when it comes to websites and contact forms, Email’s still out of the bag. He’s jumping around, scratching all of your furniture to pieces like an unruly menace instead of just getting to his destination. Get down from there, Email!

So, let’s take a look at why Email and your WordPress forms aren’t behaving today. Keep in mind I’m talking from a cPanel perspective when it comes to changing hosting related options.

Pre-flight checks

It’s important to look at the easier side of things first

Test your form first and make sure it actually submits

Before checking if email’s the true issue, it’s worth taking a moment to test your website’s contact form. Make sure that when you enter data, the form submits correctly and either redirects you to the expected place or shows you a confirmation message. If it doesn’t, you may want to reach out to your developer (or us) to find out what’s going on.

Test general email deliverability with a WordPress plugin

It’s worth seeing if your website is capable of delivering emails at all – maybe your forms aren’t the problem. My personal favourite to diagnose this is Post SMTP Mailer/Email Log so make sure to install and activate this useful plugin!

Next up, visit the plugin’s settings and click ‘Connectivity Test’. It’s likely that your ‘Outgoing Mail Server Hostname’ should remain ‘localhost’ in most cases.

In the ‘Service Available’ column, if you’re seeing ‘No’ next to a port, particularly 25, that could be your problem and it’s worth reaching out to your web host about it.

It’s worth sending a test email regardless of what you see, so head back over to the plugin’s main settings page and click ‘Send a Test Email’. Don’t listen to what Post SMTP says about whether it’s delivered – just check the inbox, and see for yourself.

If you have received a test email, it’s likely the problem lies with your form configuration. If it’s in spam, or if you haven’t received a test email at all, read on. We go deep.

Have a look at your forms’ mail or submission tab

There are a bunch of great form plugins for WordPress. Most of them will have a way for you to manage and format the emails that the forms send. Let’s take a look at my favourite one – Contact Form 7. The process for managing sent emails will be reasonably similar for other plugins such as Gravity Forms.

1. Login to your WordPress website
2. Head to ‘Contact’ in the left sidebar
3. Mouseover your favourite form and hit ‘Edit’
4. Hit the ‘Mail’ tab

Now, you’ll want to check that ‘From’ field contains an email address which is coming from the exact same domain name as the website. Why? Because you’re more likely to have control over how the email from the website domain is sent, versus a domain that potentially isn’t even hosted in the same place, isn’t yours, doesn’t exist etc. If you use the same domain as the website and the website’s accessible, you’re on the right track.

So as you can see here, I’m sending from [email protected] – bear in mind while ‘wordpress@’ will usually work, some mailservers actually won’t accept mail internally from users that don’t exist, so trying to send from an existing email user is an option to try. This means actually creating the email account [email protected] first. It’s rare that you’ll need to, but it can happen.

If that’s all good, make sure Contact Form 7 isn’t reporting any other errors. Your ‘To’ and ‘Additional Headers’ fields need to be formatted correctly. And of course, the email address you place in the ‘To’ field has got to exist. But you knew that.

Figuring out why

Three possible problems, find out which one affects you

Assuming your pre-flight checks are all green, there are three situations that could be happening. Let’s find out which it is.

A) Your form emails are sending to other domains, but not between accounts with your domain name.
To see if the emails are sending to other domains but not your own, add another email address outside of your website’s domain into your form’s ‘To’ or ‘CC’ field. For Contact Form 7, this means adding an ‘Additional Header’ like so. Make sure it’s an email address you have access to, and see if anything comes through to the external email address upon submitting the form. If it does, but not to your domain email address, it’s option A for you.

B) Your website form emails are actually sending, they’re just being marked as spam.
To check whether form emails are hitting spam, submit your form and check your domain email address’ junk or spam folder. Feel free to check with a friend too, it’s useful to know if it’s happening with other email services. If your form email turns up in a spam folder, your website email is getting marked as spam, and it’s option B for you.

C) Your website form emails aren’t sending at all, they just aren’t, okay?
If you’ve exhausted A and B, well that leaves C, the most frightful one. Reader beware, you’re in for a scare – some mailservers can outright delete emails they think are spam, and Scary C) might actually just be Old Man B) in disguise. Really though, you’ll need to do some debugging against both options.

Keep scrolling to find out more about what to do in each of these scenarios.

A) Too embarassed to talk to itself

Your emails are sending to other domains fine, but not between accounts with your domain name

This is a common occurence on cPanel based hosting. It can happen because the domain’s mail routing is set to use ‘Local Mail Exchanger’ or has been set to ‘Automatic’ and then defaulted to local. But before we go changing things, let’s verify if your domain needs a Remote Mail Exchanger.

My favourite place for this sort of quick check is DNS Dumpster – attractive name right? Pop your domain name into the field and see what magic appears before you. So if we take scriptylion.com.au as an example, we can see that our MX records (servers which handle our email) are pointed at Google’s GSuite.

Because these servers aren’t the same as the one hosting our website, we require a remote mail exchanger, and if your email is with GSuite or Office 365, you do too. In fact, if you’re using cPanel together with any third party mail service which resides outside of that cPanel account, it’s a fair bet that you need to set this option.

If you are using cPanel mail, you might see something like ‘mail.yourdomain.com’ or ‘yourdomain.com’ listed instead, and in this case you generally do want to use a local mail exchanger. If setting remote makes things worse, you can always switch it back, bear in mind.

1. Visit your cPanel hosting, likely at something similar to https://hostname.com:2083/
2. Login with your web hosts’ provided username and password
3. Visit Email -> Email Routing if available (if not, you’ll need to ask your host to enable it)
4. Select a domain from the dropdown
5. Select ‘Remote Mail Exchanger’
6. Select ‘Change’

B) Stored away in a tin can for later

Your emails are actually sending, they’re just being marked as spam

Oh boy, this is a big one. This can be caused by blacklist entries against your sending server (not necessarily for good reason), misconfigured SPF records, missing SPF and/or DKIM records, because your server’s IP address was previously sending spam and now isn’t, because your server actually is sending spam, and even because the remote servers receiving your mail just don’t like you today and aren’t in the position to bully you for your lunch money so they simply eat your mail instead. (Some are stubbornly strict)

See if your website’s server is on any spam blacklists

If your server’s IP address has been added to any blacklists, mail sent from it (including mail from your website) is likely to be marked as spam. So, let’s find out your website’s IP address and check for ourselves.

To find out your website’s IP address, the quickest way is the following:

1. Open Chrome browser and load up your website
2. Right click anywhere and choose ‘Inspect’
3. In the Inspector, navigate to ‘Network’ at the top
4. In the main Chrome window, reload the page
5. Click on the very first entry in the Inspector, it might be labelled simply as ‘/’
6. Note the numbers next to ‘Remote Address’

Now that you have your website and hosting server’s IP address, let’s throw it through a blacklist check.

Head on over to MX Toolbox and pop your IP address into the box, then click ‘Blacklist Check’. You want to be seeing either ‘OK’ or ‘TIMEOUT’ on every listing. If you don’t, you either need to inform your web host that the IP address you found is on a blacklist and ask them to action removal, or contact the specific blacklist yourself and request removal. You’d be surprised how often big services like Campaign Monitor and Mailchimp end up with their IPs blacklisted. So don’t think it won’t happen to you! Adding reverse DNS for your hosting server can help keep you off spam blacklists too…

See if your website’s server has reverse DNS

What is Reverse DNS? Important for mail deliverability, mainly. It’s essentially a way to report specific information to the requester in exchange for a provided IP address. So to figure out if your webserver has one of these little blighters, you’re going to want to take your IP address which you found above, and pop it into MX Toolbox’ Reverse Lookup page.

There’s some confusing information about RDNS and PTR (Pointer) records floating around out there, so keep this in mind. Reverse DNS is basically the application of a PTR record to a server by the authority in control of that server – usually the ISP or hosting company. A PTR record is structured, as you might expect, in a reversey kind of way relative to a standard DNS record. So what your ISP or hosting provider actually sets is something kooky like this. The part on the left of ‘IN PTR’ is the ‘name’ and the part on the right of ‘IN PTR’ is the ‘value’.

191.232.77.45.in-addr.arpa IN PTR static.cortex.scriptylion.com

“What even?” you might ask,  “Is that first part literally just your IP address, reversed, with ‘in-addr.arpa’ on the end?”
Yup. That’s a PTR record’s ‘name’ segment for you, and that’s part of why it’s referred to as ‘Reverse’ DNS.

Using our example, when we plug in our regular old IP address (45.77.232.191) to MX Toolbox’ reverse lookup page, it checks against the ‘name’ section which it determines from our regular IP, then returns the following. Notice the keyword ‘static’. Shown below is the ‘value’ segment of the overall PTR record.

static.cortex.scriptylion.com

Just having this record (set to anything with dots, basically, although it should be a fully qualified domain name (FQDN)) in the first place should be enough to keep most blacklists and mailservers happy outside of not sending actual spam.

However, some blacklists and mailservers want you to go a step further than that. They want to ensure that the domain to which your PTR record is pointed also resolves back to your IP address. It’s worth checking out Debouncer’s reverse DNS check to see if your PTR record complies here. They mention old-hat AOL, but don’t let that deter you. There are modern mail servers which are just as strict. To achieve this, we’ve setup the following record with our DNS provider.

static.cortex.scriptylion.com IN A 45.77.232.191

Now get this – some super strict blacklists and mailservers want you to go a step even further if your server is assigned a dynamic IP address. These tough customers consider it good practice to add the keyword ‘static’ into the PTR record to ensure, basically, that someone with half a brain has control over the sending mail server.

Surely if a stressed out server admin has gone to the effort of adding ‘static’ into their PTR record, their server’s IP address probably isn’t going to change anytime soon, and it’s a good bet that this person is at least intending not to send any spam.

If you find that nothing is returned under ‘Domain Name’ in MX Toolbox when you check your IP address, or you find that you don’t pass Debouncer’s reverse DNS check, reach out to your hosting provider and ask why. Either of these issues could be causing certain blacklists and mailservers to route email from your website’s forms into spam folders, or in some cases, even delete the mail without a care in the world.

See if your domain has a misconfigured SPF record

Don’t worry. Your domain isn’t going to get sunburnt (although some emails might), we’re talking about Sender Policy Framework here. Certain email suites like Office 365 will ask you to setup an SPF record that can easily cause your website’s email to be marked as spam.

To check what your SPF record looks like, head on back to our old favourite, DNS Dumpster – and pop your domain into the box. If you don’t see an SPF record starting with “v=spf1”, that could be a problem for some stricter mail servers, however it’s not quite as bad as a misconfigured record. For the sake of example, here’s ours:

v=spf1 mx a ip4:45.77.232.191 include:_spf.google.com ~all

This piece of code is saying, in regular terms:

• (v=spf1) Indicates this is an spf record
• (mx) If an email from an @scriptylion.com.au address is sent from scriptylion.com.au’s mailserver, it’s legit
• (a) If an email from an @scriptylion.com.au address is sent from scriptylion.com.au’s primary IP address, it’s legit
• (ip4:45.77.232.191) If an email from an @scriptylion.com.au address is sent from the specific IP address shown, it’s legit
• (include:_spf.google.com) Add all of the rules from the SPF record set by _spf.google.com in as well as those above
• (~all) If an email from an @scriptylion.com.au address is sent and it doesn’t match these rules, mark it spamtastic, but keep it

Now let’s take a look at the default SPF record that Office 365’s email service will ask you to set:

v=spf1 include:spf.protection.outlook.com -all

Look at that. Straight to the point, rigid little dash. This record’s all business, no fun:

• (v=spf1) Indicates this is an spf record
• (include:spf.protection.outlook.com) Add all the rules from the SPF record set by spf.protection.outlook.com into this record
• (-all) If an email address from an @example.com address is sent and it doesn’t match these rules, delete it; hurl it straight into the sun without bothering to even look at it (so much for sunscreen)

This highly cautious attitude towards incoming email might be all well and good, and even protect you from spoofing more effectively – if you don’t happen to host a website that needs to send email from the same domain. So to loosen up this black suited, crew cut record a little bit and let our slick, cool new website past to dabble in a bit of badass mail delivery, we’d need to change the record to something similar to the following via our DNS provider.

v=spf1 mx a include:spf.protection.outlook.com ~all

All we did was add ‘mx a’ after ‘v=spf1’ and change ‘-all’ to ‘~all’. Look how relaxed that tilde is! This record now reads:

• (v=spf1) Indicates this is an spf record
• (mx) If an email from an @example.com address is sent from example.com’s mailserver, it’s legit
• (a) If an email from an @example.com address is sent from example.com’s primary IP address, it’s legit
• (include:spf.protection.outlook.com) Add all the rules from the SPF record set by spf.protection.outlook.com into this record
• (~all) If an email from an @example.com address is sent and it doesn’t match these rules, mark it spamtastic, but keep it

If SPF confuses the hell out of you, and I don’t blame you if it does, have a play over at SPF Wizard – this is how I mastered it.

No SPF record? Add it to your domain for better deliverability

If your domain doesn’t have an SPF record, some mail servers may reject (delete) mail it sends or send it to spam depending on their configuration.

For SPF, you’ll want to work through SPF Wizard. You’ll generally want to set your domain at the top, set the recommended options in the dropdowns, and choose ‘SoftFail’ for the last one.

This is usually enough, because the ‘mx a’ part of the record that’s automatically inserted should permit your hosting server to send mail on behalf of your domain. Just be aware that if you’re using an external mail service, you will want to include their SPF record in your record too as shown in the example below for Google’s GSuite.

Once you’ve created a record you’ll need to add it to your domain’s DNS provider. Then make sure to run your domain through this SPF Validator to see if you’re on the right track.

Here’s how our record looks in Cloudflare:

No DKIM record? Add it to your domain for better email deliverability

Domain Keys Identified Mail is an encryption method which is used to determine if email is sent from an authorised system… okay that’s enough technical gibber.

What you need to know is that you should probably have DKIM alongside SPF against your domain to keep your server’s emails from being sent to spam or worse, deleted. The way we’re setting it up, it’s basically going to say to email servers “Hey, cPanel specifically on my server is allowed to send mail for my domain. Keep stuff it sends out of spam, please.” So, let’s get it setup:

1. Visit your cPanel hosting, likely at something similar to https://hostname.com:2083/
2. Login with your web hosts’ provided username and password
3. Visit Email -> Email Deliverability if available (if not, you’ll need to ask your host to enable it)
4. Select a domain and click the ‘MANAGE’ button
5. Under ‘DKIM’ click ‘Generate Local DKIM Key’ if you see this button, otherwise simply observe the fields shown

You’ll be presented with two fields – ‘Name’ and ‘Value. These need to go into your DNS provider’s control panel as a TXT record. Here’s how it looks using Cloudflare for example.

C) Form emails really just won’t send, dude

Email just isn’t sending no matter what you try and you could really use a drink and a nap

Track the delivery of your email with cPanel

So your emails still aren’t getting where they’re going. Let’s find out where they are going, and what’s happening to them, by taking a look at cPanel’s delivery reports.

1. Visit your cPanel hosting, likely at something similar to https://hostname.com:2083/
2. Login with your web hosts’ provided username and password
3. Visit Email -> Track Delivery if available (if not, you’ll need to ask your host to enable it)
4. Enter a recipient email that your web form should recently have sent to
5. Click ‘Run Report’

To identify emails that might have come from your web form, take a look at the ‘From Address’ and ‘Recipient’ columns and try to find an example that matches up with your form settings.

A variety of things can happen to emails sent by cPanel. They can be deferred, they can fail, they can be frozen, they can even succeed! This interface will show you the ‘Result’ of each email send attempt. The ideal one is ‘Accepted’. If you’re seeing something else, read it! This column can contain very detailed information from the receiving server on the problem occurring.

It might be that the receiving email doesn’t exist. It might be that the sending email doesn’t exist and the receiving server has to validate their existence. It might be that you’ve reached a limit set by your host such as free space, bandwidth or emails relayed per hour.

What do you do with this information once you have it? It’s hard to say, as the problem could be very different in each case, but here are some examples:

• The result states that the account you tried to reach does not exist, so try to send from your web form to another email address instead
• The result states ‘Sender verify failed’, so try to send via your web form from a real existing email account
• The result states ‘All attempts to reach … failed’, this could be an issue with Port 25 being blocked or the server otherwise configured incorrectly, so contact your web host

Check with your host about Port 25

Did you know that a number of web hosts block port 25 to prevent outgoing spam? This has the side effect of outright blocking a whole freakin’ bunch of legitimate email as well.

So as a last resort, ask your host if they block this port. If they do, ask them how you can have it unblocked and follow their instructions before testing your form again.

D) I’ve had enough, nothing works

When all else fails, use another mail service, they’re generally better trusted and more reliable

Ask yourself, who do you trust more? Google, Microsoft, or a complete stranger with no credentials?

If the answer is either of the former, you’ll part-way understand why sometimes lesser known mail servers just can’t always reliably deliver email. They aren’t immediately trusted, and it can take a lot of work and debugging to create that trust.

So, why not just give up and try something else? I’m not even being sarcastic.

Post SMTP Mailer/Email Log can be configured to send mail via a third party service such as Google Mail, Mandrill, SendGrid or Mailgun. If your own server just won’t budge on sending mail, it’s worth turning to another service that will.

Head to the plugin’s main settings page and click ‘Start the Wizard’ – the plugin will walk you through setting up with different instructions, depending on the email address you tell it that you would like to send from.

It can be a bit of an ordeal to setup the credentials required depending on your email service, but it’s definitely worth it if you can figure your way through.

If you’ve read through all of this, actioned what you can, and your email still won’t send – get in touch, we’ll do our best to help you out.