Password-reset email is a security transaction, not just another contact-form message. Diagnose whether WordPress generated the reset, whether the mail layer accepted it, and whether the recipient provider delivered or filtered it. Avoid repeatedly triggering resets while you are still unsure which token is current.
Confirm WordPress created the reset flow
Use one test user and note the exact request time. Verify the account exists and the reset action completes without PHP errors.
Inspect the generated message
Confirm recipient, From domain and reset URL host. Never paste the full token into logs or tickets.
Trace the handoff to mail transport
Check wp_mail/SMTP/provider logs using message ID or timestamp. “Accepted by SMTP” is not the same as delivered.
Check authentication and recipient filtering
Inspect SPF/DKIM/DMARC alignment and provider delivery/bounce data. Password-reset mail often has stricter filtering because it contains a security link.
Test one mailbox outside your domain
A local mailbox can hide DNS or reputation problems. Compare a representative external provider.
Verify recovery, not only delivery
Use the received link once, confirm it reaches the canonical site and that the password change invalidates the old reset token.
Trace the complete route with the browser-to-mailbox guide and interpret transport evidence with the SMTP-log guide.
Record the reset-token lifecycle, not the token itself
For one test account, record request timestamp, user ID, generated-message timestamp, provider message ID and whether the link was used or superseded. Never store the reset key in the incident log. If the user requests another reset, note that the earlier link may become obsolete so support does not diagnose an expected invalid-token response as a delivery failure.