Gravity Forms logs may record a Message-ID generated by WordPress or the mailer, while an SMTP relay or email API returns a different provider message ID. Retries, routing, queue handoff, provider rewriting, bounces, and webhook normalization can create one-to-many or many-to-one relationships. Searching only one field makes a delivered message look missing or joins a bounce to the wrong notification.
Use this for Gravity Forms support teams, SMTP plugin owners, email providers, CRM administrators, privacy reviewers, and sites troubleshooting notification delivery.
Quick answer
Create one synthetic notification and preserve form, entry, notification, attempt, WordPress Message-ID, SMTP response ID, provider message ID, recipient class, sender, timestamps, queue job, response, webhook event, delivery state, and bounce or suppression reason. Normalize brackets and case without changing raw values. Model retries as separate attempts linked to one notification. Confirm provider ownership and retention before exporting evidence, and never log message bodies or personal addresses unnecessarily.
What to check first
- Inventory identifier creation and rewriting across Gravity Forms, mailer, SMTP plugin, queue, provider API, and webhooks.
- Create sent, deferred, retried, bounced, suppressed, duplicated, missing-ID, and provider-unavailable fixtures.
- Capture raw and normalized IDs, attempt number, queue job, SMTP response, provider event, timestamp, recipient class, and final state.
- Test webhook reordering, delayed bounce, multiple recipients, provider failover, and retention expiry.
- Build a restricted support view that joins evidence without exposing message bodies or unnecessary personal data.
Why this usually happens
- Mail libraries, SMTP relays, and providers can each assign their own identifier.
- Retries are new delivery attempts even when the business notification is the same.
- Webhook payloads often omit the exact raw header string stored by WordPress.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
notification,attempt,wp_message_id,smtp_id,provider_id,queue,provider_state,webhook_at,final
GF-710,1,<abc@example>,250-ok,p-991,q-81,deferred,14:03,retry
GF-710,2,<def@example>,250-ok,p-997,q-88,delivered,14:11,delivered
GF-711,1,<ghi@example>,250-ok,p-1002,q-92,bounced,18:44,bounced
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Define raw and normalized identifier fields with one owner per system. | Inventory identifier creation and rewriting across Gravity Forms, mailer, SMTP plugin, queue, provider API, and webhooks. | Raw Message-ID and provider IDs remain available for the approved retention window. |
| Model each send or retry as an attempt under the Gravity Forms notification. | Create sent, deferred, retried, bounced, suppressed, duplicated, missing-ID, and provider-unavailable fixtures. | Retries and provider failover do not collapse into one false event. |
| Join SMTP responses and provider webhooks through provider IDs and bounded time evidence. | Capture raw and normalized IDs, attempt number, queue job, SMTP response, provider event, timestamp, recipient class, and final state. | Delivery, bounce, and suppression webhooks join to the correct attempt. |
| Restrict, redact, and expire the support record according to policy. | Test webhook reordering, delayed bounce, multiple recipients, provider failover, and retention expiry. | Support users can reconcile the case without message bodies or excess personal data. |
Decision rule
Close the incident when every attempt has an explainable identifier chain and final state, unmatched events are explicit, privacy rules are met, and the expected business notification outcome is confirmed.
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 |
|---|
| Delivered first attempt | WordPress and provider IDs differ | One joined delivered notification |
| Deferred then retried | Two provider IDs | Attempts remain separate under one notification |
| Provider failover | Second relay rewrites ID | Ownership and final state remain clear |
| Late bounce | Webhook after entry cleanup | Minimal approved join still resolves |
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.
- Define raw and normalized identifier fields with one owner per system.
- Model each send or retry as an attempt under the Gravity Forms notification.
- Join SMTP responses and provider webhooks through provider IDs and bounded time evidence.
- Restrict, redact, and expire the support record according to policy.
- Test delivery, retry, failover, bounce, suppression, and missing-ID workflows end to end.
Production verification checklist
- Raw Message-ID and provider IDs remain available for the approved retention window.
- Retries and provider failover do not collapse into one false event.
- Delivery, bounce, and suppression webhooks join to the correct attempt.
- Support users can reconcile the case without message bodies or excess personal data.
What to tell the client or owner
Give the owner the affected versions, exact fixture, stable IDs, UTC timeline, before and after evidence, decision, rollback point, unresolved risks, and next review date.
Mistakes to avoid
- Changing production before preserving a reproducible fixture, timestamps, and the current result.
- Treating one successful screen, request, or export as proof that every downstream system agrees.
- Removing logs, identifiers, or rollback evidence before the owner and failure boundary are known.
- Testing only an administrator session instead of the roles, devices, consent states, and failure paths users actually have.
Questions teams ask during testing
Can this be tested on production?
Use production for read-only confirmation and a narrow synthetic fixture. Perform destructive, version, cache-policy, queue, or schema changes on staging first, then promote the smallest proven change.
What evidence should be kept?
Keep versions, fixture IDs, UTC timestamps, request or export evidence, expected and actual results, the decision owner, rollback point, and the final clean verification. Redact personal data.
When is the work finished?
Finish when the canonical user path passes, downstream records reconcile, failure cases are understood, monitoring is in place, and an established page links to the new guide with useful context.
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, trace a Gravity Forms notification.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references