Changing a mailbox password invalidates every website, mail client or integration that still uses the old credential. WordPress may continue accepting form entries while SMTP rejects notifications with an authentication error.
Update the credential through a secure path, but first confirm which account and authentication method the site actually uses.
Preserve the exact authentication response
Run one labelled mail test and record the time, SMTP hostname, username domain and redacted response code. Typical wording refers to authentication failure, invalid credentials or an unsuccessful login.
Do not paste the password, full debug transcript or base64 authentication exchange into a ticket. A debug log can expose credentials even when they do not look like plain text.
Stop repeated attempts if the provider may lock the account.
Confirm the SMTP identity
The visible From address, SMTP username and mailbox whose password changed are not necessarily identical. Hosting relays may use a full email address, a control-panel account or a dedicated application credential.
Check the active WordPress mail plugin and provider documentation. Verify that the username has no copied spaces and uses the required full address or account identifier.
Do not reset another employee’s mailbox merely because its address appears in From.
Determine whether an app password is required
Accounts protected by multi-factor authentication often require an app password or OAuth connection rather than the normal interactive password. Some providers disable basic username/password SMTP entirely.
Follow the provider’s current supported method and grant only the required mail-sending access. Store app passwords as secrets and label them so they can be revoked without affecting unrelated applications.
Never disable multi-factor authentication to make WordPress SMTP work.
Update the actual source of the secret
The credential may be stored in the WordPress database, wp-config.php, an environment variable, a hosting secret or a central management tool. Changing the visible plugin field has no effect if a constant overrides it.
Inspect the plugin’s diagnostics for an overridden setting. Update the authorised source, then clear only relevant application/configuration caches.
Avoid placing a password directly in theme files, Git history or a reusable code snippet.
Check encrypted settings after migration
Some plugins encrypt stored credentials with WordPress salts or environment-specific keys. A migration or restored configuration can leave a value that appears populated but cannot be decrypted correctly.
Re-enter the credential through the plugin interface or supported secret mechanism. Do not copy encrypted database values between unrelated environments and assume they remain usable.
Keep staging credentials separate from production.
Verify connection settings too
A password change may coincide with a provider security update. Confirm SMTP hostname, port, encryption and authentication mode. Port 587 normally uses explicit TLS where offered, while port 465 commonly uses implicit TLS; use the provider’s documented combination.
Check server time and TLS verification. Do not solve an authentication error by disabling certificate checks or switching randomly between ports.
Ensure the host permits outbound connections to the chosen service.
Test the real form after login succeeds
A mail-plugin test proves the new credential can send one simple message. Submit the real form next because it may use a different From address, recipient, notification rule or WordPress installation.
Trace the test through provider acceptance and final mailbox delivery. Inspect SPF, DKIM and DMARC results and verify Reply-To.
Review stored entries from the failure window so missed enquiries receive a response.
Rotate and document safely
Once service is restored, revoke obsolete app passwords and remove credentials from temporary notes or logs. Record the secret owner, purpose and next rotation process without recording the secret itself.
Use a dedicated sending identity where appropriate so an employee password change does not silently break website leads.
Request urgent repair when the account is locked, OAuth ownership is unclear or several sites share the credential. Provide redacted error codes and timestamps—never the old or new password.