Connect an email provider so sign-in, notifications, and digests actually reach members, and authenticate your domain so they land in the inbox.
Loading the guide...
Help us make the guides more useful.
0 helpful · 0 not helpful
Seedly Communities sends a lot of email. Sign-up verifications, password resets, event reminders, payment notices, and the daily and weekly digests all go out through an email provider you connect with your own account. If email is not set up, the community still runs, but the moments that depend on a message arriving quietly break. This page connects a provider and gets your mail into the inbox rather than the spam folder.
A membership community sends far more mail than a personal inbox is built for, and it needs it to arrive reliably. A regular Gmail or Outlook account gets rate-limited and flagged as spam almost immediately. An email provider is a service built specifically for this kind of high-trust transactional mail. Seedly Communities works with SendGrid or Postmark. Pick one. Either is a solid choice, and you can start on a free tier.
Email is not a side feature here. It carries the parts of the experience that have to reach a person.
Create an account with SendGrid or Postmark, then tell the platform which one you chose and give it the key. Email runs on the backend, so these values go on your Convex deployments with the environment command.
If you chose Postmark, set EMAIL_PROVIDER to postmark and set POSTMARK_SERVER_TOKEN instead. All the setting names are on the Environment and Configuration page.
Unlike Stripe, email has no separate test and live modes, so the same key is fine on development and production. If you prefer, create a separate key per environment.
Every message goes out from one address that you own on your own domain. Set it on both backends.
This address must be a verified sender at your provider, which is the next step. If the From address is unset, the platform fails closed. It will not send from a bogus address, which means verification and password-reset emails silently do not go out. That is the single most common reason a fresh install seems to swallow sign-ups, so set this early.
Getting mail delivered is mostly about proving to inbox providers that you are really you. Your provider walks you through domain authentication, and it comes down to three DNS records you add at your domain registrar. You do not need to understand the cryptography to set them up correctly.
Your provider generates the exact record values for your domain. Add them at your registrar (the same DNS page where you point your domain at the app), then click Verify in the provider dashboard. DNS can take a few minutes to propagate. Once it verifies, your From address is a trusted sender and your mail stops landing in spam.
Set up all three. SPF and DKIM alone will deliver, but a published DMARC policy is what modern inbox providers increasingly expect from bulk senders, and it protects your domain from being spoofed.
The honest test is a full round trip. Create a new account in your development environment with an address you can actually check, and confirm the verification email arrives in the inbox rather than spam. Then trigger a password reset and confirm that lands too. If both arrive cleanly, your notifications and digests will as well.
The most placement-sensitive messages are the ones a member is waiting on, like a verification link or a password reset. If you want to protect those specifically, you can route them through a second provider or a dedicated sending stream, kept separate from bulk notification traffic. This is optional and off by default. The dedicated-stream setting names are listed on the Environment and Configuration page.
| Symptom | Likely cause |
|---|---|
| New members never get a verification email | EMAIL_FROM is unset, or the provider key is missing |
| Mail sends but lands in spam | Domain authentication is incomplete. Recheck SPF, DKIM, and DMARC at your registrar |
| Password resets do not arrive | Same as verification. The auth stream is not sending |
| Some members get no digests | Those members turned digests off in their notification preferences, which is expected |
| Provider reports a bounce or complaint | A bad or hostile address. Your email provider suppresses addresses that bounce or complain on its side, which protects your sending reputation |