Whether your contact form submissions survived an email outage depends almost entirely on which form plugin you run. Gravity Forms and Fluent Forms write every entry to the database before notifications are attempted, so those submissions are still there; Contact Form 7 stores nothing at all by default, and WPForms Lite sends by email only, so on those two the messages are usually gone unless a companion plugin was already active. The check takes minutes once you know where to look. This guide covers where each major plugin keeps entries, the settings that silently disable storage, and the two mail logs that tell you which notifications actually failed during the outage window.
Table of Contents
- Which plugins store entries and which do not
- Where to look, plugin by plugin
- The Contact Form 7 settings that switch storage off
- Confirming which notifications actually failed
- Using WP Mail SMTP's log as a second record
- Closing the gap before the next outage
- Frequently Asked Questions
Which plugins store entries and which do not
Contact Form 7 does not save submitted messages anywhere in the database. Contact Form 7's own documentation states that a mail-server problem or a mistake in mail configuration means those messages are lost permanently. If you run CF7 with no companion plugin, there is no local copy to recover. The companion is Flamingo, written by Contact Form 7's author.
Per the WordPress.org plugin directory listing, Flamingo saves every contact-form message into the WordPress database and lists them under an "Inbound Messages" admin menu, with Subject and From columns showing the submitter's name and email, and search across them. If Flamingo was installed and active before the outage, your submissions are sitting there. WPForms Lite is the other gap. WPForms' own documentation confirms Lite sends submissions by email only and does not store entries in the WordPress database or dashboard — database entry storage requires a paid licence, Basic tier or above. A Lite site during a mail outage typically has nothing stored locally.
Where to look, plugin by plugin
Run these checks in order. Each takes a minute, and the absence of an entries screen is itself an answer.
Gravity Forms and Fluent Forms are the reassuring cases. Gravity Forms records the entry in the database regardless of whether the notification email ever left the server, which is why entries appear in Entry Detail during an outage. Fluent Forms does the same across its submission, entry-detail and meta tables, documented in its database schema, independent of how email notifications are configured.
- Contact Form 7: look for a Flamingo menu in the WordPress admin sidebar. If it is there, open Flamingo → Inbound Messages and filter by date to the outage window.
- WPForms Lite: check whether Lite Connect was enabled. WPForms describes Lite Connect as capturing entries during the period it is on, encrypting them and storing them in the cloud, where they become visible in the dashboard after upgrading to Pro.
- Gravity Forms: go to Forms → Entries and open Entry Detail. Entries are recorded independently of notification delivery.
- Fluent Forms: open the form's Entries screen. Fluent Forms saves every submission automatically to its own custom database tables.
The Contact Form 7 settings that switch storage off
Having Flamingo installed is not sufficient. Contact Form 7's Additional Settings tab — a plain text box on each form's edit screen — can suppress storage per form, and nothing in the admin warns you that it did.
Three keys matter, all described in the Contact Form 7 additional settings documentation: So before you tell a client their enquiries are recoverable, open the Additional Settings box on the specific form. A site running `do_not_store` or `demo_mode` has no local copy to recover, Flamingo or not.
- `do_not_store: true` — tells Flamingo not to save that form's data. No local copy exists for that form.
- `demo_mode: true` — blocks both the email and the storage. Nothing was sent and nothing was kept.
- `skip_mail: true` — blocks the email but still lets Flamingo store the entry. This is the one case where a form that never emailed still has everything recorded.
Confirming which notifications actually failed
Knowing entries exist is half the job; you also want to know which notifications never arrived, so you can follow up with the right people. Checking `wp_mail()`'s return value is not a reliable outage test on its own. The precise signal is the `wp_mail_failed` action.
Per the WordPress developer reference, WordPress fires this hook after a PHPMailer exception — available since WordPress 4.4 — passing a `WP_Error` that carries the exception message plus the recipient, subject, message, headers and attachments. That payload is exactly the detail needed to identify which individual submissions failed. Gravity Forms gives you a built-in route to the same answer: Forms → Settings → Logging can be enabled to confirm whether a notification was attempted and what `wp_mail()` returned, as the Gravity Forms troubleshooting guide describes. Turn it on before the next incident, not during it.
Using WP Mail SMTP's log as a second record
If the site runs WP Mail SMTP, its Email Log is a second, independent record of the outage. WP Mail SMTP's documentation says the log stores each attempt with sender, recipient, date and time, status and error message, and a Technical Details panel exposing headers, source and the delivery error. Filter the log to the outage window and match rows against the form entries you found.
Where an entry exists and the log shows a failure, you have a submission to answer manually. Where an entry exists and no log row exists at all, the notification was likely never attempted — check the form's own settings next. One limitation matters when you report back to a client: a "Sent" status in the log confirms handoff to the mail service only. It is not proof the message reached anyone's inbox, so treat "Sent" rows in the outage window as unresolved rather than fine.
Closing the gap before the next outage
The fix for each plugin is small and worth doing while the incident is still fresh. On a Contact Form 7 site, install Flamingo and then check every form's Additional Settings for `do_not_store` and `demo_mode`.
On WPForms Lite, either enable Lite Connect or accept that email is your only copy. Gravity Forms and Fluent Forms need nothing added for storage, but Gravity's logging switch is off until you turn it on. Enable it, and enable an email log, so the next outage leaves you a list of exactly which enquiries to chase rather than a guess.
Frequently Asked Questions
Does a failed notification email mean the entry was never saved?
Not in Gravity Forms or Fluent Forms. Both write the entry to the database independently of notification delivery, so entries appear on the Entries screen even when no email ever arrived.
Can I recover Contact Form 7 messages after the outage if I install Flamingo now?
No. Flamingo saves messages as they are submitted. Installing it afterwards captures future submissions only, and Contact Form 7 kept no copy of the earlier ones.
Where does WPForms Lite Connect store captured entries?
In the cloud, encrypted, covering the period Lite Connect was enabled. They become visible in the WPForms dashboard after you upgrade to Pro.
You Might Also Like
- WordPress Maintenance: Google Login Stops Working During an Account Lockout: How to Check Existing Local Admin Access
- WordPress Maintenance: Backups Stored in Google Drive: What to Check When the Connected Account Becomes Unavailable
- WordPress Maintenance: Google Calendar Embeds During an Account Outage: How to Check Public and Private Access Separately
