Saving contact form submissions in the WordPress database

Why the order matters

A form that emails first and saves second — or never saves — depends on the least reliable part of WordPress. PHP mail is disabled on many hosts, SMTP passwords expire, and notifications land in spam. If saving happens first, every one of those failures is a delay you can see and fix, not a customer you never hear from.

Where the entries should live

There are two common designs. Some plugins store entries as a hidden post type in wp_posts, next to your pages. Others use tables of their own. Separate tables keep your posts table small, make it simple to delete everything cleanly, and let entries have proper columns for status and dates. Mailbag Contact Form uses two tables of its own, created with WordPress' dbDelta(): one for forms and one for entries.

What an entry should record

• The answers, with the labels as they were — if you rename a field next year, old entries still read correctly.
• The date and the page the form was sent from.
• Whether it's new, read or spam, and why it was judged spam.
• What happened to the notification email, and the error if it failed.

Mailbag records all of these. What it doesn't store by default is the visitor's IP address — its limit on repeated messages works on a hashed value that expires on its own.

Reading them

Entries appear under Mailbag → Entries, newest first, with search, a filter per form and a count of unread entries in the menu. You can open one at a time, mark it as spam, delete it, resend its notification, or export the list to CSV. See exporting entries to CSV.