Email Delivery Issues

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.

What's inside

Run a test from the Delivery Diagnostic page

The System/Delivery Diagnostic page offers a mailing test feature where you can send out emails to specified addresses using the same method used by the Newsletter plugin when delivering your newsletters.

Send tests to many email addresses on different domains/services: Gmail, Hotmail, your own domain, and so on.

The Delivery Diagnostic page is under the System Dropdown menu

Common errors

  1. “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.
  2. “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.
  3. “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 the Newsletter plugin (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.

Using the internal SMTP of the Newsletter plugin

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.

You can run a delivery test from that panel and you should get the mentioned error.

  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
  2. the SMTP service is refusing to respond to your blog delivery request (very rare). You need to contact the SMTP provider

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.

Using an SMTP plugin (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. Possibly report errors to the SMTP plugin author for specific support and error evaluation.

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 as the receiver address (do not test from name@domain.com to name@domain.com many mail service providers drop those 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 blacklisted (use an external SMTP service);
  • you set a non-existent mailbox as the sender email address on the main Newsletter’s configuration panel or an email that isn’t in the same domain as your blog -> change that email;
  • you set the reply to or the return path on the 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 (especially on Windows installations);
  • change the mail body encoding on the 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 shows 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 to a real mailbox and ask your provider for support if the problem persists.

Everyone receives emails except me

You set the sender as newsletter@mydomain.com and you try to send a newsletter to you@mydomain.com, 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 newsletter@mydomain.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 newsletter@mydomain.com 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 the 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, and change servers’ configurations or their network architectures. Sometimes they even change their internal rules.

Aruba (Italy) is a provider which from time to time activates 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, but newsletters not

First, test with a real newsletter. Set up a few test 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 the 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 activates 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 into little pieces testing on each change -> note what you add when it stops working again (can be a specific word, some 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.

Enabling logs

On the Diagnostic panel, you can enable logs at the debug level (even if to check for any problems the default 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.