Key facts at a glance
Squarespace form notifications status in 2026
Last updated
- Who actually sends the email
- Notifications come from
[email protected], a Squarespace-owned domain. SPF on your own domain has no effect because the message is not sent from your domain. The visible From or Reply-To often shows the submitter's address, which can fail DMARC alignment at strict receiving providers. - What changed in late 2025
- Gmail began enforcing the bulk sender rules it announced in February 2024 starting November 2025. Senders without proper SPF, DKIM, DMARC alignment, and List-Unsubscribe headers now hit temporary or permanent rejection, not just spam folder placement. Yahoo and Apple Mail tightened in parallel.
- Hallmark symptom
- Submissions appear in the Squarespace Form Submissions panel correctly, but no notification email arrives in your inbox. Test submissions from your own email address sometimes work, sometimes do not, depending on which provider's filter sees them.
- The bounce list trap
- Squarespace maintains an internal bounce list. After enough failed deliveries to a recipient address, that address is permanently blocked. The block survives form edits, plan changes, and account upgrades. Adding the sender to your allowlist after the block exists does nothing because Squarespace is no longer attempting delivery. Only Squarespace support can remove it.
- Most common DIY-fixable cause
- Custom JavaScript or CSS on the form's confirmation message. A syntax error or specificity conflict interrupts the submit handshake. The submission still saves to the panel server-side, but the email-trigger round trip never completes. Squarespace experts cite this as the single most common notification failure.
- Distinctive failure mode
- Notifications fail asymmetrically by recipient provider. Same form, same submitter, same Squarespace site, and Gmail rejects the message while iCloud accepts it, or Outlook puts it in junk while a self-hosted address receives it cleanly. The variance is not random. It reflects each provider's specific enforcement of SPF, DKIM, DMARC, and reputation signals. Squarespace cannot fix this from their side because the rejection is happening at your inbox provider, not at theirs.
Source: Squarespace Help Center, Squarespace community forum, Google Workspace bulk sender guidelines and February 2024 announcement, and our hands-on repairs since the November 2025 Gmail enforcement ramp-up. Get a quote in 60 seconds →
What changed in 2024 to 2026
Squarespace forms send their notification emails the same way they have for years. The visitor submits, Squarespace saves the submission, and a notification email is generated and sent from [email protected] to whatever recipient addresses you configured on the Storage tab. None of that changed. What changed is the receiving side. Gmail published its bulk sender rules in February 2024, gave senders a year to comply, then began enforcing in November 2025. Messages that would have landed in spam in 2024 now hit temporary or permanent rejection. Messages that would have landed in inbox in 2023 now land in spam.
Squarespace did not change its sending architecture in response. Form notifications still come from a Squarespace-owned domain, not yours, which means SPF records on your own domain have no bearing on whether the notification gets delivered. Squarespace signs with DKIM on its own domain, but the visible From or Reply-To address on form notifications often shows the form submitter, which creates a header-alignment mismatch that strict DMARC implementations at receiving providers can flag. The combined effect for a small-business site owner is that a form that worked fine in early 2025 starts losing notifications in late 2025 and is functionally broken by mid-2026, with no setting on Squarespace's side to flip and no DNS change on the owner's side that fixes it.
- February 2024: Google announces bulk sender rules requiring SPF, DKIM, DMARC alignment, and List-Unsubscribe headers for senders above 5,000 messages per day to Gmail. Yahoo announces equivalent rules in parallel.
- Throughout 2024 and 2025: Compliance phase. Marginal messages get filtered to spam but most still reach recipients.
- October 2025: Google retires the legacy Postmaster Tools dashboard and launches Postmaster Tools v2, shifting focus from reputation scores to Compliance Status.
- November 2025: Gmail enforcement ramps up materially. Messages from non-compliant senders begin hitting temporary and permanent rejection rather than just spam folder placement.
- 2026: Continued tightening. Form-notification senders that worked fine in 2023 now require active reputation management to maintain inbox delivery at major providers.
Which symptom matches yours
Match your situation to the row below. Each row points to a different root cause and a different fix path.
| Symptom | Most likely root cause |
|---|---|
| Submissions appear in the Squarespace Form Submissions panel but no email arrives at any address you have configured | The notification path is broken upstream at Squarespace itself. Almost always custom code on the confirmation message, or rarely a paused or downgraded account. |
| Submissions appear in the panel, and notifications arrive at a new test recipient address but not at your usual address | Your usual recipient is on the Squarespace internal bounce list from prior delivery failures. Only Squarespace support can remove it. The block survives form edits and plan changes. |
| Notifications used to reach inbox, started landing in spam in late 2025, and now rarely arrive at all in 2026 | Your inbox provider tightened enforcement. Gmail began enforcing its February 2024 bulk sender rules in November 2025. Squarespace sends from [email protected], which is a marginal-trust sender for many recipients under the new enforcement. |
| Same form, same submitter, same recipient address, and the notification arrives in inbox sometimes and spam other times | Reputation-based filtering. The provider re-scores the sender between messages based on engagement, volume, and time-of-day signals. Marginal-trust senders flip between inbox and spam depending on the current score. |
| Gmail recipients receive notifications fine but Yahoo, iCloud, or Outlook recipients do not | Provider-specific enforcement variance. Each provider applies its own DMARC, SPF, and DKIM checks differently against the same sender. Yahoo and Apple in particular have tightened recently. Squarespace cannot fix this from their side. |
| Google Drive storage was working and stopped, with no notification emails arriving either | The Google Drive OAuth authorization expired or was revoked, which can cascade to break the notification trigger. Reconnect via the form Storage tab, then revoke and re-add the Squarespace app permission in Google Drive itself. |
| You added custom code to the form's confirmation message recently and notifications stopped immediately after | Squarespace experts cite custom code as the single most common notification failure cause. A JavaScript syntax error or CSS specificity conflict can break the submit handshake. Remove the custom code and re-test. |
The three root causes
Almost every Squarespace form-notification failure traces to one of three root causes. Identifying the right one determines whether you fix this in fifteen minutes or spend a week on the wrong path.
1. Receiving provider enforcement filtering or rejecting the Squarespace sender
Squarespace sends notifications from [email protected]. Gmail, Yahoo, and Apple Mail evaluate that sender against their authentication and reputation rules every time it tries to deliver. Since November 2025, that evaluation is stricter. Messages without DMARC alignment or with marginal reputation now get rejected outright in many cases instead of just being filtered to spam. The signature is that test submissions to a fresh, well-trusted recipient (a brand-new throwaway Gmail, or a small-provider self-hosted address) arrive cleanly, while your established recipient address shows nothing in inbox or spam. The notification was rejected at the provider level. Squarespace cannot fix this from their side because the rejection is happening at your inbox, not at theirs. The workaround is to either route the form through a different storage path that uses a more trusted sender domain (Zapier, Mailchimp, Google Drive), or to whitelist the Squarespace sender aggressively at your email provider through allowlist rules, contact list addition, and engagement signals over time.
2. Squarespace internal bounce list permanently blocking your recipient
Squarespace maintains an internal bounce list. When a recipient address fails delivery enough times, Squarespace stops trying. The address is added to the bounce list and the block is permanent. Resolving the original delivery issue, for example renewing an expired domain, emptying a full mailbox, or telling your inbox provider to stop spamming the sender, does nothing to unblock the address at Squarespace because Squarespace is no longer attempting delivery to detect that it would now succeed. The signature is that new test recipient addresses (a fresh Gmail, a colleague's address, a brand-new alias on your domain) receive notifications fine, but the original recipient address you have been using stays silent no matter what you do at the inbox provider. The fix is to contact Squarespace support, reference the affected address, and request bounce list removal. Many support agents are not familiar with the bounce list mechanism, so cite this Squarespace Help Center article and request escalation if needed.
3. Custom code on the form confirmation message breaking the submit handshake
Squarespace experts consistently call this the single most common form-notification failure. The form submit button triggers a JavaScript flow that posts the form data to Squarespace, waits for the server confirmation, then displays the confirmation message and triggers Squarespace's server to send the notification email. Custom JavaScript injected into the confirmation message, third-party tracking scripts attached to the submit event, or CSS that overrides the success-state selectors can break that flow at the confirmation step. The submission still saves to the panel because the data post is independent and completes before the broken confirmation step. The notification email never sends because the trigger depends on the submit handshake completing successfully. The signature is that the failure correlates with a recent edit to the confirmation message or to the page's injected code. Remove any custom code from the confirmation message and the page's code injection panel temporarily, retest, and the email should arrive.
DIY vs hand it off
If most of the left column matches your situation you can fix this yourself in under an hour. If most of the right column matches, get help. We see both ends of this spectrum every week.
Realistic on your own
- ✓You recently edited the form confirmation message or page code injection and notifications stopped after
- ✓Test submissions to a brand-new recipient address arrive fine, original recipient does not
- ✓You have admin access to the form, the Squarespace dashboard, and your inbox provider
- ✓You can comfortably remove custom code from a Squarespace form to test
- ✓You can contact Squarespace support and wait a few days for a bounce list removal
- ✓You have one form and one recipient address to test against
Hand it off, save the time
- ✗Notifications fail asymmetrically across multiple recipients and you have no idea which path to debug first
- ✗You depend on form notifications for lead capture and revenue is leaking right now
- ✗You have multiple forms across many pages and the failure pattern is inconsistent
- ✗Custom code on the confirmation message is doing something important you cannot just remove
- ✗You tried storage swaps (Mailchimp, Zapier) and notifications still fail
- ✗You do not have admin access to the inbox provider or the DNS records
How to diagnose in 15 minutes
Run these in order. Each step rules out a root cause and points to the next.
In the Squarespace dashboard open the form's Storage tab and check the Form Submissions panel. If your recent test submissions appear there, the form itself is working and the issue is on the notification path. If submissions do not appear at all, you have a different problem (the form post is broken, the page has a script error preventing submit, or the form is set to a non-email storage with no notification configured).
Add a brand-new recipient address you have never used with Squarespace to the form's Email field, separated by commas if you keep the original recipient. Use a Gmail or iCloud throwaway, not one already on the bounce list. Submit a test. If the new address receives the notification cleanly and your original address does not, your original recipient is on the Squarespace bounce list.
If the previous test went to Gmail, try Yahoo, iCloud, Outlook, or a self-hosted small-provider address. If one provider receives notifications and another does not, the failure is at the receiving provider's enforcement, not at Squarespace. This is the November 2025 enforcement effect.
Double-click the form block and inspect the Confirmation Message setting. If it contains any custom HTML, JavaScript, or styling, copy it elsewhere for safekeeping and replace with plain text. Also check Settings then Advanced then Code Injection and temporarily blank the per-page or sitewide injection. Submit a test. If the notification now arrives, custom code was breaking the submit handshake.
Look in the spam or junk folder of every recipient address. On Gmail check All Mail. On Outlook check Junk and Other tabs. On iCloud check Junk. If your inbox provider runs a separate quarantine (Google Workspace admins, Microsoft 365, Proofpoint, Mimecast), check there too. Notifications routed to a quarantine that the recipient never inspects are functionally lost.
On the form's Storage tab, Squarespace surfaces a small error indicator if a connected Mailchimp audience or Google Drive spreadsheet has lost its authorization. A failed storage connection can cascade and break the notification trigger. Disconnect and reconnect any failing storage. For Google Drive, also visit drive.google.com Settings then Manage Apps and remove the Squarespace authorization, then reconnect from the form Storage tab to refresh the OAuth token cleanly.
Submit a support ticket to Squarespace from your admin account. Include your form URL, the affected recipient address, the dates the issue started, the providers affected, and a screenshot of the form Storage tab. Specifically ask whether your address is on the bounce list. Most agents need the prompt; the bounce list is rarely surfaced proactively.
How to fix it
The fix path depends on which root cause your diagnosis surfaced. Each branch below stands alone.
If your inbox provider is filtering or rejecting the Squarespace sender
Three layered fixes, in order of how durable they are.
Aggressively allowlist the Squarespace sender at your inbox. Add [email protected] to your contacts, mark prior misfiled notifications as Not Spam, reply to a recent notification (engagement signal), and create a filter that pushes the sender to inbox and never to spam. On Gmail, the filter pattern is Settings then Filters and Blocked Addresses then Create new filter, From: [email protected], action: Never send to spam plus Always mark as important.
Switch the form to a more trusted delivery path. On the form block's Storage tab, add Mailchimp, Zapier, or Google Drive as an additional storage option. Submissions then route through that path which uses its own sender authentication. Mailchimp and Zapier in particular have invested heavily in maintaining inbox delivery and are much more likely to reach modern inbox providers cleanly than the bare Squarespace notification path.
Route form notifications through your own email service. The most durable fix is to make a Zapier or Make automation that triggers on new submissions and sends a fresh email from your own authenticated domain (Postmark, SendGrid, Mailgun, or your existing transactional provider). That email is authenticated by you, signed by you, and aligned to your domain's DMARC, so it reaches your inbox under any provider enforcement regime.
If your recipient is on the Squarespace internal bounce list
Squarespace does not expose a way to see or manage the bounce list from the dashboard. The only way off the list is to contact Squarespace support and ask.
The ticket should contain:
- Your account email and the site URL
- The affected recipient address that is being blocked
- The dates you started missing notifications
- Confirmation that brand-new test recipient addresses still receive notifications
- An explicit request: please remove this address from the form-notification bounce list
If the first-line agent does not recognize the bounce list, ask politely to escalate. The mechanism is real, internal, and undocumented in the user-facing dashboard. Most agents need the prompt.
While waiting (it can take a few business days), add a temporary secondary recipient address that has never been used with Squarespace forms. New leads will route there until the original address is unblocked.
If custom code on the confirmation message is interrupting the submit handshake
Edit the form block and inspect the Confirmation Message setting. Copy anything in the custom HTML or JavaScript into a backup document, then replace the confirmation message with plain text only. Save and submit a test from a private browsing window.
If the notification email now arrives, the custom code was the cause. Reintroduce the code one section at a time, testing after each addition, until you identify the line or block that breaks the submit. Common culprits:
- A trailing JavaScript syntax error that prevents the page's success-state script from running
- A redirect script that fires before Squarespace finishes the submit handshake
- Custom tracking pixels (Meta, Google Ads conversion) that attach to the wrong submit event
- CSS selectors that override the success-state class Squarespace uses to detect completion
If the code is doing something important and you cannot just remove it, restructure it to run on the final confirmation event Squarespace exposes, not on the submit click. Squarespace's form-success custom event fires after the handshake completes, so tracking scripts attached there do not interfere.
Not sure which branch above applies, or are you losing leads every day this stays broken?
Let us fix it in 2 hours →The bounce list trap most site owners miss
Most Squarespace form-notification advice you find online stops at "check spam and add the sender to your allowlist." That advice assumes Squarespace is still attempting delivery. If your address has been on the bounce list for weeks or months, allowlisting the sender at your inbox provider does nothing because no message is being sent in the first place.
- Add a brand-new recipient address to the form's Storage tab. Use a never-before-used Gmail, iCloud, or self-hosted address.
- Submit a test from a private browsing window.
- Check the new address. If the notification arrives cleanly, your original address is on the bounce list.
Two things to know before you contact Squarespace support:
- 1.The bounce list is not surfaced in your account UI. There is no Settings tab to view or clear it. The first time most site owners discover it exists is when they ask support directly.
- 2.Reactivation can take a few business days. Set up the new recipient address as a temporary primary in the meantime so leads do not pile up unreceived.
A real recent example
Anonymized from a recent repair. Demonstrates how the diagnostic flow maps to the fix path.
A small wedding photographer on Squarespace 7.1 ran a single contact form on her home page. Notifications had reached her Gmail inbox cleanly for two years. In late November 2025, her partner mentioned that a referral never got a reply. Checking back, she found three months of inquiries sitting unread in the Form Submissions panel with not a single notification email in her inbox or her spam folder. She estimated four to six lost bookings worth several thousand dollars in commissions.
A test submission to a brand-new Gmail throwaway arrived cleanly in inbox within ten seconds. The same test submission to her primary Gmail address arrived nowhere. Spam folder empty. All Mail showed no record of the message. She was on the Squarespace bounce list. The trigger had been an earlier two-week mailbox-full episode in mid-October when she was on vacation. Squarespace had attempted delivery enough times during that window to add her address to the bounce list, and even though her mailbox cleared and was operating normally again, Squarespace stopped trying.
A support ticket to Squarespace explicitly requested bounce list removal for her primary address and referenced the timing. The agent confirmed the address was on the bounce list and removed it. While waiting (it took three business days), a temporary secondary recipient at a different provider was added to the form so new inquiries could still reach her. After removal, test submissions to her original address arrived in inbox cleanly. Two prior inquiries from the Form Submissions panel were also replied to manually. Total elapsed time including support response was four days; total active work was 35 minutes.
When to stop and hand it off
Three scenarios where DIY costs more than help. First, multiple forms across many pages with inconsistent failure patterns. Diagnosing each form individually takes hours and the variance often reflects multiple overlapping causes (one form has custom code, another is on the bounce list, a third is failing at a specific recipient's provider). Second, you are actively losing leads worth real revenue and you cannot wait three business days for Squarespace support to process a bounce list removal. We can set up a routed-through-your-domain notification path immediately so leads start arriving today. Third, your business depends on automated handoff from the form into a CRM, a project management tool, or a billing system, and that integration has broken in parallel with the notification failure. We do that integration recovery alongside the notification fix. Our flat rate is $49 to $149, we finish in two hours when scope fits, and we refund in full if we cannot.
Get a quote in 60 secondsSquarespace forms FAQ
My form submissions show in the Squarespace dashboard but I never get the email. Where are they going?
The submission and the notification email are two separate paths. The submission saves to the Squarespace Form Submissions panel as soon as the visitor clicks send. The notification email is generated by Squarespace and sent from [email protected] to whatever recipient address you configured on the form Storage tab. If submissions appear in the panel but no email arrives, the path that broke is the notification email, not the form itself. Three causes account for almost all of these. The notification was filtered to spam at your inbox provider, especially under Gmail November 2025 enforcement. Your recipient address was added to the Squarespace internal bounce list after enough delivery failures and is now silently blocked. Or custom code on the form confirmation message has a syntax error that prevents the submit script from completing the round trip.
Why does [email protected] fail authentication at Gmail and Yahoo now when it worked fine in 2023?
In November 2025 Google began enforcing the bulk sender rules it announced in February 2024. Messages from senders without proper SPF, DKIM, DMARC alignment, and List-Unsubscribe headers now hit rejection or aggressive spam filtering at Gmail, where in 2023 the same messages reached inbox most of the time. Squarespace sends form notifications from a Squarespace-owned domain ([email protected]), but the visible From or Reply-To often shows the form submitter's address. That mismatch between the envelope sender and the header sender can trip DMARC alignment checks at receiving providers. When your own domain inherits stricter Gmail enforcement, an inbox that received Squarespace notifications cleanly for years can suddenly start sending them all to spam without any change on your side.
I cleared my spam folder and added [email protected] to my allowlist but the emails still do not arrive. Is something else wrong?
Likely yes. Squarespace maintains an internal bounce list. When your recipient address fails delivery enough times, for example because the mailbox was full, the domain briefly lapsed, or the provider rejected several messages outright as spam, Squarespace adds the address to the bounce list and stops trying. The block is permanent until Squarespace support removes it. Adding the sender to your allowlist after the address was already bounced does nothing because Squarespace is no longer attempting delivery. The signature symptom is that test submissions go to a different recipient address (or a colleague's address) just fine, but the original notification address you have been using stays silent. The fix is to contact Squarespace support, reference the affected address, and request bounce list removal.
Some form notifications arrive in my inbox and others go to spam, with the exact same form. Why is it inconsistent?
Reputation. Gmail, Yahoo, and most large providers evaluate each individual message against your inbox's current trust score for the sending domain, the time of day, the volume of similar mail recently sent, and whether you engaged with prior messages from the same sender. Two notifications can be generated by the exact same Squarespace form and the exact same submitter, yet one lands in inbox and the other lands in spam because the provider re-scored the sending domain in between. This intermittent pattern is the hallmark of a marginal-trust sender, which [email protected] has become for many recipients in 2026. Adding the sender to your contacts, clicking Not Spam on misfiled notifications, and replying to prior notifications all increase your engagement score and pull future messages back to inbox over time.
I have custom code on the form confirmation page. Could that actually break notifications?
Yes, and Squarespace experts consistently cite this as the single most common cause of form notification failure. The form's submit button triggers a JavaScript flow that posts to Squarespace, waits for the confirmation, then displays the confirmation message and triggers Squarespace's server to send the notification email. Custom JavaScript on the confirmation message, or CSS that overrides the success-state selectors, can interrupt this flow. The submission still saves to the panel because that is server-side, but the round-trip handshake the email trigger depends on never completes. Remove any custom code from the confirmation message temporarily and re-test. If the email arrives, the code is the cause.
Will moving my form to Mailchimp or Zapier storage fix the missing notifications?
It can, depending on what is actually broken. Switching the form's Storage tab to Mailchimp or Google Drive or Zapier sends the submission through a different delivery path that bypasses Squarespace's notification email entirely. If the root cause was the [email protected] sender being filtered at your inbox, moving to Mailchimp routes the data to your Mailchimp audience and you can rely on Mailchimp's own delivery and authentication. If the root cause was a Squarespace bounce list block on your address, moving to a different storage provider works around the block. If the root cause is custom code on the confirmation message, switching storage does not help because the submit handshake still fails. Diagnose the cause first, then choose the workaround.
How do I tell if the form-notification problem is on my end or Squarespace's end?
Run two checks. First, submit your form using a recipient address at a different provider than your usual one, such as a personal Gmail when your usual recipient is iCloud, or vice versa. If the second provider receives the notification cleanly while the first does not, the issue is at your inbox provider, not at Squarespace. Second, submit the same form to a brand-new recipient address you have never used before. If the new address receives notifications and your original recipient still does not, your original address is on the Squarespace bounce list. If neither address receives anything, the issue is upstream at Squarespace, almost always custom code on the confirmation page, a misconfigured Storage tab, or a paused account.
Sources and further reading
Every Squarespace-specific claim on this page traces to Squarespace's own Help Center, Squarespace community forum threads, Google's published bulk sender guidelines, and our hands-on repairs.
- Google Workspace Admin: Email sender guidelines FAQ (the February 2024 announcement and the November 2025 enforcement)
- Squarespace Help Center: Troubleshooting form issues
- Squarespace Help Center: Why am I not receiving emails from Squarespace
- Squarespace Help Center: Setting up sender details (note the DMARC p=reject restriction)
- Squarespace Forum: Emails bouncing due to DMARC policy (multi-page community thread)
- Squarespace Help Center: DNS records for email