If a WPForms notification is in the spam folder, the message was generated and reached a receiving system. That is a different problem from a notification that was never selected or a form that never submitted. Start with the received message's headers and filtering evidence, not by rebuilding the form.
For notifications missing everywhere, use the broader WordPress form email checklist first. The workflow below assumes you can find at least one example in junk or quarantine.
Preserve a Message That Failed
Keep the message ID, delivery time, visible From address, Reply-To, subject, and authentication summary. Use the mailbox's original-message or header view. Save private evidence in a restricted support record, not a public screenshot. A message that has been forwarded may have different authentication results, so prefer the original recipient's copy.
Write down whether all recipients are affected or just one organization. A shared mailbox rule, tenant quarantine policy, and general sender reputation are not interchangeable explanations. Testing only your own already-whitelisted address can hide the problem.
Compare the Form Setting With the Actual Sender
In the form builder, review Settings > Notifications and the selected notification. WPForms documents sender and recipient mistakes in its notification troubleshooting guide. A configured SMTP plugin may enforce a different From address, so the header is the final evidence of what was sent.
Use a provider-authorized business sender. Route replies with the appropriate Email field Smart Tag in Reply-To. Do not put the visitor's Gmail or business address in From. Check every notification branch that matters; the sales-team copy and the visitor confirmation can use different recipients and content.
Explanatory test plan. Record your own observations; no customer results are shown.
Read Authentication Results Carefully
Ask the sending provider to help interpret SPF, DKIM, and DMARC results for the exact message. A pass on one identifier does not automatically prove alignment with the visible From domain. A generic DNS checker also cannot prove which server sent the failed notification.
Use the provider's current domain-authentication instructions. Preserve legitimate senders already in the domain's DNS configuration. Avoid copying a random SPF include or weakening enforcement across the whole business. Google's form-delivery guidance is useful when Gmail is the affected receiver, but other mailbox providers have their own policies.
Run a Small Content Test
If authentication is correct, compare two new test messages to a recipient you control: the normal notification and a temporarily simplified version on staging. Remove unnecessary tracking links, oversized images, and attachments from the test version. Keep useful context so the message is not an empty subject with a URL.
Record results instead of assuming a single inbox delivery proves a permanent repair:
| Test |
What to keep |
| Normal notification |
Template name, message ID, delivery folder |
| Simplified notification |
Exact content difference and destination |
| Different controlled mailbox |
Provider and whether the symptom repeats |
| Production retest |
Same form branch, actual sender, actual outcome |
WPForms discusses content and sender reputation in its Gmail delivery article. A successful stripped-down test is a clue, not proof that a specific word caused filtering. Avoid repeatedly sending identical test messages at high volume.
Restore Operations Without Hiding the Cause
An internal allow rule can be a temporary continuity measure, but it does not repair delivery to prospective customers. Document any mailbox exception and have its owner review it after the sender issue is fixed. Keep the production notification understandable and retain only the information staff need to act on the inquiry.
Finally, submit the public form with a new test reference. Check the stored entry where available, the notification selected, the provider event, and the actual mailbox folder. Confirm that consented customer confirmations are not being silently suppressed. HandL WP can investigate persistent notification filtering using redacted headers and a controlled test instead of broad changes to your email policy.
Sources checked September 26, 2026. Visuals and examples are explanatory, not customer measurements.