A Gravity Forms entry can exist and the notification action can report success while the mail provider has no matching message, rejects it later, or delivers it to an unexpected mailbox. The missing bridge is usually a stable message ID that connects the entry, notification, wp_mail call, SMTP transaction, provider event, and recipient result. Without that join, teams compare timestamps and subject lines that are neither unique nor reliable.
Use this when Gravity Forms notifications are intermittent, only one recipient misses mail, provider logs disagree with WordPress, or a support team needs proof of where one message stopped.
Quick answer
Submit one canary entry with a unique marker, capture the Gravity Forms entry and notification IDs, then record the Message-ID or provider ID at the SMTP handoff. Join subsequent accepted, deferred, bounced, delivered, opened, or suppressed events by that ID. If the provider never creates an ID, investigate the WordPress-to-SMTP handoff. If it does, continue with provider routing and recipient evidence.
What to check first
- Record form ID, entry ID, notification ID, recipient expansion, subject canary, UTC submission time, and request ID.
- Capture wp_mail arguments and the SMTP response without logging message bodies, passwords, or full personal data.
- Preserve the RFC Message-ID, provider message ID, queue ID, recipient, provider event type, reason code, and event time.
- Check suppression lists, bounces, routing rules, aliases, quarantine, spam placement, and mailbox acceptance separately.
- Normalize all timestamps to UTC and keep the original timezone beside each row.
Why this usually happens
- wp_mail success means the message was accepted for processing, not delivered to the inbox.
- Provider dashboards use their own message IDs and may not expose the Gravity Forms entry ID unless it is added as metadata or a header.
- A shared subject line and near-identical timestamp can cause support staff to inspect the wrong message.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
entry_id,notification_id,wp_request_id,message_id,provider_id,event,utc
18422,admin_notice,req_f81,<gf-18422@example.com>,msg_9012,accepted,2026-08-11T13:12:10Z
18422,admin_notice,req_f81,<gf-18422@example.com>,msg_9012,delivered,2026-08-11T13:12:14Z
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Create the canary entry and capture Gravity Forms identifiers. | Record form ID, entry ID, notification ID, recipient expansion, subject canary, UTC submission time, and request ID. | One test entry joins to exactly one notification action and provider message per intended recipient. |
| Add safe correlation metadata at the notification or mail transport boundary. | Capture wp_mail arguments and the SMTP response without logging message bodies, passwords, or full personal data. | Every stage includes stable IDs, UTC times, status, and a sanitized reason. |
| Join the SMTP response to the provider message record. | Preserve the RFC Message-ID, provider message ID, queue ID, recipient, provider event type, reason code, and event time. | Email and Email 2 actions remain distinguishable even when subject lines match. |
| Follow provider events through routing, suppression, and mailbox acceptance. | Check suppression lists, bounces, routing rules, aliases, quarantine, spam placement, and mailbox acceptance separately. | The final inbox, bounce, suppression, or routing result is recorded without exposing sensitive form content. |
Decision rule
Assign the incident to the earliest stage that lacks its required next identifier. No provider ID means handoff ownership; a provider ID with a terminal event means provider or recipient ownership.
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 |
|---|
| Normal delivery | One canary entry to a controlled mailbox | Entry, notification, provider message, and mailbox result join to one trace |
| Provider suppression | Controlled suppressed recipient | Provider ID exists and final suppression reason is visible |
| SMTP handoff failure | Invalid sandbox credential or blocked connection | No provider message is created and WordPress records the handoff failure |
| Email and Email 2 | Two actions with different recipients | Each action has its own notification and provider identifiers |
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.
- Create the canary entry and capture Gravity Forms identifiers.
- Add safe correlation metadata at the notification or mail transport boundary.
- Join the SMTP response to the provider message record.
- Follow provider events through routing, suppression, and mailbox acceptance.
- Remove temporary verbose logging and retain a sanitized trace template for support.
Production verification checklist
- One test entry joins to exactly one notification action and provider message per intended recipient.
- Every stage includes stable IDs, UTC times, status, and a sanitized reason.
- Email and Email 2 actions remain distinguishable even when subject lines match.
- The final inbox, bounce, suppression, or routing result is recorded without exposing sensitive form content.
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
- Do not change several production layers at once. Preserve the failing evidence and isolate one variable per test.
- Do not use a successful status or screen message as the only proof. Verify the business outcome and the underlying record.
- Do not leave debug logging, broad credentials, test orders, or temporary exceptions active after the review.
- Do not close the incident without recording the fixture, timestamps, owner, result, and rollback point.
Questions teams ask during testing
Can this be tested on staging?
Start on staging with production-like versions, cache, data shape, and integrations. Finish with one controlled production fixture when the result depends on real routing, provider, or edge behavior.
What evidence should be retained?
Keep the smallest useful set: stable IDs, UTC timestamps, sanitized request or log excerpts, expected result, actual result, version inventory, and the final verification.
When should the change be rolled back?
Roll back when a core revenue, privacy, security, or publishing path fails and the cause cannot be isolated inside the approved maintenance window.
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