How to Email Subscribers When a New WordPress Post Is Published
You can automatically email subscribers when a new WordPress post publishes by using a workflow automation plugin to connect the Post Published trigger to a Send Email action. The whole setup takes under 15 minutes and requires no code. The harder problem, which almost no tutorial covers, is making sure those notification emails actually reach the inbox instead of the spam folder.
This tutorial walks through the complete setup: collecting subscribers, building the notification workflow, customising the email, and verifying deliverability. We tested this on a self-hosted WordPress 6.5 site running PHP 8.2. The steps below reflect exactly what you will see on screen.
Before diving into the steps, one orientation note. This tutorial focuses on self-hosted WordPress.org sites.
WordPress.com has a built-in follower notification system under Settings Discussion that works without any plugin. If you are on WordPress.com, that is the place to start, as documented in the WordPress.org documentation.
What You Need Before Starting
- A self-hosted WordPress site running WordPress 6.2 or higher and PHP 7.4 or higher.
- A way to collect subscriber emails. A contact form, a subscription block, or a user registration flow all work. The workflow listens for whichever event you choose.
- An SMTP plugin or transactional email service. WordPress’s native wp_mail function uses PHP mail, which most hosts do not authenticate properly. Without SMTP, your notification emails will land in spam at a rate that makes the whole feature pointless. More on this in the deliverability section below.
- Krom Automation installed and active. The free version on the WordPress.org plugin directory includes the Post Published trigger and Send Email action you need for this exact workflow.
If you have not installed the plugin yet, follow the installation guide first. It takes about two minutes.
Step 1: Decide How You Are Collecting Subscribers
Your notification workflow needs a list of people to email. How that list is built determines which approach works best for you.
The three most common patterns on WordPress are:
- Registered WordPress users. Anyone who has created an account on your site. The Send Email action can target all users or a specific role. No separate list management needed.
- Form submissions stored as user meta or in a custom table. A subscriber enters their email via a form, and your workflow stores that email somewhere queryable. This is the most flexible pattern but requires a bit more setup.
- An email marketing platform list. Subscribers sign up via Mailchimp, MailerLite, ConvertKit or similar. Your post notification goes out through that platform, not through WordPress directly. This is the most deliverability-safe option because those platforms handle authentication on your behalf.
For this tutorial we focus on the native WordPress approach: emailing registered users when a post publishes. If you want to sync subscribers to an external list first, the Mailchimp integration documentation and the MailerLite integration documentation cover that path in detail.
Step 2: Build the Post Notification Workflow
Go to WordPress Admin Krom Automation Workflows and click New Workflow. You will land on the visual canvas. The canvas uses a drag-and-drop interface where every workflow starts with a trigger node on the left and connects to action nodes on the right.
2a. Set the Trigger
Click the trigger node and choose Post Published from the trigger list. You will see a configuration panel slide in on the right side of the screen. Set the following:
- Post Type: Post (or whichever post type you publish to).
- Category filter: Leave blank to fire on every new post, or select one or more categories if you only want to notify subscribers about specific topics. A site publishing in five categories but only wanting to alert subscribers about one of them should set this filter here rather than adding conditional logic later.
- Status transition: The trigger fires when post status changes to “publish”. This means scheduled posts that go live automatically will also trigger the workflow, which is usually what you want.
For a full reference of what this trigger passes downstream, including all available merge tags, see the free triggers reference.
2b. Add the Send Email Action
Click the plus icon after the trigger node and add a Send Email action. The configuration panel shows four fields:
- To: Enter the email addresses of your subscribers, or use a merge tag that resolves to a list. For registered users with the Subscriber role, you can build a simple query. For small lists under 500 addresses, entering a distribution list address here is the most practical approach.
- Subject: Use merge tags to make it dynamic. A subject like
New post: {{post_title}}takes two seconds to write and performs meaningfully better than a generic “New post from our blog”. - Body: Write the email body here. Include
{{post_title}},{{post_excerpt}}and{{post_url}}at minimum. These pull the live post data at the moment the workflow executes. - From name and From email: Set these explicitly. Leaving them as WordPress defaults means the email comes from “WordPress” at your domain, which looks unprofessional and hurts open rates.
Merge tags are covered in full in the merge tags documentation. Every post field you can imagine is available: title, excerpt, URL, featured image URL, author name, publish date and more.
A subject line with the actual post title gets clicked. A subject line that says “New post from our blog” gets ignored. The merge tag takes two seconds to add.
2c. Configure Run Once Per Post
Open the workflow settings panel and enable Run Once Per Entity. This prevents the workflow from firing multiple times if a post is accidentally saved to draft and re-published.
Without this setting, a post updated from draft to publish twice sends two notification emails to every subscriber. Enable it on every notification workflow.
For a complete walkthrough of workflow settings including pausing, notes and import/export, see the workflow settings documentation.
2d. Test Before Activating
Use the built-in Workflow Simulator before switching the workflow live. The simulator runs the workflow in dry-run mode: it processes the trigger, evaluates conditions and steps through every action, but sends no actual emails and makes no database changes. You will see exactly what the email would contain, including which merge tags resolved and which did not.
The simulator documentation shows you how to supply a test post ID so the dry run uses real data. Once every field looks correct, activate the workflow using the toggle at the top of the canvas.
Step 3: Fix Deliverability (The Step Everyone Skips)
This is the section that determines whether any of the above actually works. We have seen sites with a perfectly configured notification workflow where subscribers reported never receiving emails. Every single time, the root cause was deliverability, not the workflow itself.
WordPress sends email via PHP’s mail() function by default. Most shared hosts do not configure DKIM or SPF records for mail sent this way, which means receiving mail servers treat it as suspicious. Gmail, Outlook and Apple Mail all apply aggressive spam filtering to unauthenticated email from web servers.
The Deliverability Checklist
Work through these in order. Skipping ahead to item 3 without completing item 1 wastes time, because unauthenticated mail gets filtered regardless of content quality.
- Add SPF and DKIM records to your domain’s DNS. SPF tells receiving servers which IP addresses are allowed to send email for your domain. DKIM adds a cryptographic signature to each email that proves it was not tampered with in transit. Both records live in your domain’s DNS panel. Your hosting provider or email provider should document exactly what values to add. Without these two records, skip the rest of this list and fix this first.
- Install an SMTP plugin and connect a transactional email service. Services like Amazon SES, Postmark, Mailgun or SendGrid handle authentication correctly and maintain sending reputation over time. Free tiers on most of these services cover thousands of emails per month, which is enough for most WordPress blogs. The SMTP plugin (WP Mail SMTP is widely used, as is FluentSMTP) replaces the PHP mail function with an authenticated API call to your chosen service.
- Set a consistent From address that matches your domain. Sending from a Gmail or Yahoo address while your site lives at yourdomain.com is an instant spam signal. The From email in your workflow’s Send Email action must use your own domain.
- Add a plain-text version of the email. HTML-only emails score worse on spam filters. Most SMTP plugins handle this automatically if you configure them to, but verify it in your email testing tool.
- Test deliverability before your first real send. Mail-tester.com gives your email a deliverability score out of 10 and shows exactly which checks passed or failed. Run a test email through it before activating your workflow. Aim for 9 or above. A score below 7 means subscribers on Gmail will likely never see your notifications.
The WordPress documentation on plugin basics does not cover email deliverability because it is an infrastructure concern, not a WordPress concern. That is precisely why every plugin tutorial skips it and why subscribers end up not receiving emails.
A perfectly configured workflow sending to spam is indistinguishable from a broken workflow. Fix authentication before you blame the plugin.
Step 4: Handle Category-Specific Notifications
Some sites publish across multiple topics and want to let subscribers opt in to specific categories. A reader interested in tutorials should not receive every product announcement. This is a filtering problem, and there are two ways to solve it.
Option A: Separate workflows per category. Build one workflow for each category with the category filter set on the Post Published trigger. This is the simplest approach and requires no conditional logic. The downside is that managing 8 categories means 8 workflows to maintain.
Option B: One workflow with conditional branching. Use a single Post Published trigger and add Yes/No branches based on the post’s category. Each branch routes to a Send Email action targeting the appropriate subscriber segment.
This is cleaner at scale but requires understanding how conditions work. The conditions and branching documentation walks through the exact logic.
Either option works. Choose Option A if you have fewer than 5 categories and a small team. Choose Option B if you are building this for a large publication where workflow sprawl becomes a maintenance burden.
Step 5: Add a Delay for Scheduled Posts
If you schedule posts to go live at a specific time, consider adding a short delay between the Post Published trigger and the Send Email action. A 5-minute delay gives you a window to catch a typo or pull the post back before every subscriber has already received the notification.
Add a Delay node between the trigger and the action on the canvas. Set it to 5 minutes.
If you need to cancel the send, deactivate the workflow before the delay expires. The delays and scheduling documentation covers how queued actions behave when a workflow is paused mid-execution.
What to Do When Subscribers Do Not Receive the Email
If the workflow ran but subscribers report not receiving anything, work through this in order:
- Check the execution log first. Go to Krom Automation Logs and find the execution for the post in question. The log shows every step with a pass or fail status. If the Send Email step shows a failure, the error message will identify whether the problem is authentication, a bad recipient address, or a timeout from your SMTP provider.
- Check the spam folder. Ask a subscriber to check spam before assuming the email was never sent. If it is landing in spam, the problem is deliverability (see Step 3), not the workflow.
- Verify the From address. An unrecognised From address is the fastest route to spam. Check that the From email in your workflow matches the domain you authenticated in DNS.
- Check WP-Cron. Krom Automation runs actions via Action Scheduler, which depends on WP-Cron. On very low traffic sites, WP-Cron can fire late if no page loads occur during the scheduled window. Configure a real server cron job to call wp-cron.php on a fixed schedule (every minute is standard). Your host’s control panel or a system cron entry handles this. The WordPress Cron documentation explains the difference between WP-Cron and system cron.
- Check the Run Once setting. If the workflow is set to Run Once Per Entity and the post was previously published (even briefly), the workflow will not fire again. This protects against duplicates but can confuse troubleshooting. The execution log will show a “skipped” entry with the reason.
Connecting to an External Email List
The native Send Email action works well for smaller lists and internal notifications. For lists above roughly 2,000 subscribers, or for sites that want subscriber management features like unsubscribe handling, bounce processing and open rate tracking, connecting to an email marketing platform is the right choice.
The workflow structure changes slightly. Instead of a Send Email action, you trigger a campaign in your external platform by adding or tagging a contact when a post publishes. The platform then handles delivery to your full list using its own authenticated infrastructure.
Documentation for the platforms we support:
- Mailchimp integration: subscribe, tag, and sync WordPress users automatically.
- ConvertKit integration: subscribers, tags, sequences, and forms.
- MailerLite integration: subscribe, unsubscribe, and manage groups.
- FluentCRM integration: contacts, tags, and lists for teams running CRM inside WordPress.
These integrations are Pro features. The free plugin handles Send Email natively with no external platform required.
Past 2,000 subscribers, managing bounces and unsubscribes inside WordPress becomes a part-time job. An external platform earns its cost at that point.
What This Workflow Looks Like in Practice
Here is the complete workflow structure for a site that publishes tutorials and wants to email all registered subscribers within 5 minutes of each new post going live:
| Node | Type | Configuration | Why it matters |
|---|---|---|---|
| 1 | Trigger: Post Published | Post type: Post, Category: Tutorials | Fires only when a tutorial publishes, not every post type |
| 2 | Delay | 5 minutes | Gives a window to cancel if the wrong post goes live |
| 3 | Action: Send Email | To: subscriber list, Subject: New tutorial: {{post_title}} | Dynamic subject increases open rate versus generic subject |
Should You Build This Yourself or Use a Dedicated Newsletter Plugin?
This is the honest trade-off table most tutorials do not include. The right answer depends on your list size and what you value.
| Factor | Workflow automation approach | Dedicated newsletter plugin |
|---|---|---|
| Setup time | Under 15 minutes for a simple notification | 30 to 60 minutes including list import and template setup |
| Subscriber management | Manual or via user roles, no built-in unsubscribe UI | Built-in subscribe/unsubscribe, list segmentation, GDPR tools |
| Bounce and complaint handling | Depends on your SMTP provider’s dashboard | Automatic bounce and complaint processing |
| Open and click tracking | Not included in the native Send Email action | Included in most newsletter plugins |
| Best for list size | Under 500 subscribers or internal team notifications | 500 or more, or any list with public signup |
| Works alongside other automations | Yes, the same workflow engine handles all site events | Depends on the plugin’s integration capabilities |
For sites where the goal is a simple “subscribers get an email when a post goes live” and the list is small, the automation approach is faster and adds no extra plugin to maintain. For sites building a real newsletter operation with segmentation and analytics, a dedicated newsletter plugin or external platform is the more sustainable choice, and the automation layer connects the two.
Other Tools Worth Knowing About
Pollify is wpRigel’s poll, survey and quiz plugin. It is built as native Gutenberg blocks, which means creating a poll inside a post works exactly like adding a paragraph.
No shortcodes to paste, no separate interface to configure. If you are sending post notifications to subscribers, embedding a quick poll in those posts is a natural way to drive engagement back to the site.
Commandify is a command palette for the WordPress admin. Press Cmd or Ctrl plus K and you can jump to any screen, search any content, or run admin actions without navigating menus.
It is the only WordPress command palette with real WooCommerce order, product and customer commands built in. For teams managing a lot of content, it cuts the time spent clicking around the backend considerably.
Next Steps
The workflow itself is straightforward. The two things that determine whether it actually works are deliverability configuration (Step 3 above) and choosing the right approach for your list size (the trade-off table above). If you are starting fresh, complete the DNS authentication steps before activating the workflow.
If you are troubleshooting an existing setup, start with the execution log in Krom Automation and check mail-tester.com before changing anything else. For a broader look at what automation can handle on a WordPress site, the overview of how Krom Automation works is a useful next read.
Try Krom Automation free on WordPress.org
Frequently Asked Questions
Why are my subscriber notification emails going to spam?
The most common cause is unauthenticated email. WordPress sends via PHP mail by default, which most hosts do not sign with DKIM or list in an SPF record.
Install an SMTP plugin, connect a transactional email service, and verify your DNS records. Test your setup at mail-tester.com before activating the workflow.
Can I send post notifications to registered WordPress users instead of an external list?
Yes. The Send Email action lets you specify recipient addresses directly, including addresses you retrieve from registered users.
For small sites where all subscribers have WordPress accounts, this is the simplest approach. For public subscriber lists, you need a form-based signup flow and a way to store those email addresses.
How do I filter notifications so subscribers only get emails for specific categories?
Set the Category filter on the Post Published trigger. The trigger only fires when a post in the selected category publishes.
For multiple subscriber segments with different category preferences, either build separate workflows per category or use conditional branching inside a single workflow. The conditions and branching documentation covers the branching approach.
Will the workflow fire if I schedule a post to publish automatically at a future time?
Yes. The Post Published trigger fires whenever a post’s status transitions to “publish”, whether that happens immediately or via a scheduled publish. If you add a 5-minute delay node after the trigger, you have a short window to cancel the email send by deactivating the workflow before the delay expires.
Does this work for custom post types, not just standard posts?
Yes. When configuring the Post Published trigger, the Post Type field includes all public post types registered on your site. Select the custom post type you want to monitor and the trigger behaves identically to a standard post trigger.