Why emails not arriving from forms — and how to fix it

How to fix contact form submissions that are not delivering email

A visitor fills in the Contact Us form on the Acme Coffee Roasters website and clicks

Submit. The form shows the thank-you message, so the submission went through. But no notification email arrives in the inbox. Wholesale enquiries are going unread; catering requests are piling up with no response. This guide walks every reason that form notification emails can fail to deliver and the fastest way to find which one applies.

Work through the five checks below in order. The most common cause is a notification address typo or a spam filter — both take under two minutes to confirm. If you reach check 5 you are working with an integration destination that is not receiving the submission payload, which requires a connection re-test from the integrations panel.

What is this for?

This guide is for SGEN admins whose form notification emails are not arriving at the intended recipient address, even though the form itself is accepting submissions and displaying a confirmation to the visitor. It covers the path from "a visitor submits a form" to "the notification email arrives in an inbox", identifies every point where that path can break, and gives you one concrete action at each point to confirm or rule it out.

This guide specifically covers the notification email sent to the site admin or team when a form is submitted. It is not about the confirmation email sent to the visitor who filled in the form — that is a separate notification layer. If visitor confirmation emails are missing, the same checks apply, but the configuration screen to inspect is the Visitor Confirmation tab rather than the Admin Notification tab.

Good use cases

Example 1: Wholesale enquiry form emails going nowhere. Acme Coffee Roasters had a wholesale enquiry form on their site. Submissions were completing successfully (the thank-you page appeared) but no notification emails were arriving at the wholesale team inbox. Check 1 found the notification address field was set to wholesale@acmecofee.com — a typo in the domain. Correcting it to wholesale@acmecoffeeroasters.com and saving restored email delivery within minutes.

Example 2: Catering request emails landing in spam. Acme Coffee Roasters' catering request form was sending emails correctly, but the receiving inbox at the catering team was routing them to the spam folder. The sender address on the notifications was noreply@sgen-mail.com — an address the catering team's email provider had not seen before, so it was treated with suspicion. Check 2 identified the spam folder as the destination. Adding the sender address to the safe senders list in the email client stopped the misclassification.

Example 3: Notification address changed during a site update. During a site content refresh, an admin accidentally changed the notification email on the contact form to their own address while testing. The field was never restored to the team inbox. Check 1 revealed the mismatch. Restoring the correct address resolved delivery immediately.

Example 4: Integration destination disconnected. Acme Coffee Roasters connected their contact form to a third-party CRM to capture leads. After a credential rotation in the CRM, the integration stopped receiving payloads — but because the team relied on the CRM rather than email, they did not notice for three weeks. Check 5 showed the integration connection status as

Error. Re-authenticating the connection from the Integrations panel restored the lead capture flow.

Example 5: From address flagged by receiving mail server. The Acme Coffee Roasters site was sending form notifications from forms@acmecoffeeroasters.com, but the domain's mail authentication records (SPF/DKIM) had not been updated to include the SGEN mail sender as an authorised source. Some recipients' mail servers were rejecting the messages silently. Check 3 identified the mismatch. Updating the domain's SPF record through the domain registrar to include the SGEN authorised sender resolved the silent rejection.

What NOT to use this for

How this connects to other features

Before you start

Before working through the checks, have the following available:

If multiple forms are affected simultaneously, start at check 3 rather than check 1 — a problem affecting all forms at once is most likely a site-level mail settings issue, not a per-form configuration error. If only one form is affected, start at check 1.

• Admin access to the specific form whose notifications are not arriving.
• Access to the email inbox where the notifications should be arriving — you will need to check the spam or junk folder as part of the process.
• The email address the notifications should be going to, and the email address they are supposed to be sent from.

Where to go

The checks in this guide touch several areas of the SGEN admin:

• Forms list — Admin → Forms
• Form settings — Admin → Forms → Edit → Notifications
• Site mail settings — Admin → Settings → Mail
• Integrations — Admin → Integrations

You will also need access to the recipient email client to check the spam or junk folder as part of check 2.

Steps — five checks to restore form notification emails

1. Confirm the notification address on the form settings screen

Each form stores its own notification recipient address. If this address is empty, incorrectly typed, or set to a test address left over from a previous configuration, notifications will either bounce silently or arrive in the wrong inbox. This is the most frequent cause of missing form emails and takes under a minute to check.

To confirm the notification address:

1. Go to Admin → Forms.
2. Find the form whose notifications are not arriving. Click Edit.
3. On the form edit screen, click the Notifications tab (sometimes labeled Email Notifications depending on your SGEN version).
4. Look at the Notification email field. Read it character by character — domain name typos and transposed letters are the most common error.
5. If the address is wrong or empty, correct it and click Save.

After saving, submit a test entry through the public form and wait up to two minutes for the notification to arrive. If it arrives, the cause was an address error. No further action is needed.

If the address is correct and no notification arrives, continue to Check 2.

{{emit:admin-edit-form {"title":"Form Notifications — Contact Form","subtitle":"Acme Coffee Roasters","fields":[{"label":"Notification email","value":"hello@acmecoffeeroasters.com","type":"text"},{"label":"Subject line","value":"New contact form submission — [Name]","type":"text"},{"label":"From name","value":"Acme Coffee Roasters Website","type":"text"},{"label":"Reply-to field","value":"[Email] (maps to visitor's submitted email)","type":"text"},{"label":"Notification enabled","value":"Yes","type":"toggle"}],"primaryAction":"Save","height":260}}

2. Check the spam or junk folder at the recipient address

Form notification emails are often misclassified by spam filters, particularly if the sending address is unfamiliar to the receiving mail server or if the email contains keywords associated with automated messages. The email may be arriving, but landing in spam before anyone sees it.

To check:

1. Open the inbox that should be receiving the notifications.
2. Look in the Spam, Junk, or Promotions folder (the folder name varies by email client and provider).
3. Search for the sender address — typically the from-address configured in your site's mail settings, or a platform notification address. You may also search by the expected subject line.

If you find the notification in spam:

• Mark it as Not spam or Safe sender — this trains the email client to deliver future notifications correctly.
• Add the sender address to your contacts or safe senders list to prevent future misclassification.

If the notification is not in spam or junk, it did not arrive at the recipient address at all. Continue to Check 3 to investigate the site-level mail settings.

3. Review the site mail settings

The site-level mail settings in SGEN control the sender name, the from address, and the mail relay used to dispatch all form notifications. If these settings are misconfigured — or if the from address is not authorised by the domain's mail authentication records — the receiving mail server may reject notifications silently before they reach the inbox or spam folder.

To review mail settings:

1. Go to Admin → Settings → Mail.
2. Check the following fields: - From email address — this should be an address on a domain you control, ideally the same domain as your website. A generic or unfamiliar from address is more likely to be flagged by receiving mail servers. - From name — this should clearly identify your business or site so the recipient can recognise the sender. - Mail relay / SMTP settings — if your site is configured to use a custom SMTP server, confirm the host, port, username, and password are correct and the server is reachable.

After reviewing and correcting any settings, click Save Settings, then submit a test form entry and wait up to two minutes for delivery.

If notifications are still not arriving, continue to Check 4.

4. Send a test email from the mail settings screen

Most SGEN mail settings screens include a Send test email action. This bypasses the form submission flow and sends a raw test notification directly from the mail relay to a target address. If the test email arrives, the mail relay is working correctly and the problem is specific to the form's notification configuration. If the test email does not arrive, the relay itself is the issue.

To run the test:

1. Go to Admin → Settings → Mail.
2. Click Send test email (the label may vary — look for a "Test" or "Verify" action near the mail settings fields).
3. Enter the recipient address where the test should arrive.
4. Click Send.
5. Wait up to two minutes, then check the inbox — including the spam folder.

If the test email arrives: the mail relay is working. Return to the form's notification settings (Check 1) and carefully re-enter the notification address to confirm it is correct and the form is enabled.

If the test email does not arrive: the relay is not delivering. Check the SMTP settings (if using a custom SMTP server) or contact SGEN support to investigate the platform mail relay. Include the recipient address you used for the test and the time of the attempt.

5. Check the integration connection status

If your form is connected to a third-party destination — a CRM, a help-desk tool, or a marketing platform — that integration may be the intended recipient of the submission payload rather than (or in addition to) an email address. If the integration connection has expired, been disconnected, or is in an error state, submissions from that form may appear to send correctly but never reach the connected tool.

To check the integration status:

1. Go to Admin → Integrations.
2. Find the integration connected to the form in question.
3. Look at the Status column. A healthy connection shows Active or Connected. An error state shows Error, Disconnected, or Expired.

If the status shows an error:

1. Click the integration to open its settings.
2. Use the Reconnect or Re-authenticate action to re-establish the connection. You may need to log in to the third-party tool to authorise the connection again.
3. After reconnecting, submit a test form entry and verify the submission appears in the connected tool.

If the integration reconnects and submissions start flowing again, the cause was an expired or disconnected integration. Integration credentials sometimes expire when third-party tools rotate API keys or when a connected user account is deactivated. Check whether the connected tool requires periodic re-authentication and set a reminder to reconnect before the next expiry.

The Wholesale form — Help-desk row above shows an Error status with a last sync three weeks ago — a clear signal that the connection broke at that point and has not recovered. Reconnecting will resume the flow of wholesale submissions to the help-desk tool.

What success looks like

What to do if it does not work

If you have worked through all five checks and notifications are still not arriving, collect the following before contacting SGEN support:

1. The name of the form and the notification address it is configured to send to.
2. A screenshot of the form's notification settings screen showing the current configuration.
3. A screenshot of the site mail settings screen.
4. The result of the test email from Check 4 — did it arrive, and in which folder?
5. If using a custom SMTP relay: the SMTP host, port, and whether the credentials have changed recently.
6. The time of your most recent test form submission.

When contacting support, the test-email result (Check 4) is the most useful data point. If the test email arrived but form notifications did not, the problem is isolated to the form configuration. If the test email did not arrive either, the problem is at the relay level. Knowing which before you contact support gets your report to the right team.

Quick reference — the five checks

Common causes at a glance

Typo in the notification address is the most frequent single cause. A single character error in the domain or username sends every notification to a non-existent address. Because the sending system does not receive a bounce-back in most configurations, there is no obvious error signal and the issue can go undetected for weeks.

Spam filter misclassification is the second most common. Platform notification emails are sent from automated infrastructure addresses that a recipient's mail provider may not recognise. Training the email client to trust the sender by adding them to the safe senders list resolves this going forward.

Integration connection expiry tends to manifest all at once — everything was working, then stops on a specific date when credentials rotated. The integration status panel shows the last successful sync date, which makes this easy to pinpoint.