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
- 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.
- Read only the relevant error details: Compare the actual
client_idandredirect_uriin the failed request. Do not publicly share the entire authorisation URL; it can contain other values that do not belong in a support request. - 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.
- 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.
- 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.
Prepare a findings note
Summarise your observations for your enquiry. The note is created in your browser and is not saved or sent here. You can then copy it into the contact form.
Unknown is fine. Do not enter passwords, customer data or complete confidential logs.
Support with this issue
KAN KAI WORKS can compare the OAuth setup route with the values actually being used.
Sources and scope
- Q1: Original report and visible replies
- Q2: WP Mail SMTP: configuring the Gmail connection
- Q3: Google: OAuth for web-server applications
Sources checked: 5 November 2026. The original incident has not been independently reproduced.
