Sending an email is far more complex than we are used to thinking, so a wide range of different issues can lead to the same problem: emails are not delivered. On this page, we try to cover a few possible issues that should be checked when emails are not delivered to their final destinations.
After reading this article, we have even more specific cases you may be interested in:
- When Test Newsletters Are Not Sent But Test Emails Are
- When Activation or Welcome Emails Are Not Sent
- Test Reports: Could Not Istantiate The mail() Function
First: do a test from with our Delivery Diagnostic page
The Delivery Diagnostic page offers a mailing test feature where you can send out 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 or more addresses on different domains, like Gmail, Hotmail, your own domain and so on.
- “Could not instantiate mail function“: this is a problem of your provider and you need to contact them. It is not about the Newsletter plugin. Read more here on how to solve the problem.
- “Connection timeout“: you’re using an SMTP and probably you set the wrong SMTP parameters (double check them) or your provider is blocking external connections. It is not about the Newsletter plugin. Report it to your provider with the SMTP host address and port.
- “SMTP connect() failed“: you’re using an SMTP and your provider is blocking the connection. It is not about the Newsletter plugin. Report it to your provider with the SMTP host address and port.
You may think “I’m NOT using an SMTP service!” Probably you are and you don’t know it. Check if you have an SMTP plugin installed or if you configured the SMTP of Newsletter (it should be reported on top of the status page).
More on SMTP connect() failed
If you get that error message while sending, it mainly means your blog is blocked when it tries to contact and use the SMTP service to deliver your emails. That kind of block is usually caused by your provider, but let’s see some cases.
- You’re using the internal SMTP of Newsletter. On our SMTP configuration panel, you set up the SMTP parameters (host, port, user, password, protocol and so on) and it is set as enabled.
Case 2: the SMTP service is refusing to respond to your blog delivery request (very rare). You need to contact the SMTP provider
You can run a delivery test from that panel and you should get the mentioned error. Case 1: your hosting provider does not allow your blog to contact the SMTP. You need to open a ticket to your provider reporting the problem and the SMTP *host* and *port* you’re trying to use.
- You’re using and SMTP plugin (which is always recommended). An SMTP plugin redirects all emails sent by your blog to an SMTP service. The problem originates from the same causes, follow the steps described above.
Other checks when there are errors or emails are not delivered
If you got an error OR you got a success message but the test emails are 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 providers are really slow in sending emails;
- check the spam folder: if your email is classified as spam your server is probably black listed (use an external SMTP service);
- you set a non existent mailbox as sender email address on main Newsletter’s configuration panel or an email that has not the same domain of your blog -> change that email;
- you set the reply to or the return path on main Newsletter’s configuration panel 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 that gives you a “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 that receives it and should deliver it.
Here is 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 changing provider).
The sender address I set is not respected
If 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 if 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 manages 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 to 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 receives 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 in a time window. Most parts of the providers are “flexible”, with a limit of N emails per hour. Other providers are so strict that they drop emails if they are sent faster than 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 using 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.
Problems started a 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 filters, change servers’ configurations or their network architectures. Sometimes they even change their internal rules.
Aruba (Italy) is a provider which from time to time activate some spam filters and the emails stop: the best solution is to use an external SMTP (Sendgrid, Mandrillapp, Amazon AWS, Mailjet, …). Most of them offer a free account.
Immediately ask the provider to check the problem, reporting to them your configurations.
Tests work, newsletters not
First, test with a real newsletter. Setup a 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 the 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 a 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 your provider started to drop your emails. Ask the provider about what hourly limits you must set on the main Newsletter configuration page.
On the Diagnostic panel, you can enable logs at the debug level (even if to check for any problems the defaulf level should be enough). Log files are generated inside the folder “wp-content/logs/newsletter”. Reading log files is not easy but we can be of help in that task.