You open the form entries and there they are: names, messages, phone numbers. The enquiries arrived. But the emails that should tell your team about them never did.
This is common, and it is fixable. The key is to treat it as a journey with several stops, not one switch that is “on” or “off”. An email can fail at any stop, and each stop has a different owner.
This guide uses Gravity Forms as the example because it is widely used with WordPress. Other form plugins follow the same pattern with different screen names.
Start here: what a saved entry does and does not prove
When someone submits a form, a chain of events starts:
- The website saves the entry in its database.
- The form plugin builds a notification email.
- WordPress hands the email to the website’s sending method.
- The sending method passes it to a mail server.
- The mail server delivers it to the recipient’s mail system.
- The recipient’s system places it in an inbox, a spam folder, or rejects it.
A saved entry proves step 1 only. Gravity Forms’ own troubleshooting guide makes the same point: it saves the entry and hands the email to WordPress, and delivery after that depends on servers it does not control.
So “the entry is there” is good news. It means no enquiry is lost. It does not mean anyone has been told.
Step 1: check the notification settings
The most common cause is also the simplest. In the form’s settings, open Notifications and look at each one.
Check that:
- The notification is switched on.
- The Send To address is spelled correctly, with no stray spaces.
- If you use routing (different recipients for different answers), at least one rule matches the test you submitted.
- The From address uses a real address on your own website’s domain. Put the visitor’s email in Reply To instead.
- The From and To addresses are not identical. Gravity Forms’ guide lists identical addresses and invalid From addresses as common causes of mail being marked as spam or rejected.
If you changed anything, submit a new test and see whether the result changes.
Step 2: read the note on the entry
Recent versions of Gravity Forms (2.4.15 and later) add a note to each entry recording what happened when it tried to send. Open a recent entry and look at the notes.
Two outcomes matter:
- The note says WordPress passed the email to the sending server. The form did its job. The problem lies further along, in step 3 below.
- The note reports a failure. The message usually indicates what went wrong, such as a connection problem or a rejected login. Copy it exactly for whoever fixes it.
Step 3: check how the website sends email
Many hosting accounts send WordPress email directly from the web server. Receiving systems are often suspicious of that, so mail may be rejected or filed as spam, sometimes silently.
A more reliable setup sends website email through an authenticated mail service. Gravity Forms suggests an SMTP plugin or a transactional email service for this. If a plugin like that is already installed, check its log and settings for errors. Typical messages point to a failed connection, a failed login, or a server that refuses the sender address.
This is usually a job for your web developer or hosting provider, because it involves server settings and account credentials. Please do not email passwords. Share the error message and the time of the test.
Step 4: check your domain’s email records
Receiving mail systems check whether a message really comes from the domain it claims. Three DNS records support that check: SPF, DKIM and DMARC. If your website sends email using your domain and those records do not cover the sender, mail may be filed as spam or rejected.
Google’s published sender guidelines explain how these records work and note that missing or misconfigured ones are a common reason for rejection or spam filing. Gravity Forms’ guide also recommends configuring SPF and DMARC.
These records live wherever your domain’s DNS is managed. That may be your registrar, your hosting provider or an IT contractor. Changing them incorrectly can affect all your email, so change them deliberately and test afterwards.
Step 5: look at the receiving end
If everything above looks fine, check the destination:
- The spam or junk folder.
- Quarantine areas, if your organisation uses email filtering.
- Mailbox rules or forwarding that might move or delete the messages.
- A shared mailbox or distribution list with restrictions on outside senders.
- The recipient’s mailbox size, in case it is full.
Ask your email administrator whether the receiving server logged a rejection. If you use a service such as Google Workspace or Microsoft 365, the administrator can often search message logs by sender, recipient and time.
Step 6: rule out conflicts and blocklists
Less often, the cause is one of these:
- A plugin or theme conflict, particularly after an update.
- The sending server’s address appearing on an email blocklist.
- A limit at your host on how many emails can be sent.
These need technical investigation. Gravity Forms’ guide suggests enabling logging and keeping the logs, testing for conflicts and asking the host to review server logs.
A diagnostic table to print
Work down this table and note the result of each check.
| # | Check | What a good result looks like | Who usually looks into it |
|---|---|---|---|
| 1 | Entry exists in the form’s entries list | Test entry appears with the right data | You or your web developer |
| 2 | Notification is enabled and addressed correctly | Right recipient, no typos, routing matches | Web developer |
| 3 | From address is valid and on your domain | Real address, different from the recipient | Web developer |
| 4 | Entry note after sending | Says the email was passed to the sending server | Web developer |
| 5 | Sending method | Authenticated SMTP or a mail service, with no errors in its log | Web developer or host |
| 6 | SPF, DKIM and DMARC | Records exist and include the sending service | DNS or IT contact |
| 7 | Receiving mailbox, spam and quarantine | Message found or a logged rejection reason | Your email administrator |
| 8 | Conflicts, blocklists, host limits | None found | Developer, host |
| 9 | Retest to a different external address | Test message arrives | Everyone |
Test to a second address at a different provider, for example a personal mailbox. If it arrives there but not at your business address, the issue is probably at the receiving end. If it arrives nowhere, look at the sending side.
What to send when you ask for help
A good request saves hours. Include:
- The form’s name and web address.
- The date and time of one or two test submissions.
- The email address you expected to receive them.
- What the entry’s notes say.
- Whether it ever worked, and what changed since: updates, a new host, a new email provider or DNS changes.
- Screenshots of the notification settings.
Do not include passwords. Use synthetic details such as “Test Person” when testing so you do not create real-looking enquiries.
Recovering the enquiries you missed
Because the entries were saved, you can usually still contact those people. Gravity Forms can resend notifications from the entries list: select the entries, choose Resend Notifications, pick the notification and, if needed, enter a different recipient. Fix the underlying delivery problem first, or the resend may fail the same way.
After it is fixed
Fixing the immediate fault is half the job. Put these in place so you notice next time:
- Test the form after every significant website update, hosting change or email change. Our guide to testing a website form properly gives a step-by-step plan.
- Agree who receives form emails and who checks the entries list if the inbox is quiet for too long.
- Consider logging email sending so you have evidence if it fails again.
A sensible next step
If you have followed the table and still cannot find the break, we can look at it. Our WordPress support team troubleshoots forms and email delivery, and our care plans are there for ongoing help. Send us the details listed above and we will tell you what we find.
