When a Gravity Forms entry exists but its notification is missing, check whether that notification was eligible to run before changing SMTP providers. Entry storage, notification selection, WordPress mail handoff, and delivery to a mailbox are separate checkpoints.
Begin with one controlled entry
Submit a clearly labeled test using an address and inbox your team controls. Record the form ID, entry ID, timestamp, and expected notification name. Avoid using a customer's real record for repeated resends. Confirm the entry is present and check its status, including whether it was classified as spam.
If the entry was blocked or misclassified, investigate that earlier stage. The existing honeypot false-positive guide covers one specific failure. Do not disable all spam protection simply to make a notification appear.
Check the notification's own decision
Open the correct form's notifications. Verify the intended notification is enabled, attached to the right event, and configured with a usable recipient. Evaluate its conditional logic against the saved values in this entry, not the values you remember selecting in the browser.
Gravity Forms notification troubleshooting distinguishes configuration and mail-related causes. For a conditional recipient, check the branch selected by the test. A blank merge-tag result or a branch with no destination can explain why another notification from the same form works.
Explanatory worksheet for your own test evidence. No customer results are represented.
Trace the next handoff only after eligibility
| Evidence |
Interpretation |
Next step |
| Entry saved, condition false |
Notification not selected |
Correct the business rule or the test expectation |
| Notification selected, no mail attempt |
Failure before transport |
Inspect relevant Gravity Forms and application logs |
| Mail provider rejects request |
Transport or sender problem |
Read the sanitized provider error |
| Provider accepts message |
Handoff occurred, inbox not proven |
Check delivery events and mailbox filtering |
WordPress's wp_mail reference warns that a successful return does not prove the recipient received the message. Keep the application event, provider message ID, and mailbox result distinct. Do not label all missing messages as an SMTP failure.
Test recipient and sender choices carefully
Use a sender identity the site's mail provider authorizes. A visitor's address usually belongs in Reply-To when appropriate, not as an arbitrary authenticated From identity. Confirm the exact recipient mailbox with its owner, including aliases, forwarding, and quarantine rules.
If one team inbox fails while another controlled inbox receives the same test, compare delivery events and mailbox policy before rewriting the entire form. If every WordPress email is missing, the broader contact-form mail delivery guide is the better next path.
Resend once, with an explicit purpose
After correcting the failing checkpoint, choose a single controlled entry and the intended notification. Confirm who will receive it before resending. A resend can notify staff, customers, or an automation downstream of the inbox. It is not a harmless diagnostic when used across hundreds of real entries.
Record whether the resend follows the same event conditions as an original submission in your installed configuration. Then submit a new test to prove the normal path works, rather than concluding from a manual resend alone. Keep test entries identifiable for cleanup under the site's retention policy.
Close the loop
The completed test should identify the saved entry, selected notification, resolved recipient, mail attempt, provider disposition, and observed mailbox result. Remove verbose temporary logs or shorten retention after collecting the evidence; notifications can contain personal information.
When the form and mail teams each report success but the inbox remains empty, ask HandL WP to trace the notification using those checkpoint IDs. A precise handoff record usually narrows the problem faster than replacing several mail plugins at once.
References checked September 25, 2026. Illustrations and examples are explanatory, not customer case studies.