There is no one key to making sure WordPress site emails are sent reliably and stay out of the recipient’s spam folder. A common recommendation is to use a dedicated email service like Amazon SES, but why? In this article, I’ll look into some of the common causes of WordPress emails going to spam or not being delivered at all.
What Causes WordPress Emails to Go to Spam?
We’ve all been there. Your WordPress email setup seems solid, but you’re still finding that your emails are dumped into your recipient’s spam folder or filtered out before they even get a chance to end up there. This can lead to lost sales and may confuse or anger users who were expecting emails from you, and they may wind up with a bad impression of your company if this is your first interaction with them. Even if it’s not, it will almost certainly lower your overall chances of retaining that user. The more that your emails wind up in spam or get filtered out, the more your reputation suffers.
The truth is that there’s no one thing that can guarantee good deliverability. A multitude of factors come into play, including DNS records, the IP you’re sending from, and email blocklists. In addition, malicious actors may hack your mail server, leading to a further loss in reputation and mail deliverability.
DNS Records and WordPress Emails
Domain Name System (DNS) records are basically instructions that provide important information about domains and hostnames, such as associated IP addresses and how to handle requests. DNS records come in a wide variety of types. This Cloudflare doc lists 25 different types, but that’s by no means an exhaustive list. However, there’s only a few that really impact WordPress emails to any great degree: A, AAAA, CNAME, DKIM, MX, and SPF.
A and AAAA Records
Even if you don’t know much about DNS records, you probably recognize these. The “A” is short for address, and it shows which IP address belongs to a particular domain. AAAA records are essentially the same, but designed for IPv6.
If you’re finding your WordPress site or other emails are going to spam, your A record probably isn’t the culprit. Errors here can certainly impact email deliverability, but an incorrect A record will cause so many other problems that emails going to spam will be the least of your concerns.
You can check any DNS record with the
nslookup command. It will default to displaying the A record if you don’t give it any parameters.
nslookup deliciousbrains.com Server: 192.168.1.1 Address: 192.168.1.1#53 Non-authoritative answer: Name: deliciousbrains.com Address: 22.214.171.124
The answer isn’t authoritative because it’s coming from a server that isn’t the root source for those records. Using the
-type=soa option will get us one step closer to the authoritative answer.
nslookup -type=soa deliciousbrains.com Server: 192.168.1.1 Address: 192.168.1.1#53 Non-authoritative answer: deliciousbrains.com origin = david.ns.cloudflare.com mail addr = dns.cloudflare.com serial = 2290146293 refresh = 10000 retry = 2400 expire = 604800 minimum = 3600
The origin listed is the primary name server. Add that to the original command, and it will give you the authoritative answer.
nslookup deliciousbrains.com david.ns.cloudflare.com Server: david.ns.cloudflare.com Address: 126.96.36.199#53 Name: deliciousbrains.com Address: 188.8.131.52
Canonical Name (CNAME) records point one domain or subdomain towards another domain. The domain name it’s pointing to should have an A record pointing to an IP address. Incorrect CNAME records can result in issues with email deliverability, but just like with A records, it’s likely to show up long before you start worrying about emails hitting spam folders. Use
-type=cname to get these.
Domain Keys Identified Mail (DKIM) records offer a way to verify that the email sender is who they say they are, by offering another layer of verification. DKIM relies on the email being sent to contain a DKIM signature, which is verified against the DKIM DNS record for that domain.
A private key is used by the email sending service to create a DKIM signature hash email header from one or more important parts of the email that should not change, such as the “From:” header and the message body.
The DNS record acts as a public key. The receiving mailbox provider uses it to decrypt the DKIM hash signature back to the original text and verifies that the message still has that same text. This ensures that the message has been sent from the correct domain, and that the email hasn’t been altered in any way.
You may experience significant email deliverability errors if your DKIM records contain errors (or simply don’t exist). Exactly how you add a DKIM record varies from provider to provider.
Mail Exchange (MX) records are what actually direct emails to mail servers for your domain. The MX record shows how emails should be routed according to SMTP, and the priority they are assigned.
Sender Policy Framework (SPF) records specify the servers that the domain is allowed to send email from. This is the same concept as a return address in old-school mail. If you get a letter from your mother, but the return address is wrong, you may be suspicious that the letter didn’t actually come from your dear mother.
Dedicated IP Addresses
If you research the various email providers, you’ll notice that some of them advertise a dedicated IP address you can use for your email. By sending your emails from one dedicated IP address, you don’t run the risk of sending email from the same IP address that has been (or is still being) used to send emails that are being reported as spam.
This sounds like we should all hop on the dedicated IP address train to get better deliverability for our WordPress emails.
Unfortunately it’s not that simple. If you don’t send enough emails to build up a reputation on your dedicated IP address, spam filters won’t know who you are and are more likely to block you. Also, if you get a fresh IP address and immediately start sending out a huge amount of emails, your sending pattern may be confused with a spammer. Spam filters need to trust you first.
The key to successfully adopting and using a dedicated IP address for emails is to send a consistent amount of emails and keep an eye on your reputation. You should also “break in” the new IP address by sending a smaller amount of emails at first and gradually working up to your full email capacity, otherwise known as “warming up” the dedicated IP address.
There are some downsides to dedicated IPs for email sending as well. A dedicated IP usually costs more than a shared IP. They’re also usually more difficult to manage, as each email account needs its own IP address.
Showing Up on Email Blocklists
After all this talk of reputation, I should probably explain what exactly sender reputation is. When you send an email through WordPress or anything else, the recipient’s email service likely checks the domain and IP address that you used and compares them against a blocklist.
There are hundreds of blocklists run by as many different blocklist providers, each containing a database of IP addresses and domain names that are used by spammers. These blocklists mostly rely on users reporting email as spam, so it’s important to monitor your email complaints and make any necessary changes to ensure that you don’t end up on one of these lists. If you do end up on a blocklist, you need to reach out to the blocklist provider for steps to get removed.
A great tool to check to see if you are on any blocklists is MxToolbox. You can provide the domain or IP address you’re using for mail, and within a few seconds it will check dozens of the most popular blocklists.
When we say “malicious actors” in this context, we’re mostly talking about hackers. In this day and age it seems almost impossible not to get hacked. If you’re running your own mail server, it will need constant attention to stay updated and patched against new vulnerabilities.
The problem is compounded when a web server is also acting as a mail server. Neglected content management systems are incredibly easy for a skilled hacker to locate and exploit, at which point it’s possible that they will use the server to send their own mail. And they won’t care much about your reputation!
How Can a Dedicated Email Service Help?
A dedicated email service isn’t the be-all and end-all solution to WordPress email deliverability, but it can definitely help make a lot of these things easier.
For example, Amazon SES automatically sets up SPF and DKIM for its own email servers so that if you don’t set them up yourself, your emails will still pass most spam checks. It does this by setting the “From” field to an alias of Amazon SES, so that SPF and DKIM both pass for amazonses.com:
This results in a “Sent via amazonses.com” message in most email clients, but that’s better than failing and ending up in a spam folder. Of course, you can (and should) set up your own SPF and DKIM records. Our plugin, WP Offload SES, guides you swiftly and easily through this process, step-by-step.
Most dedicated email services will also monitor their own IP addresses in email blocklists, so that’s one less thing that you have to worry about checking yourself. If you run a dedicated IP address, you may have to be more vigilant, but it’s still safer than setting up a dedicated email server of your own.
Sending WordPress email may seem simple, but there’s a lot going on behind the scenes. While it is technically possible to run email through your own server and do all of these things yourself, it’s not something to be taken lightly. Using a transactional email service like Amazon SES will save you the time and hassle of worrying about every small detail, and will ultimately be more secure in the long run.
There are many providers for this, each with their own strengths and weaknesses. You can check out our comparison of Amazon SES, SendGrid, Mailgun, and Sendinblue to see how they stack up.
We usually recommend Amazon SES because it’s cost-effective and works with both our WP Offload SES and WP Offload SES Lite plugins, but the email service you choose should come down to your priorities and the volume of emails you intend to send.
Have you tried running your own mail server before? What challenges did you experience? If you gave up and went with an email provider, what was the final straw? Let me know in the comments.