Gravity Forms notifications: seed-test before you publish

Gravity Forms is the premium workhorse on WordPress. Long forms, conditional logic, partial entries, Stripe and Zapier out of the box. For anything more structured than a name-and-email contact form, it is usually the right tool.

Notifications are where deliverability enters the picture. Every Gravity form can fire one or more notifications on submit: a copy to the submitter, a copy to the internal team, a copy to a warehouse team if the form includes a shipping block, and so on. Each notification is an email. Each email has to reach its recipient. If any one of them silently lands in spam, your operations break — and you will not know until somebody complains.

How Gravity Forms routes notifications

Gravity Forms uses WordPress's wp_mail() function for every notification. Whatever wp_mail() is configured to do, Gravity inherits. On a default WordPress install that means PHP mail() and whatever the host's local MTA does with it — which, as covered in our CF7 article, is essentially a deliverability dead end.

The fix is the same class of fix: install an SMTP plugin (WP Mail SMTP, FluentSMTP, Post SMTP) and connect it to a real authenticated relay. Once wp_mail() routes through that relay, every Gravity notification — admin, user, conditional, auto-responder — goes with it.

Relay choices for Gravity workloads

• Google Workspace or Microsoft 365. Fine for under a few hundred notifications per day. Simple auth, no separate billing. Watch the daily send quota if the form is popular.
• Transactional ESPs (Postmark, Amazon SES, Brevo, Resend, Mailgun). Better for consistent volume. Give you per-message logs, webhooks on bounces, and dedicated domain signing.
• Dedicated ESP (SendGrid, SparkPost) with a sending subdomain. Makes sense when the same WordPress site also sends newsletters or transactional order mail and you want notifications on a different reputation.

The preview-fork workflow

The right time to catch a deliverability problem is before the form reaches real users. That means building and testing on a staging site that mirrors the production configuration closely enough for notifications to behave identically.

1. Fork the production site to staging. Most managed WP hosts (WP Engine, Kinsta, Pressable, Pantheon) have a one-click clone.
2. Override the SMTP plugin on staging to send via the same relay but with a "staging" subdomain or a sandbox stream. For example, Postmark has separate Sandbox servers; SES has a sandbox mode. You want DKIM signing with keys on a domain you control but no risk of notifications leaking to real submitters.
3. Build the form and its notifications. Use a test entry with seed addresses as the submitter.
4. Submit once. Capture each generated notification from the Gravity Forms entry log or the SMTP plugin's log.
5. Run each captured notification through a placement tester. Every notification is a separate email with its own subject, body, and recipient set, so each one gets its own verdict.
6. Fix whatever fails (usually authentication, sometimes content scoring from a stock subject line like "New form submission"), and rerun.

Merge tag pitfalls

Gravity's merge tags are powerful and occasionally dangerous. A few that commonly cause deliverability or rendering issues:

• {all_fields} renders every submitted field into the email body as an HTML table. On long forms this produces a message body that is mostly structured data, which content filters sometimes score as a phishing pattern. Break it into logical sections instead.
• {entry_url} exposes a link back into wp-admin. Fine for internal notifications, disaster for submitter notifications. Double-check every notification's audience before using admin-facing merge tags.
• {admin_email} as From: is the default and is a problem if the admin email is on a different domain from the site. Use a dedicated mailbox on the site's domain instead.

From:       "Acme Forms" <forms@acme.com>
Reply-To:   {Name:1:value} <{Email:3:value}>
To:         ops@acme.com
Subject:    New quote request from {Company:4:value}

Conditional notifications

Gravity Forms lets you fire different notifications based on field values. A common pattern is a single form that routes to sales, support, or partnerships depending on a dropdown. Each branch needs its own deliverability check — it is entirely possible for one branch to land and another to bin.

Causes we have seen:

• Different To: domains with different filter configurations (e.g. sales@ on Google Workspace, partnerships@ on a self-hosted Zimbra with aggressive content scoring).
• Different attachments per branch. Invoice uploads, CV files, and image attachments push some content scorers over threshold.
• Different subject patterns per branch, one of which happens to match a known phishing template.

Test each branch with a representative entry. Submit once with dropdown value A, once with B, once with C. Capture and seed-test all three.

Ongoing monitoring after launch

A form that worked on launch day can drift. Reasons: the relay rotated an IP onto a freshly listed pool, DMARC aggregate feedback flags a new alignment issue, a plugin update changes a header, the sending subdomain gets listed on URIBL because of an unrelated marketing campaign.

Mitigation:

• Schedule a weekly seed test of the primary notification. Catch drift before a user complains.
• Point DMARC rua reports at a mailbox you actually read (or a DMARC aggregator). A policy drift will show up in aggregate reports a day or two before it produces user-visible problems.
• Keep the staging site current. If notifications change, replay through the staging workflow rather than editing production.

Frequently asked questions