Probably, if the host’s notice says files or databases were reached, or doesn’t say what was. Changing your hosting password does nothing for the credentials your WordPress site sends mail with: the SMTP password or API key in your mailer plugin, or the Google or Microsoft connection behind it. Those live in the site’s files and database, and only your email provider can cancel them.
The full answer depends on two things you can find out: which of the host’s systems the notice says were reached, and where on your account each mail credential sits.
One check first. Open the host’s control panel by typing its address, not through a link in the email, and confirm the notice on the host’s status page or blog. Breach news is good cover for phishing.
Where WordPress keeps mail credentials
- The database. Mailer plugins save their settings in the
wp_optionstable by default, including OAuth refresh tokens: the long-lived token that lets the plugin keep sending as your Google or Microsoft account without you signing in again. wp-config.php. The main mailer plugins can read secrets from constants instead: WP Mail SMTP fromWPMS_SMTP_PASSand its siblings, FluentSMTP fromFLUENTMAIL_*constants, Post SMTP fromPOST_SMTP_AUTH_PASSWORDandPOST_SMTP_API_KEY.- Environment variables. Some setups have
wp-config.phpfetch those values withgetenv()from the platform’s variable store. - The host’s own mail service. If the plugin sends through a mailbox the host runs (
mail.yourdomain.comon the same account), that mailbox password is also a login the host holds.
To tell which applies to your site, open the mailer plugin’s settings. A password or API key field that is greyed out, or says it is set by a constant, is read from wp-config.php; searching that file for WPMS_, FLUENTMAIL_ or POST_SMTP_ confirms it. A field you typed into and saved is in the database. Post SMTP is the exception: its settings show no sign of a constant, so search wp-config.php for POST_SMTP_; a value saved before the constant was added stays in the database too.
What each plugin saves in plain text differs. WP Mail SMTP (4.10.3) encrypts only the SMTP password, with a key kept in the same database unless WPMS_CRYPTO_KEY is defined; its API keys, client secrets and OAuth tokens are saved as plain text. Post SMTP (4.0.2) base64-encodes passwords and API keys, which anyone can reverse, and saves the OAuth client secret and tokens as plain text. So for both, a copy of the database alone gives up the credentials (except WP Mail SMTP’s SMTP password when WPMS_CRYPTO_KEY is set). FluentSMTP (2.4.1) by default encrypts them with keys taken from wp-config.php, so reading them takes the database and the files. The exception is SMTP2GO: FluentSMTP saves that API key as plain text. The Secrets API question has the mechanism plugin by plugin.
What the host says was reached, and what that exposes
| The notice mentions | What it can expose |
|---|---|
| Hosting panel or account login | Inference: whatever the panel opens. Most include a file manager and a database tool, so a panel session someone else used counts as the two rows below. If only panel password hashes leaked, changing that password is the fix. |
| File manager, SFTP or SSH | wp-config.php: every constant in it, and FluentSMTP’s encryption keys. Inference: if the access could change files, anything the site can read, environment variables included, because code planted on the server runs with the site’s access. |
| Databases or phpMyAdmin | wp_options: every credential the plugins saved, readable for WP Mail SMTP and Post SMTP. |
| Files and databases, or full-site backups | Everything, FluentSMTP included. |
| Webmail or the host’s mail service | Mailboxes the host runs, and the password your plugin uses if it sends through one. Inference: only the host knows whether it stores those passwords recoverably; treat them as exposed. Inference: if your email provider account is registered to a mailbox at the host, whoever reads that mailbox gets the provider’s password-reset emails, and with them the whole account. |
| Environment variables or a secrets store | Every secret wp-config.php reads from there. |
A notice that says “some systems” without naming them is the files-and-databases row.
The trap in moving keys to wp-config.php
Moving a key from the database into a wp-config.php constant is good advice. It protects against a leaked database dump or an SQL injection that reads wp_options. It does not protect against a breach of the host’s file storage, because that is where wp-config.php lives. On a host-side breach, the hardened setup and the default one can end up equally exposed.
An environment variable kept in the platform’s variable store is a different case. wp-config.php then holds only the getenv() call, so a copy of the files doesn’t contain the secret. A breach of the variable store itself does, and so (inference) does one that let the attacker change your files, because code running on the server can read the variable.
What to do now
- Replace each exposed credential at the provider, not just on the site: a new API key in the SendGrid or Mailgun dashboard, a new SMTP password at the mailbox. The rotation guide for a compromised plugin has the per-provider steps. Its order applies here too if the notice says files were reached: anyone who could get at your files may also have changed them, so check the site before the new credential goes in.
- Revoke OAuth grants, don’t just reconnect. A copied refresh token keeps working from someone else’s server until the grant is revoked at Google or Microsoft (for Google this is inference from its
documented refresh parameters, which identify the app and the token, not the server). The rotation guide has the revoke steps for both. - Check the provider account itself. In the sending log, look for mail you didn’t send and API keys or sending domains you didn’t add, from the date the host gives for the incident. In the account settings, look for a changed login email or two-factor setting. The hacked-site spam guide covers what abuse looks like.
Limiting the next one
The site has to be able to read its own credential, so nothing stops a host-side breach copying it. The settings below make a copied key worth less, where the provider offers them: send-only permissions, one key per site, and an allow-list of the addresses that may use it.
- Send-only keys. Mailgun’s
Domain Sending Keys can only post messages for one domain. SendGrid’s 
Custom Access keys can be given Mail Send alone. Amazon SES 
SMTP credentials created in the SES console carry a policy allowing only ses:SendRawEmail. - Narrower scope where there’s no send-only key. A Postmark Server API token covers one server but is not send-only: Postmark
documents it for reading sent messages and the Bounce API too. Over SMTP, a per-stream SMTP Token is the narrower login. One Postmark server per site contains a leak. - One key per site, so revoking one leaves the others sending.
- IP allow-lists, where the provider has them:
- Mailgun’s IP Allowlist covers API keys and SMTP credentials.
- SendGrid’s IP Access Management covers the dashboard, the API and SMTP.
- Brevo‘s
Authorized IPs blocks API calls from unlisted addresses. - Postmark’s allowlist gates API sends, not SMTP.
- SES accepts an
aws:SourceIpcondition in the sending policy.
- Mailgun’s
An allow-list stops a copied key being used from elsewhere. It does not help if the breach gave write access to your files, because then the attacker can send from your server.