Quick Answer
A WordPress email delivery checklist should confirm the site administration address, the notification settings that generate email, the sender domain, the mail transport, DNS authentication, plugin ownership, and a narrow test note before changing production settings. For a small publisher, the best fit is not "install an SMTP plugin and move on." The safer workflow is: identify which WordPress message failed, confirm the recipient and sender, check whether wp_mail() only handed the message to the mail layer, verify SPF, DKIM, and DMARC for the sending domain, then record one controlled delivery test.
Operator Checklist
| Review area | What to confirm | Why it matters |
|---|---|---|
| Message type | Admin notice, password reset, comment moderation, contact form, or plugin alert | Different messages may use different plugins or headers |
| Recipient | Site administration address, author address, form recipient, or shared mailbox | Prevents debugging mail transport when the wrong inbox is configured |
| Sender identity | From address, From name, domain, and reply-to path | Receiver trust depends on domain alignment |
| Mail transport | Host PHP mail, SMTP plugin, API mailer, or managed host service | Shows who owns retries, logs, and authentication |
| DNS records | SPF, DKIM, and DMARC status for the sending domain | Helps receiving services authenticate domain mail |
| Evidence note | Time, message type, recipient, sender, transport, and outcome | Keeps the next fix from starting over |
When Should A Publisher Review WordPress Email Delivery?
Review WordPress email delivery when password reset messages do not arrive, comment moderation notices are missed, contact form submissions disappear, plugin alerts are inconsistent, new-user notifications go to the wrong person, or a hosting migration changes the sender path.
Email delivery is an operations problem with several layers. WordPress can prepare a message, a plugin can change headers, the host can hand the message to PHP mail or SMTP, DNS records can authenticate the sender, and the recipient mailbox can still filter or reject the result. If the operator treats all of that as one black box, the next failure becomes harder to diagnose.
The official wp_mail() reference is an important boundary for public claims: a successful return value means WordPress was able to process the send method, not that the recipient received the message. That distinction should shape the checklist. A public article can explain the review path, but it should not claim inbox placement or deliverability success without actual test evidence.
Step 1: Identify The WordPress Message
Start with the specific message that failed. "WordPress email is broken" is too broad for a useful fix.
- [ ] Record whether the missing message was a password reset, admin email change, comment moderation notice, new-user email, form submission, order-style plugin email, backup alert, security alert, or custom plugin notice.
- [ ] Confirm the expected recipient address.
- [ ] Confirm the expected sender address and sender name.
- [ ] Check whether the message is generated by WordPress core, a theme, a plugin, or an external service.
- [ ] Note whether the issue affects every message or only one workflow.
- [ ] Avoid changing DNS, plugins, and host settings in the same pass.
This first step prevents the common wrong fix: changing the whole mail stack when only a comment notification setting or form recipient was wrong.
Step 2: Confirm The Administration Address
WordPress General settings include the site administration email address. WordPress documentation describes this address as the place where administration and maintenance messages are sent, and it notes that comment moderation notices can also use it depending on Discussion settings.
Use this review table:
| Field | Better operator note | Common mistake |
|---|---|---|
| Site administration email | Shared operations mailbox or current owner address | Old founder, agency, or personal inbox |
| Admin user email | Current user account email | Assuming it is the same as the site address |
| Forwarding address | Who receives forwarded mail | Forwarding to an unmonitored list |
| Change owner | Who can approve or confirm address changes | Changing it during an incident without owner consent |
| Public exposure | Whether the address appears publicly | Confusing private admin email with contact-page display |
The best fit for a solo publisher is usually a shared operations mailbox controlled by the site owner, not a contractor's mailbox. If multiple people need alerts, use a managed forwarding group or helpdesk address rather than scattering plugin-specific recipient fields.
Step 3: Map Notification Settings
The WordPress Discussion settings documentation shows that comment notification options can send email when someone posts a comment or when a comment is held for moderation. Those settings matter because a comment moderation problem may be a configuration issue before it is a mail delivery issue.
Use this checklist before touching the mail transport:
- [ ] Confirm comment notification settings under Discussion.
- [ ] Check whether comments are enabled for the affected post type.
- [ ] Check whether the expected recipient is the site administration email, post author, form recipient, or plugin-defined address.
- [ ] Check spam, promotions, quarantine, and forwarding rules for the recipient mailbox.
- [ ] Confirm whether a plugin has its own notification settings separate from WordPress core.
- [ ] Record which setting changed, if any.
For a content site, missed moderation notices are operationally important because they can delay legitimate community signals or hide spam-review work. Still, the first decision is narrow: choose the specific notification path and verify it before making wider changes.
Step 4: Treat wp_mail() As A Handoff, Not Inbox Proof
The wp_mail() function prepares and sends email through the configured method. Its documentation warns that a true return value is not proof that the user received the email. That makes it useful as a boundary in troubleshooting.
Decision path:
| Finding | Better decision | Notes to keep |
|---|---|---|
| WordPress never triggers the message | Review plugin settings, hook, form, or comment workflow | Mail transport is not the first layer |
| WordPress processes the message but inbox is empty | Review transport logs, DNS, recipient filtering, and sender identity | Handoff is not delivery proof |
| Only HTML messages fail | Review content-type handling and plugin email template behavior | Avoid changing global mail settings blindly |
| Only one recipient fails | Check mailbox filtering, forwarding, and address spelling | Domain-wide changes may be unnecessary |
| All messages fail after migration | Review host mail support, SMTP/API credentials, and DNS | Migration likely changed the transport path |
Do not publish raw message headers, mailbox screenshots, recipient addresses, SMTP passwords, API keys, DNS control-panel screenshots, or unredacted mail logs. Use redacted evidence internally and summarize the public lesson.
Step 5: Verify Sender Authentication
Google's sender guidance frames SPF, DKIM, and DMARC as core email authentication controls. For a WordPress publisher, the practical lesson is that the domain in the From address should match the service authorized to send the message. If WordPress sends from news@example.com through a host, SMTP provider, or API mailer, that sending path needs to be represented in DNS and provider settings.
Use this decision table:
| Authentication item | What to check | Operator note |
|---|---|---|
| SPF | Sending service is included in the domain's SPF record | Note the service owner, not the full DNS value |
| DKIM | Sending service signs mail for the domain | Record provider and selector, redacting private keys |
| DMARC | Policy exists after SPF/DKIM are working | Record policy level and report owner |
| From alignment | Visible From domain aligns with authenticated sender | Avoid generic host addresses when possible |
| New sender | DNS was updated after adding an SMTP or API mailer | Prevents stale authentication records |
| Monitoring | DMARC reports or provider logs have an owner | Turns delivery into an ongoing operation |
Do not treat SPF, DKIM, and DMARC as a magic guarantee. They help receiving systems authenticate mail, but inbox placement can still depend on content, reputation, recipient rules, rate, and provider behavior. The checklist should keep claims at the level the sources support.
Step 6: Choose One Mail Transport Owner
WordPress mail problems get messy when several plugins and services all try to own the same sender path. A small publisher should be able to answer one simple question: which layer is responsible for sending WordPress email today?
- [ ] Host PHP mail is allowed and monitored, or it is intentionally bypassed.
- [ ] SMTP or API mail plugin has one owner.
- [ ] The plugin sender domain matches DNS authentication records.
- [ ] API keys, SMTP credentials, and provider accounts are stored outside public content.
- [ ] The fallback behavior is known if the mail service fails.
- [ ] The plugin update path is included in the normal plugin update checklist.
- [ ] The rollback path is documented before switching providers.
The better choice is a single documented transport with logs and DNS ownership. If the site relies on contact forms, password resets, moderation alerts, and admin notices, email is production infrastructure, not a decoration.
Step 7: Run A Narrow Delivery Test
Testing should answer one question at a time. A useful test note does not need to expose private mailboxes or headers publicly.
Minimum evidence fields:
| Evidence field | Example note | Public-safe? |
|---|---|---|
| Message type | Password reset or comment moderation notice | Yes |
| Sender domain | Same domain as the site | Usually yes |
| Recipient type | Operations mailbox, author, or test mailbox | Yes, if not exposing address |
| Transport | Host mail, SMTP plugin, API mailer, or managed service | Usually yes |
| Outcome | Received, delayed, bounced, filtered, or unknown | Yes |
| Private details | Full address, headers, keys, logs, and DNS values | No |
If the test fails, choose the next layer based on evidence. A WordPress trigger failure points to settings or plugin behavior. A processed message with no inbox result points to transport logs, DNS authentication, mailbox filtering, or provider rejection. A sender mismatch points to DNS and provider configuration.
What Should A WordPress Email Delivery Checklist Include?
A WordPress email delivery checklist should include the failed message type, expected recipient, site administration email, notification settings, sender domain, wp_mail() handoff boundary, active mail transport, SPF/DKIM/DMARC status, plugin owner, rollback path, and a redacted test note. The practical order is: name the message, confirm the recipient, confirm the sender, identify the transport, verify sender authentication, test one message, then record the outcome.
This is not a legal compliance checklist or a bulk email marketing playbook. It is a site-operations workflow for keeping WordPress administrative and editorial notifications understandable.
Common Questions
Does wp_mail() prove the email reached the inbox?
No. The WordPress function reference warns that a successful return value does not automatically mean the recipient received the email. Treat it as a handoff signal, then check transport logs, DNS authentication, and the recipient mailbox.
Should every WordPress site use an SMTP plugin?
Not always. The best fit depends on the host, sender domain, logs, and owner. A small site can use host mail if it is reliable and authenticated, but an SMTP or API mailer may be easier to monitor when notifications are business-critical.
Why do comment moderation emails use a different address than expected?
WordPress Discussion settings can send moderation notices to the site administration email from General settings. Review both settings before changing the mail service.
Are SPF, DKIM, and DMARC enough to guarantee delivery?
No. They help authenticate the domain and reduce sender confusion, but they do not guarantee inbox placement. Recipient filtering, sender reputation, message content, rate, and provider policies can still affect delivery.
What evidence belongs in a public article?
Public content can describe the checklist, cite official docs, and explain safe decision criteria. Do not publish private email addresses, message headers, SMTP credentials, API keys, DNS control-panel screenshots, provider logs, or customer messages.
Source Notes
- https://developer.wordpress.org/reference/functions/wp_mail/ checked 2026-06-10; used for source-derived analysis of the WordPress email handoff boundary, sender filters, content type behavior, and the warning that a processed send is not inbox proof.
- https://wordpress.org/documentation/article/settings-general-screen/ checked 2026-06-10; used for source-derived analysis of the WordPress site administration email address and maintenance-message routing.
- https://wordpress.org/documentation/article/settings-discussion-screen/ checked 2026-06-10; used for source-derived analysis of comment notification and moderation email settings.
- https://wordpress.org/documentation/article/site-health-screen/ checked 2026-06-10; used for source-derived analysis of Site Health as a technical inventory surface for WordPress version, plugins, server details, and relevant configuration review.
- https://support.google.com/a/answer/81126?hl=en checked 2026-06-10; used for source-derived analysis of sender authentication expectations for SPF, DKIM, DMARC, From alignment, and sender infrastructure.
- https://knowledge.workspace.google.com/admin/security/set-up-spf checked 2026-06-10; used for source-derived analysis of SPF as a sender-authorization record that should be updated when a new mail sender is introduced.
- https://knowledge.workspace.google.com/admin/security/set-up-dkim checked 2026-06-10; used for source-derived analysis of DKIM setup, verification, and provider ownership.
- https://knowledge.workspace.google.com/admin/security/set-up-dmarc checked 2026-06-10; used for source-derived analysis of setting up DMARC after SPF and DKIM are working and assigning report ownership.
No private WordPress dashboard, admin email address, mailbox, SMTP plugin, email service account, DNS zone, message header, contact form submission, provider log, API key, customer message, support ticket, or live delivery test was inspected for this article. If a future operator adds redacted headers, provider logs, DNS screenshots, or mailbox test evidence, attach those artifacts in the internal runbook and narrow public claims to match the evidence.
Internal Link Notes
Link to wordpress-site-health-review-checklist when the operator needs a broader inventory before changing plugins or server settings. Link to wordpress-debug-log-checklist when a plugin, theme, or PHP warning may explain why a notification was never generated. Link to wordpress-comment-spam-moderation-checklist when the missed email involves comment workflow. Link to wordpress-plugin-conflict-troubleshooting-checklist when mail behavior changes after plugin updates. Link to wordpress-security-checklist-for-blogs when sender authentication, admin mailbox ownership, or credential handling needs a security-oriented review.
Update Note
Review this checklist every 60 days. Recheck official WordPress wp_mail() documentation, General settings, Discussion settings, Site Health documentation, and Google sender authentication guidance. Refresh earlier after a hosting migration, mail-provider change, SMTP/API plugin change, DNS migration, domain change, bulk sender policy update, plugin conflict, contact form incident, or repeated missed WordPress notification.