Email Delivery Issues
Sending an email is far more complex than we are used to think, so extremely different issues can result in a common problem: emails are not delivered. In this page we try to cover all possible issues that should be checked when emails are not delivered to the final mailboxes.
Test from the Status panel
Be sure the status panel id not reporting errors. If so, try to fix them.
The status panel offers a test feature where you can send out few emails to specified addresses using the same method used by Newsletter when delivering your newsletters.
Do not test only a single email address, test one ore more address on different domains, like gmail, hotmail, your own domain and so on.
There are two common errors you can easily solve:
- “Could not instantiate mail function”: is a problem of your provider, read more here to solve the problem
- “Connection timeout” (when you use an SMTP): you set the wrong SMTP parameters (double check them) or your provider is blocking external connections: open a ticket and find out with them
If you got an error OR you got a success message but the test emails is not delivered:
- never set as sender email address something like …@gmail.com, …@yahoo.com and so on, use your own domain
- your sender address is the same of the receiver address (do not test from email@example.com to firstname.lastname@example.org many mail service providers drop that emails)
- wait at least 15 minutes, some provider is really slow in sending emails
- check the spam folder: if your email is classified as spam your server is probably black listed (use and external SMTP service)
- you set a sender email address on main Newsletter configuration which is a non existent mailbox or which has not the same domain of your blog -> change that email
- you set the reply to or the return path on main Newsletter configuration and your server does not like that -> empty them
- you set a sender name and your server does not like it-> use a plain one without accented characters or empty it (specially on Windows installations)
- change the mail body encoding on main Newsletter configuration -> try all the values
- you configured an SMTP but something is not correct -> test the SMTP on its configuration panel
Test with Mailtrap
Mailtrap is a test system which gives you an “fake” SMTP service. This service traps all the emails sent and show them in a console. It’s a perfect way to see if a plugin is actually sending an email and then understand if the problem is in the plugin or in the system which receive it and should deliver it.
Here an article about testing delivery with Mailtrap. Of course if your provider is blocking connections to external SMTPs you cannot use Mailtrap (and you probably should consider to change provider).
The sender address I set is not respected
If the newsletters come from a different address than the one your set on sender settings, your provider is changing it. Verify to set as sender address a real mailbox and ask your provider for support is the problem persists.
Everyone receive emails except me
You set the sender as email@example.com and you try to send a newsletter to firstname.lastname@example.org, but it does not work. The problem is who manage the mail for the domain “mydomain.com”. Probably they say: “someone [your blog] is sending emails as email@example.com but that is not possible since only we can send for that domain” and they drop the email.
Contact your mail provider and explain them you need to send from your blog emails with sender firstname.lastname@example.org and to check for block rules, SPF records, DMARC records. Add to your ticket that everyone else on other domains receive the emails.
A possible solution is to set on Newsletter as SMTP the same SMTP they provided for your regular mail, the one you set in your email reader. This is usually a recommended option.
Sometimes emails are delivered sometimes not
This is a classical “limit hit” problem. Many providers pose a limit on the maximum number of emails that can be sent on a time window. Most part of the providers are “flexible”, with a limit of N emails per hours. Other providers are so strict that drop emails if sent more quickly than on every three seconds.
Immediately ask the provider about mail limits and if they have an SMTP service that you can use. If they gave you an SMTP for your personal mail, you can consider to use that setting for Newsletter too.
Godaddy is an example: they require the use of an SMTP (ask them the current configuration to be used that you can set on Newsletter SMTP setting), otherwise emails are sometimes delivered, sometimes not (I answered tens of support question from Godaddy users…).
Problems started few days ago
If you’re sure, 100% sure, you have not changed the configurations, it’s almost surely a provider problem. Providers sometimes activate new spam filter, change servers’ configurations or their network architectures. Sometimes the even change their rules.
Aruba (Italy) is a provider which from time to time activate some spam filter and the emails stop: the best solution is to use and external SMTP (Sendgrid, Mandrillapp, Amazon AWS, Mailjet, …). Most of them offer a free account.
Immediately ask the provider to check the problem, reporting them your configurations.
Tests work, newsletters not
First, test with a real newsletter. Setup few tests subscribers and send a test newsletter. If they ARE delivered, it can be a delivery engine problem.
Pressing the “send” button enqueues the newsletter to the delivery engine. It is moved to the sending status and the delivery engine, at speed configured on main Newsletter configuration panel, sends it to the targeted subscribers. If the delivery engine is not triggered by WordPress, no emails are sent. See the delivery engine documentation page.
If test newsletters ARE NOT delivered but tests from the diagnostic panel ARE, create an empty newsletter and test it. If it works you have a newsletter content problem. Things to check are:
- the mail body encoding (settable on main Newsletter configuration) -> try different values (usually base 64 works on every system, but we experienced cases where the 8 bit encoding was mandatory – your provider should be of help on that topic)
- the content activate spam filters
- check if you have images from other domains -> use only images from your blog domain
- disable the tracking feature
- remove all images
- remove all links
- empty the message and reconstruct it by little pieces testing on each change -> note what you add when it stop to work again (can be a specific word, time ago we had a user with a provider blocking emails with the “update” word inside!)
Spam filters can be installed on your provider server or on mail receiver servers.
Not all emails are delivered
First be sure this is real and not only an hypothesis: how do you know that over 1000 emails sent only a part is delivered? If you’re sure that part of the emails are not delivered (while Newsletter is reporting it sent all), you may have hit a limit and the provider started to drop your emails. Ask them about hourly limits you must set on main Newsletter configuration.
On Diagnostic panel you can enable logs at the debug level (even if to check problem the “normal” level is enough). Log files are generated inside the folder “wp-content/logs/newsletter”. Reading log files are not easy but we can be of help in that task.