Tally and NotionForms have quietly become the default form builders for a big slice of the Notion-adjacent world: community projects, startup landing pages, internal intakes. Both are generous on the free tier, both work with Notion databases, both handle form-submission email notifications internally. The last part is where things get foggy.
Neither platform exposes the sending headers, the envelope domain, or the reputation pool. They just say "notification sent" in a log somewhere. Whether that notification actually arrived in your team's inbox is a black box — until you seed test.
Both platforms send from their own mail infrastructure on shared pools. Use a seed test to measure placement across major providers. If it's mixed, switch to Zapier/Make/native webhook routing into your own ESP.
How Tally sends notifications
- Email notification from a Tally-owned envelope.
- Reply-To can be set to a submitter field or a team address.
- No DKIM on your domain, no custom Return-Path.
- Shared reputation across all Tally users.
On the paid Pro plan Tally offers integrations — Slack, Zapier, Make, webhook, CRM push — that bypass the email notification entirely. That's the part you want to lean on for anything important.
How NotionForms sends notifications
- Email notification from a NotionForms-owned envelope.
- Direct write to a Notion database regardless of email notification success.
- Email notification also via Zapier, Make, or webhook on paid plans.
The Notion database row is the source of truth. Even if email notification fails, the data is still in Notion. That makes NotionForms slightly more forgiving than Tally's email-primary flow.
Neither Tally nor NotionForms exposes the full email headers in their notification logs. The only way to know the envelope, SPF result, and DKIM result is to receive the mail on a seed address you control and view the "Original message" in Gmail or "View source" in Outlook.
Seed test both platforms
- Add 15–20 seed recipients across major providers in the form config.
- Gmail, Google Workspace, Outlook.com, Microsoft 365, Yahoo, Mail.ru, Yandex, ProtonMail, GMX, Fastmail.
- Submit three realistic test entries from incognito.
- Log placement per provider.
- In Gmail, open one and View Original — capture the From, Return-Path, DKIM Signature and Authentication-Results header.
Webhook path to your own ESP
Both platforms support webhooks on paid plans. The standard escape hatch:
Tally or NotionForms submission
--> webhook POST
--> Zapier / Make / serverless fn
--> Resend / Postmark API
from: notifications@yourdomain.com (DKIM-signed)
to: team@yourdomain.com
reply-to: {{ submitter_email }}
subject: New submission from {{ name }}
--> Inbox at your teamOnce that's wired up, turn off the native email notification in the form settings. Keep both on for the first 48 hours while you validate the webhook path — then cut over.
When to prefer which
- Tally: cleaner form UX, better for public-facing forms. Rely on Slack webhook or Zapier for notifications, not native email.
- NotionForms: better if you're already running ops in Notion. The Notion database row gives you a built-in fallback if email fails.
- Neither: if notification email latency matters (e.g. live support intake), go with a hosted form + your own backend. Form builders add 2–10s of latency at the best of times.
Decide for your use case
- Seed shows Inbox everywhere: keep native notification, re-test monthly.
- Seed is mixed: switch to webhook → ESP. 20 minutes of setup.
- Seed is bad and you're on free tier: either upgrade to paid to unlock webhooks, or use Slack/Discord webhook as the primary channel.