Forward Form Submissions to Multiple Email Addresses

Why one inbox isn't enough

Most form-to-email setups start the same way: a single contact form, a single inbox, one person watching it. Then the business grows and that single recipient becomes a bottleneck. Submissions sit overnight because the owner is asleep. Sales leads get answered three days late because the only person who saw the email was on holiday. A VA needs to triage but doesn't have access. This is the moment everyone reaches for multi-recipient routing — and most people pick the wrong tool for the job.

Here's the actual reason multi-recipient delivery matters: redundancy and routing. You want every submission to reach at least one person who will act on it, and you want some submissions to reach specific people (sales vs. support). Those are two different problems with two different solutions, and most blog posts conflate them.

Common real-world cases:

• Team inboxes. Sales@ and support@ should both see every lead from the contact form.
• Owner + VA visibility. The founder wants to see every inquiry; the VA does the actual response.
• Multi-location businesses. Each city manager gets only their own city's leads, but HQ sees all of them.
• Compliance archive. A silent archive address holds a copy for record-keeping.

The rest of this guide walks through the four approaches that actually work in 2026, what they cost in deliverability, and which one we recommend for each case.

Approach 1: Multi-recipient at the source (splitforms Notify field)

This is the simplest and the only approach that preserves deliverability cleanly. Instead of forwarding from one inbox to others after the fact, you tell the form backend to deliver to multiple addresses in the original send. There's only ever one email envelope and one SPF check, so receiving servers never see a forwarded message.

In splitforms, the setup is one field in the dashboard:

1. Open splitforms.com/login and pick the form you want to configure.
2. Click Settings on the form's detail page.
3. Find the Notify field. Paste a comma-separated list of email addresses.
4. Save. The change is live within seconds; no redeploy needed.

# In the Notify field, paste:
sales@yourco.com, support@yourco.com, owner@yourco.com, archive@yourco.com

Every future submission delivers to each address as a real To: recipient — they all see each other in the email header, replies fan out naturally with Reply-All, and per-recipient delivery is logged in the dashboard so you know exactly who got it. Your form HTML doesn't change at all:

<form action="https://splitforms.com/api/submit" method="POST">
  <input type="hidden" name="access_key" value="YOUR_ACCESS_KEY" />
  <input type="text"  name="name"    required />
  <input type="email" name="email"   required />
  <textarea           name="message" required></textarea>
  <input type="checkbox" name="botcheck" style="display:none" tabindex="-1" />
  <button type="submit">Send</button>
</form>

The free tier (1,000 submissions/month, raised in May 2026) includes multi-recipient delivery at no extra cost. If you're coming from another tool, this is one of the most common reasons to migrate from Formspree — Formspree puts CC on a paid plan.

Approach 2: Distribution list or Google Group

A distribution list (Google Groups, Microsoft 365 group, ProtonMail alias) gives you one address that expands to many on the receiving side. You set team@yourco.com as the form's only Notify address; the group fans it out to whoever you've added as members.

This is the right approach when membership changes frequently. New hire joins the sales team? Add them to the group. Someone leaves? Remove them. The form configuration never changes. The drawbacks:

• One To: address, not many. Every recipient sees only team@yourco.com in the To: header, not their teammates. Replies feel anonymous unless you train people to Reply-All.
• Per-recipient delivery is opaque. The form backend sees one successful delivery. If three out of five members' mailboxes silently dropped it (Gmail's "Less Important" bucket, an overzealous filter), you won't know.
• Groups can be spammy targets. Public group addresses get scraped and abused; some receivers downscore mail to large groups.

Setup is platform-specific. For Google Workspace:

1. Go to admin.google.com → Groups → Create group.
2. Set the group's email to something like contact-form@yourco.com.
3. Add members (yourself, sales, support, VA, archive).
4. Set Who can post to Anyone on the web so external form-backend emails aren't bounced.
5. In splitforms, set the Notify field to just contact-form@yourco.com.

Verdict: use it when you genuinely don't want to touch the form to change recipients. For most teams under ten people, individual addresses in the Notify field are clearer.

Approach 3: CC/BCC in email rules (Gmail filters, Outlook rules)

This is the approach you should avoid. The instinct is reasonable: keep the form pointed at one inbox, then use Gmail filters or Outlook rules to auto-forward a copy to teammates. It looks elegant. It also tanks your deliverability.

Here's the actual mechanic. When Gmail auto-forwards a message, it rewrites the envelope sender (Return-Path) but keeps the original From: address — usually the visitor's email. The receiving server sees an email claiming to be from visitor@gmail.com arriving from a Google relay. SPF for gmail.com doesn't authorize Google to send on behalf of arbitrary senders, so the SPF check fails. DKIM may also break because the body was lightly mutated. DMARC then trips. The result: spam folder for the forwarded copy, sometimes for the original too, depending on how aggressive the downstream filter is.

If you absolutely must do this (legacy setup, can't change the form config), Gmail's filter UI is:

1. Gmail → Settings → Filters and Blocked Addresses → Create new filter.
2. Filter for messages with a unique header your form adds (e.g. from:notify@splitforms.com).
3. Action: Forward it to and pick the destination address. (You have to verify the destination first under Forwarding and POP/IMAP.)

Outlook rules work similarly but suffer from the same SPF/DKIM/DMARC breakage. The only auto-forward that doesn't break alignment is Microsoft 365's SMTP redirect (which preserves headers) inside the same tenant — and even that gets flagged when forwarding outside the tenant.

Verdict: this approach turns a clean form-to-email pipeline into a deliverability puzzle. Use it only as a temporary patch while you migrate the routing to the form backend.

Approach 4: Conditional routing via webhook

This is the right tool for "different submissions go to different teams." A flat multi-recipient Notify field sends every submission to everyone; a webhook lets you inspect each submission and route based on its content.

The pattern: splitforms posts every submission to a webhook endpoint you control. Your endpoint reads the payload, decides who should get it, and either sends the email itself via your SMTP provider or calls splitforms' API to deliver a notification. Webhooks are free on the splitforms free tier.

// Node.js / Next.js route — /api/route-form
export async function POST(req) {
  const submission = await req.json();
  const { fields } = submission;

  // Decide based on a dropdown field named "inquiry_type"
  let recipients = ["owner@yourco.com"]; // fallback
  if (fields.inquiry_type === "sales")    recipients = ["sales@yourco.com"];
  if (fields.inquiry_type === "support")  recipients = ["support@yourco.com"];
  if (fields.inquiry_type === "billing")  recipients = ["billing@yourco.com", "owner@yourco.com"];

  // Geographic routing
  if (fields.country === "DE") recipients.push("de-lead@yourco.com");

  // Fire the email via your SMTP
  await sendMail({
    to: recipients,
    subject: `New ${fields.inquiry_type} inquiry from ${fields.name}`,
    html: renderTemplate(fields),
    replyTo: fields.email,
  });

  return new Response("ok");
}

The full webhook envelope, including the signed X-Splitforms-Signature header you should verify before trusting any field, is documented at /api-reference. Common routing keys:

• Dropdown / radio selection — "What can we help with?" → sales / support / partnerships.
• UTM parameters or referrer — leads from a paid campaign go to a sales SDR, organic to a generalist.
• Visitor country from IP geolocation — route to the regional team.
• Keyword scan of the message body — "refund" routes to billing, "integrate" routes to support.

This approach scales to any complexity you need. The cost is that you're now running code; if the webhook receiver goes down, leads can be lost. Always log the raw submission to a database or to splitforms' built-in dashboard so you can replay routing later.

Side-by-side comparison

Each approach has a different tradeoff between simplicity, deliverability, and flexibility.

The recommended default is approach 1 — multi-To: at the form backend. Layer approach 4 on top of it only when you actually need conditional routing.

Deliverability: what actually breaks when you forward

If you only remember one thing from this guide, remember this: every hop after the initial send is a chance to fail SPF, DKIM, or DMARC. Multi-recipient delivery at the source is one hop. Auto-forwarding is two hops. Auto-forwarding through three Gmail rules to four destinations is five hops, each of which can corrupt headers.

The 2026 landscape after Google and Yahoo's 2024 bulk sender rules tightened further:

• DMARC reject is now the default for high-volume senders. Your form notification that auto-forwards from Gmail will be silently dropped at the next hop, not bounced.
• Forwarding rewrites by ARC (Authenticated Received Chain) help slightly, but ARC sealing is inconsistent across providers. Don't bet your leads on it.
• BIMI only works for messages that pass DMARC; auto-forwarded copies lose their brand indicator.

The fix in one sentence: configure recipients at the form backend, not at the inbox layer. For the full deliverability checklist (SPF records, DKIM keys, custom SMTP, return-path domains), see contact form not working and the deliverability section of /docs.

How splitforms handles routing rules

The dashboard exposes three layers of routing, applied in this order:

1. Notify list — comma-separated To: addresses that get every submission. This is the everyone-sees-everything floor.
2. Per-form Reply-To override — set a fixed Reply-To address (a shared inbox or group) so team replies fan out instead of going only to the visitor.
3. Webhooks — for any logic the Notify list can't express. Webhooks fire in parallel with the email send, so adding one doesn't delay delivery.

You can mix all three. A typical small-team setup: Notify = founder + VA, Reply-To = team@yourco.com (a Google Group), webhook = posts a summary into Slack. The visitor sees the form succeed in under a second; the founder and VA get the email; the team Slack channel gets a one-line ping. No code on the website, no inbox rules, no SPF risk.

Plan limits as of 2026-05: free tier 1,000 submissions/month with unlimited recipients per form, Pro at $5/month covers 5,000 submissions, and the $59 4-year plan is the cheapest long-haul option. Webhooks are free across all tiers, which matters because the "split the routing into webhooks" pattern is paywalled on most competitors. For the full plan comparison, see splitforms vs Formspree.

Troubleshooting

• Only one person on the team received the email. Check the Notify field for typos and the dashboard's per-recipient delivery log. If the log shows delivery to all addresses but one recipient still has nothing, check that recipient's spam folder and any client-side filters they've set up (Gmail "Less Important" and category tabs are the usual culprits).
• Replies go to the visitor instead of the team. The default Reply-To is the visitor's email so you can reply directly. To fan replies to the team, set a per-form Reply-To override in the dashboard (a shared inbox or group), or train your team to use Reply-All.
• One address bounces every time. The bounce shows in the delivery log with the SMTP response. Most common causes: typo, mailbox over quota, the receiving server has a strict spam policy. Remove the address or fix the typo.
• Submissions land in spam for some recipients but not others. Different ISPs make different decisions. Switching to a custom SMTP setup (Gmail App Password, SES, Postmark) with proper SPF/DKIM on your domain is the single biggest fix.
• You changed the Notify list but emails still go to the old address. Hard refresh the dashboard; check you saved the form (not just typed in the field). Changes apply to new submissions only — anything in the queue from the last few seconds uses the old config.
• Webhook fires but no email is sent. Webhook and email delivery are independent paths. The email going missing means it's a Notify-list problem, not a webhook problem — check the delivery log. The webhook firing successfully means your routing endpoint is healthy.

If you're still stuck, /faq covers the long tail and /docs has the request/response shapes for every endpoint. Framework-specific patterns are at /forms/nextjs and /forms/react.

Next steps

• Grab an access key at splitforms.com/login and paste your team's addresses into the Notify field. The whole change is one minute.
• If you're still on a tool that paywalls CC/BCC, the Formspree migration guide covers the cut-over end to end.
• If you need conditional routing, sketch the rules first, then implement the webhook. The API reference documents the signed envelope.
• If you're still picking a backend, the best free form backends roundup compares the multi-recipient handling of every major option.
• Need a ready-made form? Grab a free contact form template pre-wired to splitforms, then add your Notify list.
• Browse more guides on the blog.

FAQ