Help, I’m not getting emails from the plugin!

✓ Free ⭐ Premium

If emails from Church Admin aren’t arriving, the cause is almost always one of a small number of well-understood problems. This page walks through each one in order — start at the top and work down.

The best solution — use a dedicated email service

Before troubleshooting, it’s worth knowing that the most reliable fix for email problems is to use a dedicated email delivery service rather than sending through your web host. Both Mailersend and Brevo handle authentication, rate limits, and spam filtering automatically, and both have free / hobby tiers. If you haven’t set one up yet, do that first:

If you’re already using Mailersend or Brevo and emails still aren’t arriving, skip to the relevant section below.

Step 1 — Send a test email

Go to Church Admin → Communications → Email settings and click Send test email. This sends a test message using your current settings and shows full debug output if something goes wrong. The debug output is the most useful starting point for diagnosing any problem.

Send test email button in Church Admin email settings

Step 2 — Check whether your host has disabled email sending

Some web hosts — particularly budget shared hosting — disable the server’s native mail function entirely to prevent abuse by spammers. If the test email fails immediately with no SMTP error, this is likely the cause.

The fix is to use either Mailersend, Brevo, or SMTP settings instead of native WordPress mail. Native WordPress mail is the least reliable option and should be avoided if possible.

Step 3 — Check whether emails are going to spam

Since 2022 Google, Yahoo, and other major providers have become significantly stricter about which emails they accept. Emails sent from a WordPress website without proper authentication are routinely rejected or sent to spam. The authentication records that matter are:

SPF (Sender Policy Framework)

An SPF record is a DNS TXT record that tells email providers which servers are authorised to send email on behalf of your domain. Without it, emails from your website look suspicious to receiving servers.

How SPF records work

DKIM (DomainKeys Identified Mail)

DKIM is a DNS record that cryptographically signs outgoing emails so receiving servers can verify they haven’t been tampered with. It’s more complex than SPF but more reliable — it also survives email forwarding, which SPF doesn’t.

Both records need to be added to your domain’s DNS. If you use Mailersend or Brevo, they provide the exact values to add during their setup process. If you’re using SMTP, ask your hosting company or domain registrar to add them — it’s in their interest to do so as it helps all their customers’ emails get delivered.

You can check whether your domain has SPF and DKIM records at mxtoolbox.com.

Step 4 — Set up SMTP

If you’re not using Mailersend or Brevo, the next best option is to send through an SMTP account — an actual email account at your church’s domain rather than through the server’s native mail function. This looks far less like spam to receiving servers.

Set up an email address at your church domain (for example admin@stpauls.org.uk), note the SMTP settings from your email provider, then go to Church Admin → Communications → Email settings and select Send using SMTP server.

SMTP server option in Church Admin email settings

Fill in the SMTP host, port, username, password, and security type from your email provider. For Gmail you’ll need to use an App Password rather than your regular Google account password — see Google’s App Password instructions.

SMTP settings fields in Church Admin

Step 5 — Check email queueing

Most shared web hosts limit how many emails can be sent per hour — typically around 100. If your directory has more than 100 people and you’re sending a bulk email, emails beyond the limit will fail silently unless you have queueing set up.

Go to Church Admin → Communications → Email settings and configure queueing:

Email queueing settings
  • Server Cron — a Linux cron job runs on your server at a set interval and sends a batch of emails each time. More reliable since it runs at a fixed time regardless of website traffic. You set it up in your hosting control panel (cPanel) using the command shown on the settings screen.
  • WordPress Cron — sends a batch of emails triggered by the next website visit after the scheduled interval. Simpler to set up but less predictable on low-traffic sites — emails may go out later than expected if nobody visits the site.

Set the maximum emails per hour to stay within your host’s limit. If you’re not sure what your limit is, start with 50 and increase it if needed.

Step 6 — Check whether your host’s IP is blacklisted

On shared hosting, your website shares an IP address with many other websites. If any of those sites have been used for spam, the IP may be blacklisted by major email providers — causing your emails to be rejected even when your own setup is correct.

Check at mxtoolbox.com/blacklists.aspx. If your IP appears on any blacklists, raise a support ticket with your hosting company and ask them to investigate and request delisting.

Step 7 — Check for plugin conflicts

If you have other email-related plugins installed — WP Mail SMTP, Easy WP SMTP, or similar — they can override Church Admin’s email settings and cause unexpected behaviour. Deactivate any such plugins and test again.

Step 8 — If you’re sending to yourself

Some hosting providers have a setting that prevents a website from sending email to an address on the same domain — for example a site at stpauls.org.uk cannot send to an @stpauls.org.uk address. If test emails fail when sending to your own address but work to an external address, this is likely the cause. Contact your hosting provider and ask them to disable this restriction.

Still not working?

If you’ve worked through all the steps above and emails still aren’t arriving, the debug output from the test email is the most useful thing to share with support. Go to Church Admin → Settings → Debug log immediately after a failed send attempt and copy the log to include in your support request.

Related tutorials