Communication
Email over SMTP
Every transactional email — verification, password reset, magic links, fee reminders, receipts, absence alerts, exam notices, scheduled reports — sent through your own SMTP provider.
Available, configured at deployment
Schoolyi sends email through standard SMTP rather than through a single vendor SDK. That means the school chooses the provider: Google Workspace, Microsoft 365, Amazon SES, SendGrid, Postmark, or a provider local to your country all work, because all of them speak SMTP.
The practical consequence is deliverability stays yours to control. Mail leaves from your domain, through your provider, under your SPF, DKIM, and DMARC records. Nothing routes through a Schoolyi-owned sending domain, which is what usually causes school email to land in spam.
Email is the backbone of the platform’s outbound communication: account verification and password reset, magic-link sign-in for parents and students, fee reminders and receipts, absence alerts, exam notices, general notices, career applications, and scheduled reports.
How it works
- Standard SMTP over Nodemailer. Host, port, TLS mode, credentials, and the from-address are deployment configuration.
- A built-in email test in Settings sends a live message so a misconfiguration surfaces before go-live rather than when a parent does not receive a receipt.
- Because sending is from your own domain and provider, SPF, DKIM, and DMARC alignment is under your control.
Who configures it
SMTP host, port, TLS mode, username, password, and from-address are deployment environment variables. Settings has an email test page to verify the configuration end to end.
What it does not do
Worth reading before a procurement decision rather than after.
- There is no vendor-specific integration for SendGrid, Resend, or SES. Those providers work through their SMTP interfaces rather than through their APIs, so provider-specific features such as suppression list APIs or event webhooks are not surfaced in Schoolyi.
- Bounce and complaint handling lives in your provider’s dashboard rather than in Schoolyi.
- Deliverability is the school’s responsibility, which is the flip side of it being the school’s control.
Related
Email over SMTP: common questions
Including the questions where the answer is no.
Which email provider should we use?+
Whichever you already run your staff email on, in most cases, since the domain reputation and DNS records are already in place. Schools sending high volumes of fee reminders sometimes add a dedicated transactional provider to keep bulk mail off the staff domain. Both work; the second is more work for a benefit only larger schools notice.
Why not a vendor API instead of SMTP?+
Because SMTP means you are not locked to a provider we chose. A school in a country where the popular transactional vendors are awkward to buy can use a local provider without waiting for us to add an integration.
How do we know it is configured correctly before parents rely on it?+
Settings includes an email test that sends a real message through the configured connection. Run it before go-live, and again after any DNS change. Most email problems in a rollout are SPF or DKIM records rather than the platform.
Everything else
Other integrations, and the ones we do not have
The hub lists what is available and names what is not.
Bring your stack to a walkthrough
Tell us what you already run and which handoffs cost your team time. That is a more useful conversation than a compatibility list.
Already using Schoolyi? Sign in