WP Mail SMTP · Help

WP Mail SMTP and Gmail: redirect_uri_mismatch?

Compare the client ID and callback actually sent with the same Google OAuth client’s registered configuration.

Source date: 5 November 2026Editorial team: KAN KAI WORKSEditorially updated:

Quick answer

redirect_uri_mismatch means the submitted callback does not match the registered configuration of the Google OAuth client being used. A correct address in another client will not help. Compare the actual client_id and redirect_uri in the failure with that exact client and the intended WP Mail SMTP setup route. Check scheme, host, path and trailing slash; the message does not implicate an SMTP port or Gmail password.

Source basis: Q2 · Q3

Applies to
WP Mail SMTP using Gmail OAuth; manual and automatic setup are distinct routes. The original report describes differing client IDs, without confirming a general plugin defect.
How to verify the result
The intended Google authorisation succeeds with matching values, then a test email and a controlled real WordPress mail workflow reach their intended inboxes.
Your first check

Does the client ID in the error match the Google client you are editing?

Record the actual client ID and redirect URI shown in the error. Compare that pair with the selected OAuth client, not merely a similarly named project.

Connecting Gmail fails with Google error 400 and redirect_uri_mismatch, although the callback shown in the plugin appears correct. The reviewed report additionally describes a different client ID in the error details. That is a useful lead, but not a confirmed plugin defect. Q1

Treat the client and callback as a pair

Google checks the callback in the context of the OAuth client requesting authorisation. A correct address registered against a different client will not fix that request. Manual configuration and a supported automatic setup are also distinct routes; do not mix their settings. Q2 Q3

This failure occurs during connection authorisation. It does not justify changing SPF, DKIM or an SMTP port. Start with the values identified by the actual error rather than unrelated mail-delivery settings.

Inspect the actual authorisation attempt

  1. Record the setup route: Note the WP Mail SMTP version, selected mailer and whether setup is manual or automatic. Preserve the callback currently displayed in the plugin.
  2. Read only the relevant error details: Compare the actual client_id and redirect_uri in the failed request. Do not publicly share the entire authorisation URL; it can contain other values that do not belong in a support request.
  3. Open the same client: In the correct Google project, choose the OAuth client with that exact ID. A similar display name is insufficient. Check authorised redirect URIs, which are separate from authorised JavaScript origins.
  4. Compare the address exactly: Check scheme, host, path and trailing slash. Use the documented callback for this configuration route rather than inventing an address from your own domain.
  5. Test the saved configuration: Save the targeted correction, start a fresh connection attempt and inspect the values actually sent. If a different client ID remains active, investigate unsaved settings, another installation or a different setup route.

Verify delivery after authorisation succeeds

Send a clearly labelled test email to your own address. Then check one intended WordPress mail workflow, such as a controlled form submission. Successful Google authorisation does not establish that every application is using the expected delivery route.

Keep a record of the original configuration and the corrected values without secrets. A client secret does not need to be published or included in screenshots for this comparison. If another application shares the client, understand that relationship before changing settings used by it.

Frequently asked questions

Would changing my Gmail password help?

It will not correct a callback mismatch. Follow the specific OAuth error first.

Should I delete the entire Google project?

No. That could disrupt other connections. Identify the client actually used and change only the setting shown to be wrong.

Is the consent-screen status automatically the cause?

No. Other OAuth requirements can matter, but this error initially identifies the redirect mapping. Keep different failure messages separate during diagnosis.

Information for assistance

Provide the plugin version, setup route, callback and a shortened client ID for comparison. Do not include client secrets, authorisation codes or tokens in the initial message.

KAN KAI WORKS can compare the OAuth setup route with the values actually being used. Get help with this case.

Support with this issue

KAN KAI WORKS can compare the OAuth setup route with the values actually being used.

Sources and scope

Sources checked: 5 November 2026. The original incident has not been independently reproduced.