When WordPress PHP email fails, the user often doesn't know

[chadbush]

WordPress PHP email sometimes fails to send, depending on the host. There currently is no built-in way for a user to test whether the email works on a particular installation. A tool in Site Health to help verify whether PHP email is working would help.

Adds an administrator-initiated email delivery check to Site Health and General Settings.

WordPress installations frequently depend on server mail configuration for password resets, user notifications, and administration messages, but a successful wp_mail() call does not prove inbox delivery. This change asks administrators to periodically perform and manually confirm a delivery test without adding mail service credentials to Core.

The change:

• adds a recommended Site Health test when delivery has never been tested or the last successful send request is more than 90 days old;
• adds a Verify email delivery button beneath the Administration Email Address setting;
• sends the test to the configured administration address using wp_mail();
• clearly asks the administrator to confirm inbox receipt and inspect sender headers;
• stores a non-autoloaded timestamp only when WordPress hands the message to the mail system without an immediate error;
• reports the test as passed for the following 90 days; and
• keeps the dashboard Site Health state at Should be improved while this check is overdue.

The UI explicitly notes that accepting the message for sending does not guarantee delivery.

## Testing

• php -l src/wp-admin/includes/class-wp-site-health.php
• php -l src/wp-admin/options-general.php
• node --check src/js/_enqueues/admin/site-health.js
• ./vendor/bin/phpcs --standard=phpcs.xml.dist src/wp-admin/includes/class-wp-site-health.php src/wp-admin/options-general.php tests/phpunit/tests/admin/wpSiteHealth.php
• npx grunt jshint:core
• git diff --check

New PHPUnit coverage is included for missing, malformed, future, expired, and current timestamps; successful and failed send requests; invalid administration addresses; non-autoloaded timestamp storage; and Site Health test registration. PHPUnit was not run locally because this host does not have an isolated Core test database; the pull request is therefore opened as a draft for CI and review.

## Use of AI Tools

AI assistance: Yes
Tool(s): OpenAI Codex
Model(s): GPT-5
Used for: Implementing and reviewing the change, generating tests, adapting the prototype to current trunk, and running local validation.

cc/ @Clorith due to the work you did on site health

Thanks for the feedback. I have switched the recipient to the current user and moved the complete workflow into Site Health. The administration-email confirmation screen is a useful idea, but I think it should remain separate follow-up scope.

I had the completely opposite approach to your thought here @aaronjorbin , I would've said that individual user tests aren't as valuable as ensuring deliverability (and access to) the admin email configured on a site, and I would have the check be specifically for that since that covers both that emails work, and that the address they've confirmed is correct is one they can also access then.

I do like the intention behind the idea, let's dive into some initial thoughts I had when looking it over and narrow down some questions, as there are some things I suggest we consider, and have answers to;

A test you're required to make every X days feels a little burdensome on site admins, granted purposes and priorities shift, the initial idea was that checks ran in the background and only required user interaction when something failed, and even then it had clear actions for users of all technical levels.

At the same time, 90 days may not be often enough, the tricky thing about email is that it can change at a whim, your server is blocked one day, your domain ends up on some obscure blocklist the other, different mail-services use different blocklists, how do we account for this to make the test reliable?

Finally, we also need to account for the health checks being reset on every core update (intentionally, as changes in core may have changed the results of your tests on your environment), is this an acceptable level of recurrence?