WordPress password reset email not received: fix delivery

Fix email without confusing account recovery with delivery

The login page tells you to check your email, but the link to choose a new password cannot be found. This confirmation does not locate the failure. WordPress may have recognized the account, a component may have prevented notification, or the recipient server may have filed the message elsewhere. Installing SMTP transport before checking these stages may leave exactly the same problem.

This guide concerns native email from a WordPress installation whose accounts or sending settings you can already administer. If you are completely logged out and the only administrator, start with the account recovery guide: some operations below already require an authorized session. Keep any working session open. Fixing message delivery and immediately restoring your access are two tasks that can progress separately.

Work with a test account belonging to the team and a mailbox you can inspect. Record the site, affected account, time with time zone and result of one request. These details are enough to track an attempt; neither the password nor the complete recovery link belongs in a shared ticket. An old email found after repair is not automatically the correct link to use.

• If only one person receives nothing, start with their address and mailbox.
• If several notifications are missing, examine the shared transport.
• If a transport test arrives but the native link never does, return to generation of that notification.

Approach 1: check the site, account and recipient address

This route needs no plugin. It suits cases where an administrator retains dashboard access and the recipient’s identity is uncertain. Open Users → All Users, then Edit for the exact account. For your own account, Users → Profile leads to the same type of information. Record the profile email address without replacing it merely to obtain a faster result.

Native recovery uses this user address by default. The administration email under Settings → General serves another function: changing it does not redirect every account’s recovery links. Similarly, a mailbox with the same name on an old domain does not automatically become the current profile address. Check characters, domain, aliases and whether the mailbox actually exists.

If a profile correction is necessary, make it only for the verified account owner and save with Update Profile or Update User, according to the screen. Then follow any requested confirmation. A pending change is not an already effective address. Read the profile again to see which address is actually stored. Retain the original value and correction justification in private records without disclosing other users’ data.

The site may also use WordPress.com login or an external identity provider. In that case, use that service’s account recovery when it authenticates the user. Changing local WordPress SMTP does not fix email sent by the other platform.

In multisite, involve the super administrator if accounts or transport are managed at network level. A user’s address may be shared between several network sites: correct their actual profile, not merely a subsite contact address. If settings are unavailable, do not seek elevated permissions solely for this repair.

1. Confirm the domain and environment: public site, test copy or old site.
2. Find the account by username and verify its effective address.
3. Return to the same site’s login page and make one request for this account.
4. Wait for the result in the corresponding mailbox; to undo an incorrect correction, restore the original address through the profile process.

Check the mailbox before changing WordPress

Check the provider’s webmail as well as your usual email application. This comparison distinguishes a message absent from the server from one received but hidden by phone or computer synchronization. Search for the site name and approximate time in all folders: inbox, spam, archive, trash and automatic categories. The displayed sender name may differ from the domain in the actual address.

Examine sorting rules, forwarding and blocked addresses available in mailbox settings. A rule immediately archiving mail may explain the lack of a visible notification. A full mailbox or forwarding to an old address can also move the problem outside WordPress. If you find the message in spam, sending works at least for that attempt; further work concerns classification and sender authentication.

You can send an ordinary email to this mailbox from another account you control. Its receipt verifies only that the mailbox accepts that message. It does not prove the WordPress server is authorized to deliver its messages there. Keep the two observations separate rather than concluding everything works because a personal message arrives.

The expected result is either finding the link or confirming that the correct mailbox and every folder were searched. If you temporarily change a rule, record its value and restore it after the test. Do not globally disable organizational spam protection or allow an unknown sender merely because its name resembles the site’s.

Approach 2: remove an identified sending block

This approach fits when a transport plugin is already present and an intentional block may have remained enabled after migration or maintenance. First determine whether the stop is deliberate. A test copy may specifically prevent messages reaching real customers. Do not reenable all its email to test recovery for one account.

With WP Mail SMTP already active, open WP Mail SMTP → Settings → Misc. Find Do Not Send, whose label may be translated according to the administration language. In examined version 4.10.3, this option blocks ordinary messages handled by WP Mail SMTP. A decisive point: the plugin’s test emails are allowed despite this setting. Receiving a test therefore does not rule out this block on ordinary notifications.

On the public site whose messages should be sent, record the initial state. If the option is enabled by mistake and you are authorized to resume site sending, disable it and click Save Settings. Then make a native request for the test account and check receipt. This change affects other messages using the same mechanism; coordinate timing if the site generates orders or registrations.

A disabled switch accompanied by a constant indication means the value is enforced elsewhere. Do not try to bypass it with a second plugin. Whoever manages configuration must locate the WPMS_DO_NOT_SEND definition and confirm its scope, especially in multisite.

The expected result is receipt of an actual recovery message, not just the SMTP test. If the block was necessary for this environment, restore its original value and continue in a correctly isolated test environment. No change is needed when the option was already disabled.

Locate the failure in the sending chain

Before replacing configuration, separate three stages. WordPress prepares the account’s message; a transport handles it; the recipient system delivers it to the mailbox or classifies it. The wp_mail function may return success without the recipient receiving the message. A green plugin screen likewise describes one stage, not a delivery guarantee.

First consult tools already available from your host or sending provider. For the timestamped attempt, look for the recipient, status and technical message ID if one exists. A connection or authentication error points to transport. An explicit recipient rejection points to its precise reason. A queued message calls for understanding the queue before multiplying new requests.

Absence of a log entry does not always prove absence of a message: the log may cover another transport, site or time period. Verify the tool’s scope. Conversely, an entry recorded before sending does not prove the remote server accepted the email. Your conclusion must include the exact label and observed stage.

Link creation and notification that a password has already changed are also separate. A setting suppressing one does not necessarily disable the other. Avoid enabling every security notification in hopes of repairing the missing link. Find the setting actually concerning recovery requests, then act only on that setting if its responsibility is established.

Approach 3: use authenticated transport when transport is missing

This route fits if earlier checks establish a sending problem and you have administrator access plus an authorized sending service for this site. If SMTP or API transport already exists, correct it with its current tool. Running two plugins handling the same email makes diagnosis less reliable and may change the sender unpredictably.

WP Mail SMTP by WPForms provides a connection interface and test tool. The WordPress directory credits the plugin to Syed Balkhi. At the documentary check on November 3, 2026, the listed version is 4.10.3, requiring at least WordPress 5.5 and PHP 7.4, with declared compatibility through WordPress 7.1.4. These statements allow comparison with your environment; they are not a test of your installation.

The Other SMTP connection described below is available in the free edition, but the email service has its own conditions and limits. It requires storing sending credentials in WordPress, accessible to authorized administrators, and is not the first choice if your provider offers a better-suited integration. Use it only with a server that still authorizes this method. A mailbox using modern authentication must not be reduced to an old SMTP password by guesswork.

Before any installation, record versions under Tools → Site Health → Info and back up existing settings privately. If no competing transport exists, Plugins → Add New Plugin lets you search for WP Mail SMTP, verify its listing, install and activate it. Its presence alone does not authorize sending: the service and sender still need configuration.

Configure Other SMTP using the actual provider’s settings

Prepare parameters supplied for your service: server name, port, encryption, authentication mode and sending username. Do not copy another host’s settings from an example. The server name is not necessarily your site’s name, and an address that receives email is not automatically authorized as a sender.

Under WP Mail SMTP → Settings → General, choose the From Email address authorized by the provider and a recognizable From Name. Examine the scope of Force From Email before enabling it: this choice enforces the configured address for messages handled by the plugin. It may help maintain one sender but also affects other site notifications. Record initial values so you can restore them.

Under Mailer, select Other SMTP, then enter the service’s exact values. Use site-specific credentials when your provider allows it. Do not give the secret to someone merely reviewing the guide; enter it directly in the designated field. If the provider requires an API connection or specific account authorization, stop this SMTP route and use its documented integration.

The desired result is an authorized connection with an accepted sender. A certificate error is not fixed by removing encryption. A hosting-level connection block is not repaired by arbitrarily changing the port. If the provider requires domain authentication records, follow its exact values in SPF, DKIM and DMARC diagnosis. Do not change nameservers or MX records to test a simple SMTP send.

If you added WP Mail SMTP only for this test and must abandon the configuration, retain private notes and deactivate only this new plugin under Plugins → Installed Plugins. This restores the previous route with any delivery difficulties it had. Do not delete settings of a transport already used by the team. Also have any now-unneeded sending authorization removed at the provider through its process.

1. Enter the supplied server in SMTP Host without adding a web page address.
2. Match Encryption and SMTP Port according to that same provider’s instructions.
3. Set Authentication and complete SMTP Username and SMTP Password according to the authorized method.
4. Click Save Settings; to roll back, restore recorded values in the same transport, then check sending after restoration.

Test transport, then the actual recovery message

Open WP Mail SMTP → Tools → Email Test. Under Send To, enter the mailbox controlled for the test. Disable HTML to send a plain-text message, a relevant format for comparing transport with the native notification. Click Send Email once and record the time and displayed result. This action sends a real message, so choose a recipient on your team. If your edition offers multiple connections, choose the one actually handling this notification; testing another connection does not verify its route.

Then check the mailbox instead of relying only on the success screen. If the test fails, use its error to correct one specific detail: rejected credentials, unavailable connection or rejected sender. Do not replace server, port and address simultaneously, because you would lose the ability to identify what repaired the route. A secret changed at the provider must also be updated in the affected transport.

If the test arrives, return to the site’s login page and trigger a new recovery for the test account. This second stage verifies the message actually wanted, with its recipient and specific rules. It is essential even after a successful test, especially because of Do Not Send and components capable of changing recovery.

The complete result has two distinct observations: the test is received, then the recovery link is received in the correct mailbox. If only the first arrives, do not replace transport that just worked. Now examine native-message generation. After testing, retain validated production parameters and remove only any temporary diagnostic data under your team’s rules.

When only the recovery link remains missing

Working transport does not guarantee WordPress hands it this particular message. In the native mechanism, filters may prevent recovery sending or make its content empty while allowing the procedure to finish without a transport error. Other customizations can change the recipient. This is why request confirmation is not proof that a message reached the mail system.

Examine recent changes in the component managing accounts: custom login, membership area, security or centralized login. Open its lost-password settings and check whether it replaces the native procedure or sends users to another service. Compare its behavior with the login page intended for your installation. Do not bypass a security restriction merely to obtain a different form.

If the team already has a code snippet manager, search its snippets for send_retrieve_password_email, retrieve_password_message and retrieve_password_notification_email. Perform the same search in custom code through your maintenance environment’s editor, initially read-only. A name’s presence does not prove a fault: record the condition and site or account type it applies to.

A correction must target the identified rule, with a copy of its initial state and validation using a test account. Avoid globally deactivating plugins on the public site: this may affect login, commerce or site protections. If you cannot change this rule in a controlled way, send its location and observations to the component maintainer. Useful diagnosis is then already narrowed to email generation.

If the tool reports deferred sending, also examine existing asynchronous-send or rate-limit options. They may queue the email. Check normal queue operation with its administrator; do not run all tasks or all pending messages. A new transport plugin does not necessarily fix a task that never executes.

Complete recovery without retaining sensitive links

When several emails finally arrive, use the latest request you just triggered on the correct site. If the link is rejected or already invalid, make one new request after confirming delivery works. Do not forward the link to a shared mailbox for verification: it grants access to a sensitive operation on the affected account.

The administrator can confirm receipt with the account owner without learning the new password. Once chosen, verify login in another window before closing the backup session. If the person restored access through another route, nevertheless keep the email issue open until the native link arrives: the next incident could cause the same loss of access.

Do not enable full message-body recording solely to observe this failure. Recovery emails contain a personal link, and logs may be accessible to other administrators or exported in backups. Prefer minimal details: time, recipient redacted when necessary, transport status and technical ID. Check features actually included in your edition instead of assuming the free plugin supplies a complete email archive.

The expected result is restored access and a usable recovery channel. Rollback concerns settings changed during investigation; it does not mean restoring an old password or retaining the link used for the repair.

Validate a precise repair and prepare a useful handoff

Finish with the same scenario that failed. Request a link for the test account, confirm receipt and verify it targets the expected domain. Also check another representative notification if you enforced a new sender across the site. A test on a copy using a different service is insufficient to validate the public site’s transport.

If the message remains absent, send a brief, usable record: environment, affected account without secrets, time and time zone, checked mailbox, transport-test result and native-request result. Include the exact status from the sending service after removing credentials and the link. Ask at which stage the message is missing instead of requesting a general site reinstallation.

• Test not received with a connection error: review transport parameters or network access.
• Test received, recovery absent: review the recipient, notification block and recovery rule.
• Message accepted then rejected or queued: follow the reason reported by the provider.
• Message found in spam: handle classification and sender identity in a separate diagnosis.
• Link received for the correct site and recovery successful: retain validated configuration and close temporary diagnostics.

Read the rule suppressing email without bypassing it

For developers, the three filters mentioned above act at different points. send_retrieve_password_email decides whether sending should continue; retrieve_password_message modifies the body; retrieve_password_notification_email allows notification parameters to be adjusted, among other things. A condition targeting only one role or address explains why a test email arrives while recovery for a specific account remains absent.

On the isolated copy, search custom code for occurrences and record each callback, priority and condition. Compare an affected test account with another authorized test account using the same private capture mailbox. Do not record full bodies in a shared log: they contain recovery links.

The useful correction is repairing the faulty condition in the component that owns it. Do not add a universal filter always returning true: it could cancel an intentional centralized-login rule. Keep the initial file or setting to restore only this change.

Then validate a native request and its receipt, followed by behavior of the case that should remain excluded. Free WP Mail SMTP can verify the transport described in this guide but cannot recreate a message deliberately suppressed by application policy before sending.