Gravity SMTP 2.3.3 can define an Amazon SES Tenant and route messages using Members plugin criteria. This gives multi-tenant and membership sites more control, but overlapping rules can select the wrong tenant, sender identity, region, configuration set, or fallback connector. A message marked sent in WordPress is not proof that the intended recipient received it through the intended account.
Use this for membership communities, franchise networks, agencies, multisite platforms, SaaS portals, regional brands, and organizations that separate email reputation, billing, compliance, or sender identities through Amazon SES tenants.
Quick answer
Create a route matrix with one synthetic user for every relevant Members role, one unauthenticated path, and one message type outside all rules. For each message, write the expected Gravity SMTP route, SES tenant, AWS region, verified identity, configuration set, fallback rule, and recipient. Send unique markers, then reconcile the routing preview, WordPress email log, SES message ID, event destination, delivery or bounce, and inbox headers. A fallback should activate only for the failure classes you intentionally allow, never for a permission or configuration mistake.
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 |
|---|
| Member role A | Form notification | Tenant A and identity A |
| Member role B | Order message | Tenant B and identity B |
| No match | System notice | Documented default |
| Tenant denied | Synthetic message | Visible failure or approved fallback |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Write the route truth table | Record Gravity SMTP version, Members version, rule order, role and capability criteria, SES region, tenant name, identity ARN, configuration set, fallback connector, and suppression policy. | Every marker appears once in the Gravity SMTP log and once in the expected SES event stream. |
| Create role fixtures | Build users with one role, several roles, no matching role, recently changed membership, expired membership, and the least privilege needed to trigger each message type. | The SES region, tenant, identity, configuration set, and recipient headers match the written route. |
| Send unique markers | Test password reset, form notification, order email, administrative notice, scheduled email, bulk send, and a message whose From address is not verified for the selected SES tenant. | Multi-role and no-role users follow an explicit deterministic rule. |
| Reconcile SES events | Compare routing preview, selected connector, SES request, message ID, event destination, delivery, complaint, bounce, suppression result, and final recipient headers. | Denied, bounced, suppressed, and fallback paths create clear alerts without duplicate or cross-tenant delivery. |
What to check first
- Record Gravity SMTP version, Members version, rule order, role and capability criteria, SES region, tenant name, identity ARN, configuration set, fallback connector, and suppression policy.
- Build users with one role, several roles, no matching role, recently changed membership, expired membership, and the least privilege needed to trigger each message type.
- Test password reset, form notification, order email, administrative notice, scheduled email, bulk send, and a message whose From address is not verified for the selected SES tenant.
- Compare routing preview, selected connector, SES request, message ID, event destination, delivery, complaint, bounce, suppression result, and final recipient headers.
- Remove or disable one tenant, revoke an SES permission, exceed a safe test threshold, and confirm fallback behavior is bounded, visible, and cannot cross customer boundaries.
Field notes
- Write the pass condition before changing anything. A repeatable synthetic fixture makes the before and after comparison far more useful.
- Keep exact versions and UTC timestamps because scheduled jobs, caches, OAuth refreshes, 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.
route_fixture:
marker: SMTP233-SES-001
member_role: partner_eu
expected_tenant: tenant-eu
expected_region: eu-west-1
expected_identity: mail.example.test
fallback_allowed: false
Why this usually happens
- Several Members roles match one user and the first or last rule wins unexpectedly.
- An SES identity is verified in one region but the connector sends through another.
- The fallback route is broad enough to move a tenant-specific message into a shared account.
- WordPress logs a handoff as sent before SES reports a bounce or suppression.
Decision rule
Approve the routing setup only when each role and message type selects exactly one expected tenant and identity, SES events reconcile, recipient privacy holds, and failure cannot silently cross tenant boundaries.
Production verification checklist
- Every marker appears once in the Gravity SMTP log and once in the expected SES event stream.
- The SES region, tenant, identity, configuration set, and recipient headers match the written route.
- Multi-role and no-role users follow an explicit deterministic rule.
- Denied, bounced, suppressed, and fallback paths create clear alerts without duplicate or cross-tenant delivery.
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.
- Write the route truth table
- Create role fixtures
- Send unique markers
- Reconcile SES events
- Constrain fallback rules
Mistakes to avoid
- Changing production before recording plugin versions, WordPress version, PHP version, UTC time, the exact fixture, and a tested rollback point.
- Accepting one successful admin screen while the public form, stored record, API response, accessibility tree, cache, email, or downstream system remains unchecked.
- Testing only as an administrator instead of the role, browser, device, locale, network state, and failure path that a real customer reaches.
- Leaving test accounts, broad credentials, debug logs, temporary compatibility filters, or synthetic customer data 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 a current data shape, theme, extensions, caching stack, and browser mix. If a production canary is necessary, make it reversible, identifiable, monitored, and unable to charge a customer or expose personal data.
How do I know the result is not a cache artifact?
Record the origin response, purge only the affected paths, and repeat the test in a private session and a normal session. Compare stored data and server logs with the visible page. A cache hit is useful evidence only when you know which version 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 can I close the test?
Close it when the primary 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 test Gravity SMTP routing.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references