Form not sending email
How to fix a form that isn't sending email
When a visitor submits a form and the notification never arrives, there are seven places to check — in order.
Work through the steps below from top to bottom.
Most problems are resolved by step 3.
Scenario used throughout this guide: your business has a Contact form at /contact.
Visitors submit it, the rows appear in the admin Submissions list — but nothing reaches support@yourdomain.com.
What is this for?
This guide is for SGEN site owners and admins who can see form submissions in the admin panel but are not receiving the notification email in their inbox.
It is a structured decision tree: each check tells you what to look at, what a healthy state looks like, and what action fixes an unhealthy one.
If you have never built the form yet, start with Build a form first — this guide assumes the form exists and is saving submissions.
If you are not sure whether the form is saving at all, jump straight to Check 7 (Submissions record) before anything else.
Good use cases
Example 1: SMTP is off — the most common root cause. The site was migrated to a new host.
The previous host allowed PHP mail on port 25; the new host blocks it.
Every form notification, password reset, and order receipt stops arriving at the same time.
Flipping Enable SMTP on in Settings → Email and pasting the provider credentials fixes all of them at once — one change, one transport.
Example 2: Notification recipient field was never filled in. A form was duplicated from an older form to save setup time.
The Title and fields were updated, but Mail Settings → To was left blank from the original.
Every submission silently discards the notification because there is no address to route it to.
No error appears to the visitor or the admin — the submission saves, the email never fires.
Opening the form, filling in support@yourdomain.com in the To field, and clicking Update a Form fixes it immediately.
Example 3: Tracking Consent is gating the form notification. The site has Gate Draft Form Entries turned on under Tracking Consent.
Visitors who declined the consent banner on their first visit are having partial auto-saves suppressed.
On a short form (Name, Email, Message) this causes no problem — a completed submit still fires the notification.
On a longer form with many fields, the auto-save suppression can interact with how the submission is recorded, and notifications arrive late or not at all for decline-banner visitors.
Turning off Gate Draft Form Entries in Tracking Consent → Settings restores normal notification behavior and does not affect analytics consent gating.
What NOT to use this for
Marketing emails go through a separate sending platform and are not routed through SGEN's form notification system. This guide covers only SGEN admin-generated notifications: form submissions, password resets, order receipts.
The test tool sends one diagnostic email to one recipient with a fixed subject. It is a verification tool only.
If you enter an invalid address in the Testing card, the panel shows the validation notice more than once. No emails were queued. Enter a valid address and a message of at least 5 characters, then verify delivery in the actual inbox.
Wrong SMTP credentials and an empty notification recipient are by far the most common causes, and both take under a minute to fix.
How this connects to other features
— the SMTP transport that carries form notifications is the same transport used by password resets, order receipts, and admin user-invitation emails. Fixing the transport in Configure SMTP fixes all of them at once.
— the Mail Settings card inside the form builder is where the notification recipient (To field) and email template live. See Build a form for the full field reference including shortcode tokens.
— the Gate Draft Form Entries exclusion interacts with form submission timing. See Configure the cookie consent banner for the Exclusions reference.
— the submissions list confirms whether the form's save path is healthy, independent of email delivery. If rows appear here, the problem is in the delivery chain, not the form itself.
Before you start
- You are signed in to SGEN as an Administrator or Site Owner.
- You can reach Settings → Email and Forms → All Forms in the left navigation.
- You have access to the inbox that should be receiving notifications (
support@yourdomain.comin this example). - You know the URL of the form page (e.g.
/contact) so you can submit a test entry yourself.
Where to go
- Open your SGEN admin left navigation.
- For SMTP checks: click Appearance → Site Settings, then the Email tab.
- For form notification checks: click Forms → All Forms, then click the form name.
- For consent checks: click Tracking Consent → Settings.
- For submission records: click Forms → Submissions (or click View Entries from inside the form editor).
Steps
Open Settings → Email.
Look at the SMTP Configuration card.
The fields are: Enable SMTP, Host, Encryption, Port, Username, and Password.
Check that Host, Port, and Username contain real provider values — not blank, not placeholder text.
A fully configured SMTP card for your business on SendGrid looks like this:
What to look for:
- Host, Port, and Username all have real values — not blank.
- Password renders empty-looking even when configured (that is expected and correct by design).
- If you just filled these in for the first time, click Save Changes before moving on.
If Host was blank: fill it in from your SMTP provider's dashboard, click Save Changes, then move to step 2.
See Configure SMTP for a provider-by-provider credential reference (SendGrid, Mailgun, Gmail Workspace, Amazon SES, Postmark).
Still on Settings → Email, check the Enable SMTP toggle at the top of the SMTP Configuration card.
This is the master switch.
Even when Host, Port, Username, and Password are all populated, if Enable SMTP is off, SGEN ignores every SMTP field and routes email through the web host's default PHP mailer — which is often blocked, rate-limited, or unauthenticated on production hosting.
The two states side by side:
If the toggle is off:
- Tick Enable SMTP.
- Click Save Changes.
- Continue to step 3, then run a test email at step 6 to confirm delivery.
Open Forms → All Forms.
Click the Contact form (or whichever form is not sending).
Scroll to the Mail Settings card.
Three things must be true for the notification to fire:
- Send email on submission checkbox is ticked.
- To field contains a real, watched inbox — in this case
support@yourdomain.com. - Subject is not blank.
The Mail Settings card as it should look for your business' Contact form:
Common findings at this step:
- To field is empty — the form was duplicated and the recipient was never updated.
- To field has a typo (
suport@instead ofsupport@). - Send email on submission was accidentally unticked during a recent edit.
Fix any of these, click Update a Form, then submit a test entry from the public /contact page and check the inbox.
If email still does not arrive after fixing these three fields, continue to step 4.
Open Tracking Consent → Settings (left nav).
Scroll to the Exclusions section.
Look at the Gate Draft Form Entries toggle.
When this is on, visitors who declined the consent banner have their form auto-saves suppressed.
On most short contact forms this causes no issue — completed submissions still fire the notification.
On longer multi-field forms, or any form where auto-save timing interacts with submission finalization, you may see inconsistent notification delivery for visitors who declined the banner.
The Exclusions grid in a typical active setup, with Gate Draft Form Entries off (recommended for notification reliability):
If Gate Draft Form Entries is currently on:
- Consider whether your site has a legal requirement to gate form auto-save behind consent.
- If not, untick it in Tracking Consent → Settings, click Save Config.
- Re-submit a test form entry and confirm notification delivery.
See Configure the cookie consent banner for the full Exclusions reference.
Open the receiving inbox (support@yourdomain.com).
Check the Spam or Junk folder first — the majority of missing notifications are there, not lost.
If the notification is in spam, open it and look at the email headers ("Show original" in Gmail, "View source" in Outlook).
Look for these three lines:
Authentication-Results: mx.google.com; dkim=pass header.i=@yourdomain.com header.s=sendgrid header.b=Rk3pL4Xa; spf=pass (google.com: domain of hello@yourdomain.com designates 167.89.0.1 as permitted sender) smtp.mailfrom=hello@yourdomain.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=yourdomain.comAll three values — dkim=pass, spf=pass, dmarc=pass — mean your domain and SMTP provider are correctly aligned and deliverability should be clean.
If you see dkim=fail or spf=fail:
- Your DNS records do not include the SMTP provider configured in Settings → Email.
- Log in to your DNS provider and add the SPF
include:record and the DKIM CNAME or TXT record that your SMTP provider specifies in their setup guide. - DNS changes take up to one hour to propagate. Retest after that window.
SPF and DKIM records live with your DNS provider, not inside SGEN.
SGEN sends the email; DNS records tell the receiving server that you are permitted to send for that domain.
Without both records, transactional email lands in spam regardless of how well SMTP is configured here.
Go back to Settings → Email.
Scroll to the Email Testing card at the bottom of the panel.
Enter support@yourdomain.com in the Email address field.
Leave the Content at its default (or type a short message — at least 5 characters).
Click Send Email.
A note about the panel's validation behavior: if you enter an invalid email address or leave the Content field under 5 characters, the validation notice can appear more than once in the panel simultaneously.
This is a display quirk — no emails are sent on the error path.
The fix is to enter a valid address and a message of at least 5 characters, then confirm delivery by checking the actual inbox rather than counting panel toasts.
When the test fires correctly, you see a single confirmation:
Open the inbox. Confirm:
- The email arrived — not in spam.
- The From line reads
your business <hello@yourdomain.com>— your configured From Name and From Email, not a generic server hostname. - The subject reads
This is just a test email.
If the test email arrives but form notifications do not: SMTP is healthy; the problem is in the form's Mail Settings. Return to step 3.
If the test email does not arrive: SMTP is not working. Steps 1–2 need another pass, or the spam and DNS issue from step 5 applies to the test as well.
Open Forms → Submissions (or click View Entries from inside the form editor).
Find the most recent submission from the /contact page.
The submissions list for the Contact form with recent test rows:
If submission rows are here: the form's save path is healthy. The problem is purely in the email delivery chain. Work through steps 1–6 above.
If submission rows are missing: the visitor's submit either failed silently (JavaScript error, field validation failure, network drop) or the form is in Draft status.
To rule out Draft:
- Open Forms → All Forms, click the Contact form.
- In the right sidebar, check Status — it must read Publish, not Draft.
- Draft forms save nothing and render nothing on public pages. Set to Publish, click Update a Form.
Then submit a test entry from the public page yourself.
If your own row appears in the Submissions list, the save path is now confirmed — continue with delivery checks 1–6.
What success looks like
A visitor submits the /contact form. A row appears in Forms → Submissions with the visitor's name and email within seconds of submit. Within a few seconds more, support@yourdomain.com receives an email with: Gmail's "Show original" on the notification email shows dkim=pass and spf=pass. The Email Testing tool in Settings → Email also delivers to support@yourdomain.com without landing in spam. After fixing Mail Settings and clicking Update a Form, you see the green save banner: Once that banner appears and the next test submission delivers to the inbox, the fix is confirmed.
- Subject:
New Contact from an editor(or whichever name was submitted). - Body containing the submitted Name, Email, and Message fields.
- From line:
your business <hello@yourdomain.com>.
What to do if it does not work
Send a test email from the Email Testing card (step 6). If the test arrives but form notifications do not, check that the form's Send email on submission checkbox is ticked — it is the per-form notification switch and is separate from the SMTP master toggle.