Gravity SMTP 2.3.3 improves Zoho connection reliability so failed or abandoned OAuth attempts do not appear active. An existing connector still needs a controlled expiry test because regional endpoints, rotated refresh tokens, clock drift, concurrent sends, and lost responses can turn one token failure into a mail outage or duplicate delivery.
Use this for WordPress sites sending through Zoho Mail, especially multisite, regional Zoho datacenters, high-volume forms, backup connectors, or recent OAuth reconnections.
Quick answer
On staging, record the Zoho datacenter, connector ID, masked token timestamps, sender, recipients, and one message marker. Expire or revoke only the test connection, then send one marked email. Trace the refresh request, selected regional endpoint, new connector state, provider message ID, SMTP log, and inboxes. Repeat with two concurrent sends and an abandoned reconnect. Only the intended connector may become active, and one business message may produce one provider-accepted delivery.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Expired access | Valid refresh token | Refresh then one send |
| Revoked refresh | Current connector | Clear reauth state |
| Wrong region | EU account on US endpoint | No false active state |
| Concurrent mail | Two workers, one marker | No duplicate delivery |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Record connector and region | Record Gravity SMTP version, Zoho datacenter, connector ID, sender domain, token issue and expiry time, refresh-token state, site clock, recipients, and backup route. | The selected Zoho datacenter handles authorization, refresh, and send requests consistently. |
| Create one marked expiry fixture | Test an expired access token, revoked refresh token, wrong regional endpoint, abandoned callback, denied consent, clock drift, and two simultaneous sends. | Expired access refreshes without promoting a failed or abandoned connector. |
| Trace refresh and callback state | Compare OAuth callback state, connector status, primary selection, token refresh response, mail log, provider ID, recipient list, and inbox result. | Concurrent workers do not overwrite a valid refresh token or duplicate the message. |
| Test concurrent sends | Verify a failed reconnect cannot replace the working connector or become primary through stale settings, browser history, or a delayed callback. | Gravity SMTP, Zoho, and inbox evidence agree on sender, recipients, marker, and one provider ID. |
What to check first
- Record Gravity SMTP version, Zoho datacenter, connector ID, sender domain, token issue and expiry time, refresh-token state, site clock, recipients, and backup route.
- Test an expired access token, revoked refresh token, wrong regional endpoint, abandoned callback, denied consent, clock drift, and two simultaneous sends.
- Compare OAuth callback state, connector status, primary selection, token refresh response, mail log, provider ID, recipient list, and inbox result.
- Verify a failed reconnect cannot replace the working connector or become primary through stale settings, browser history, or a delayed callback.
- Redact access tokens, refresh tokens, authorization codes, client secrets, personal addresses, and private callback parameters from every evidence artifact.
Field notes
- Write the pass condition before changing anything. A repeatable synthetic fixture makes the before and after comparison useful.
- Keep exact versions and UTC timestamps because scheduled jobs, caches, retries, and background processing can change the evidence.
- Check the public experience and the stored server-side result. Admin previews and isolated API calls do not prove the whole workflow.
- Repeat the test after the relevant cache, queue, scheduled action, webhook, and observation window has finished.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
zoho_refresh_test:
datacenter: eu
connector_id: zoho-primary
access_state: expired
callback_state: unique-test-value
message_marker: ZOHO-REFRESH-20260909-01
expected_provider_count: 1
Why this usually happens
- A Zoho account belongs to a regional datacenter different from the authorization or token endpoint.
- A provider rotates refresh tokens and one worker continues using the previous value.
- A delayed OAuth callback writes connection state after the administrator abandoned setup.
- Two mail workers refresh at the same time and retry the same business message.
Decision rule
Keep the connector active only when the regional refresh succeeds, abandoned callbacks stay inactive, the recipient set is unchanged, and each marked message is accepted once.
Production verification checklist
- The selected Zoho datacenter handles authorization, refresh, and send requests consistently.
- Expired access refreshes without promoting a failed or abandoned connector.
- Concurrent workers do not overwrite a valid refresh token or duplicate the message.
- Gravity SMTP, Zoho, and inbox evidence agree on sender, recipients, marker, and one provider ID.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Record connector and region
- Create one marked expiry fixture
- Trace refresh and callback state
- Test concurrent sends
- Confirm one provider message
Mistakes to avoid
- Changing production before recording exact versions, UTC time, the affected fixture, current behavior, and a tested rollback point.
- Accepting one successful admin screen while the stored record, API response, queue, email, browser, or downstream system remains unchecked.
- Testing only as an administrator instead of the role, browser, locale, network state, catalog size, and failure path a real user reaches.
- Leaving broad credentials, debug logs, temporary filters, synthetic records, or recovery code active after verification.
Questions teams ask during testing
Should I test this on production?
Use production for read-only evidence first. Reproduce the change on staging with current data, extensions, cache, browser mix, and integration settings. If a production canary is necessary, make it reversible, identifiable, monitored, and unable to charge a customer or expose personal data.
How do I rule out a cache artifact?
Record the origin response, purge only affected paths, and repeat in private and normal sessions. Compare stored data and server logs with the visible page. A cache hit is useful evidence only when you know which version and settings it contains.
What belongs in the evidence packet?
Keep UTC time, exact versions, fixture ID, role, browser, expected result, actual result, relevant response or log lines, change made, rollback point, owner, and final verification. Redact passwords, tokens, personal data, and private URLs.
When is the test complete?
Close it when the main path and important failure branches pass, records reconcile across systems, accessibility and mobile checks are complete, temporary changes are removed, and monitoring covers the next update or business cycle.
What to tell the client or owner
Give the owner a short packet with the affected workflow, exact versions, UTC test time, fixture ID, expected result, actual result, key evidence, change made, rollback point, unresolved risk, owner, and next review date. Remove credentials and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP trace a Zoho mail failure.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references