Free WordPress email tools: SPF, DKIM, DMARC, and more.

Try the tools

nanoPost

The WordPress Email Authority

Will the WP Secrets API replace SMTP constants?

Last reviewed/updated:

Short answer: not on its own. The Secrets API that landed in trunk in October 2026 is a new encrypted place for plugins to keep sensitive values; it does not touch what WP Mail SMTP, FluentSMTP, or Post SMTP already have on disk. If the SMTP plugin a site uses adopts the API, credentials move out of the wp_options table and into the encrypted store; until it does, nothing moves, and the wp-config.php constants a site is using today keep working. For an operator reading this before WordPress 7.2 ships, there is nothing to do.

What the Secrets API is

The Secrets API is Trac ticket #66187, committed to trunk as r64337, and scheduled to ship in WordPress 7.2 on 2026-12-09 (release schedule).

The design proposal defines the following functions, which the trunk patch implements:

wp_set_secret( string $name, string $value ): bool|WP_Error
wp_get_secret( string $name, string $version = WP_Secret_Version::CURRENT ): WP_Secret|null|WP_Error
wp_delete_secret( string $name ): bool|WP_Error
wp_import_option_as_secret( string $option, string $name ): bool|WP_Error

The proposal flags these wp_-prefixed function names as proposed rather than shipped, so names and signatures may still change before 7.2 goes GA.

wp_get_secret() returns a WP_Secret object. The actual string is reached through WP_Secret::reveal(); WP_Secret::fingerprint() returns a non-reversible identifier for diagnostics and logging. The version argument accepts WP_Secret_Version::CURRENT or WP_Secret_Version::PREVIOUS, which is how the API supports rotation: a new value becomes the current one and the prior value is kept in the previous slot so plugins can migrate off the old credential without losing it.

The backing store is the options API, not a dedicated table. The proposal specifies, and the trunk patch is expected to ship, ciphertext blobs with autoload=no, excluded from the options.php admin screen and from the REST settings endpoint, so a secret cannot be read out by browsing options. Encryption is an envelope scheme on libsodium (sodium_compat as a fallback): each secret gets a per-secret data key, the data key is wrapped by a master key, and the master key is wrapped by a site key. The site key comes from a dedicated wp-config.php constant, with a zero-config fallback derived from the existing WordPress salts for sites that cannot set one. The proposal does not name the constant; the committed name will land with the dev-note.

A drop-in (secrets.php) can replace the storage and keyring as separate extension points, so a managed host that wants secrets in HashiCorp Vault or AWS Secrets Manager can wire that in without plugin cooperation.

Two things the API does not do. It does not define a wp-config.php constant fallback for secret values; the constant is for the key material, not the credentials themselves. And there is no automatic sweep of existing options. wp_import_option_as_secret() moves one named option at a time, which the API treats as a candidate for rotation once the plugin migrates its code path; there is no code in core that walks the options table and migrates things it thinks look sensitive.

Where SMTP credentials sit today

Across the SMTP plugins nanoPost reviews, credentials are stored in one of three places, in rough order of hardening:

  • In wp_options as a saved option. The default for every plugin. The password sits in plaintext in the database row.
  • In wp-config.php as a define() constant that the plugin reads at every send and that overrides the saved option. WP Mail SMTP uses WPMS_ON plus WPMS_SMTP_PASS and related constants; its admin field goes read-only when the override is set (plugin docs). FluentSMTP reads the same WPMS_* constant list through its Converter service, plus a smaller FLUENTMAIL_* set for a handful of mailer-specific values (Gmail OAuth, SendInBlue, PepiPost, Elasticmail). Post SMTP reads POST_SMTP_* constants (POST_SMTP_AUTH_PASSWORD, POST_SMTP_API_KEY, and the fallback-mailer equivalents).
  • In an environment-driven constant that wp-config.php reads from $_SERVER or a host-provided include, which is what managed hosts and Composer-based WordPress stacks do.

This is the pattern nanoPost’s existing hardening guides lean on, including wp-config SMTP migration for Microsoft 365 and WordPress SMTP without a plugin.

The Secrets API is a fourth place, and the first one blessed by core. Nothing in r64337 touches options the plugins have already written; the migration has to be done by the plugin, one option name at a time, through wp_import_option_as_secret().

What has to be true for SMTP credentials to actually move

For a site’s SMTP password to live in the Secrets API rather than in wp_options or wp-config.php, three things have to happen in sequence:

  1. The plugin ships adoption. Someone on WP Mail SMTP, FluentSMTP, or Post SMTP has to add wp_set_secret() on save, wp_get_secret() on send, and a migration path for existing installations. As of 2026-10-17, none of the three plugin maintainers has announced a timeline; the current plugin trees carry no references to the new API. SMTP credentials are called out as an example in the proposal, but the proposal explicitly leaves plugin-side adoption to the plugins.
  2. The site is on WordPress 7.2 or later. wp_get_secret() does not exist on 7.1. Any plugin that adopts the API has to keep a code path for the saved-option and constant patterns, which means plugin releases will carry both.
  3. The site has a site key set. Without the dedicated wp-config.php constant, the API falls back to deriving a key from the existing salts. The fallback works, but a dedicated key is what the proposal recommends; a site that cares enough to adopt the API should add the constant at the same time, once the committed name is published.

For an operator today, the right stance is to leave things alone. The hardening path that works keeps working on 7.2: SMTP password in a wp-config.php constant, admin field locked, saved option empty. The Secrets API is additive; it does not break anything that already stores a credential in a define(). When the SMTP plugin a site uses announces adoption, the migration will be a plugin upgrade and, at most, running the plugin’s one-click import. There is nothing to prepare for ahead of 7.2.

For an operator whose SMTP password still sits in wp_options as a saved option, the Secrets API will eventually be an upgrade, but only when the plugin adopts it. A site that wants a hardening win before then has the wp-config.php constant pattern available today; the SMTP without a plugin guide walks it through for the plugin-free case, and the WP Mail SMTP constants documentation covers the plugin-based case.

When this changes

Two signals are worth watching:

  • A release note from WP Mail SMTP, FluentSMTP, or Post SMTP that mentions wp_set_secret() or Secrets API support. Any of the three adopting it would shift the recommended hardening pattern for sites running that plugin.
  • The WordPress 7.2 dev-note for the Secrets API. The committed constant name, the shipped function signatures, and any changes between the proposal and the committed code land there. Until the dev-note publishes, the function set described above is the proposal’s; the trunk patch may differ in details that only the dev-note or the Trac changeset will settle.

Until one of those lands, nothing in the recommended configuration for an SMTP plugin changes.