Every product sends email before it has a marketing team: the sign-up confirmation, the password reset, the order receipt, the "your export is ready" alert. The question founders ask is whether that mail should go through the same email service the team uses, or through a separate sending platform such as Amazon SES, ZeptoMail, Netcore or MSG91. The honest answer is: both, at different volumes. Here is where the line is.
Two ways to send from code
SMTP. Your app connects to a mail server with a username and password over TLS and hands over the message. Every language and framework has an SMTP client built in; Django, Laravel, Rails, Spring and Node's nodemailer all speak it without a library from the provider. Latency is a second or two, which nobody notices for a receipt.
An HTTP API. Your app makes an HTTP call with the recipient, subject and body. APIs are faster per message, easier to retry, and usually come with logs and webhooks for bounces and complaints. They need the provider's client library or a hand-written request.
For a startup app sending a few thousand messages a day, the difference is convenience, not deliverability. Deliverability comes from the domain's SPF, DKIM and DMARC records and from the reputation of what you send, not from the protocol.
Sending from your own email service
If the team's email is on a service that includes authenticated SMTP, the simplest setup is a dedicated mailbox, noreply@yourdomain.in or alerts@, whose credentials live in your app's secrets and nowhere else. Mail from it is signed with the same DKIM key as the founders' mail, passes the same SPF, and bounces land in a mailbox someone can read. There is no second vendor, no second invoice, and no second set of DNS records to get wrong.
On XgenPlus that is what every plan includes: SMTP over TLS from any mailbox, and a SOAP API with a messaging service whose sendMAIL method sends text or HTML mail with CC and BCC, SendMailWithAttachment adds a file, and sendSMS sends a text message where SMS is enabled. Calls authenticate with a per-user key from getSoapAuthKey. The documentation with a sample client is in the document hub.
Where the line is
Team email services are built for mail between people. They rate-limit sending per mailbox to stop a compromised account from spamming, and that limit is the practical ceiling for app sending through them. As a rule of thumb:
| What the app sends | Typical volume | Send it through |
|---|---|---|
| Sign-up confirmation, password reset, invoice, alert | Hundreds to a few thousand a day | Your own email service, from noreply@ |
| OTP for login at scale | Tens of thousands an hour at peaks | A sending platform, and SMS or WhatsApp OTP where the user expects it |
| Newsletter, product announcement, drip campaign | Everyone on the list at once | A campaign platform, always on a subdomain |
| Mail your product sends on behalf of your own customers | Unbounded | A sending platform with per-customer domains and complaint handling |
Why campaigns go on a subdomain
Gmail and Outlook keep a reputation per sending domain. One bad campaign, one purchased list, one complaint rate over Gmail's 0.3 percent threshold, and mail from your founders starts landing in spam too. Put campaign mail on mail.yourdomain.in or news.yourdomain.in with its own SPF, DKIM and DMARC, and the damage stays there. This is true whichever platform you use.
What a sending platform costs in India
Amazon SES in the Mumbai region is priced around $0.10 per thousand messages and needs an engineer who is comfortable with AWS. ZeptoMail from Zoho sells credits from about $2.50 per ten thousand with support included and Indian hosting. Netcore's email API and MSG91 are Indian companies with rupee invoices; MSG91 is the usual choice when OTP goes by SMS as well. All of them bill in dollars or rupees per message, and all of them expect you to run the subdomain's DNS and warm up the sending volume.
What we tell startups
Start on your own email service from a noreply@ mailbox. It is the setup that takes an hour and needs no second vendor, and it is right for most products until well past the first thousand customers. When the volume table above says you have crossed the line, add a sending platform on a subdomain for that traffic and keep the team's mail where it is. If you are on XgenPlus, the Startup Desk will look at your expected volume and tell you which side of the line you are on before you build anything.
