Purpose-built infrastructure for the email your product depends on: one-time passwords, password resets, order confirmations and system alerts. Priority queuing so system mail never waits behind a campaign, dedicated IPs, and India-hosted delivery. Plans from ₹528/month with GST invoices.
Transactional emails are triggered by something an individual user did, rather than scheduled by a marketer. Each goes to one person, is expected within seconds, and forms part of a transaction that person initiated.
The common types, and what each one tolerates:
What unites them is that nobody signed up for them and nobody wants to receive them twice. They are infrastructure, not communication.
The last row explains why transactional problems get discovered late. A campaign that underperforms shows up in a dashboard; an OTP that doesn't arrive shows up as a user who gave up and never told you.
When OTPs are slow or landing in spam, the cause is almost always one of four things.
Shared reputation with marketing. This is the most common and the least suspected. If campaigns and OTPs send from the same domain and IP pool, a poorly targeted promotional blast that generates complaints degrades the reputation delivering your login codes. Nobody marks an OTP as spam; they inherit the damage anyway. Few teams connect Tuesday's campaign to Thursday's login failures.
Queueing behind bulk. On infrastructure that treats all mail equally, an OTP submitted thirty seconds after a 200,000-recipient campaign waits behind it. neuMails prioritises transactional traffic in the delivery queue for exactly this reason.
Authentication gaps. Missing or misaligned SPF, DKIM and DMARC records mean mailbox providers cannot verify you. Gmail and Yahoo now require all three, and the failure mode is rejection rather than a spam-folder placement you might notice.
Overseas routing. Mail sent through infrastructure in Virginia or Dublin to a recipient in Mumbai makes a round trip of thousands of kilometres before the delivery conversation even begins. For a newsletter that's invisible; for someone waiting on a checkout screen it isn't.
The fixes are structural: separate sending domains and IP pools, priority queueing, verified authentication, and infrastructure close to your recipients.
The single most valuable configuration decision for transactional email is one most teams skip.
Use a subdomain reserved for system mail — mail.yourdomain.com — and a different one for campaigns, such as news.yourdomain.com. Each gets its own DKIM key, its own IP allocation and its own reputation with every mailbox provider.
Two benefits follow. Marketing behaviour can no longer affect transactional delivery, which removes the failure mode above entirely. And when something does go wrong, the diagnosis is immediate, because the two streams are measured separately rather than as one blended number.
You can run both from a single neuMails account. See bulk email for the campaign side.
Both are available on the same account, and neither is universally better.
SMTP relay suits an existing application that already sends mail. Change host, port and credentials — ports 587, 465 or 2525 — and everything continues working. A configuration change, not a code change.
The REST API suits new services and anything where you want more control. One round trip instead of five, immediate accept or reject in the response, richer per-message metadata, and a natural fit for serverless environments where holding SMTP connections is awkward.
One API feature matters specifically for OTPs: idempotent requests. If a response is lost to a network timeout and your retry logic fires, a naive integration sends the code twice — and if only one is valid, roughly half of affected users enter the wrong one. Submitting a unique request ID per logical send means a repeat returns the original result instead of sending again.
Background on the trade-off in What Is an Email API?
Transactional email fails quietly. The user doesn't email you to say the code never came — they try again, then leave.
Alert on delivery rate, not just on send errors. An application that only logs API failures believes every accepted message reached someone.
Transactional messages form part of a transaction the user initiated, so they are not marketing communications requiring separate opt-in. An OTP does not need the consent record a campaign does, and does not require a one-click unsubscribe header.
That said, you remain the Data Fiduciary for the personal data involved. Lawful basis, retention limits, security safeguards and the ability to answer a data principal's access or erasure request all still apply.
One boundary worth respecting: attaching promotional content to a transactional message changes its character. A receipt with a discount banner is arguably a marketing communication, and treating it as transactional to avoid consent requirements is a route to complaints on your most reputation-sensitive stream.
Message data, delivery logs and recipient records are stored and processed on AWS Mumbai (ap-south-1). See DPDP compliance, or on-premise deployment where data must remain inside your own network.
Worth asking before you commit:
Comparisons: vs SendGrid · vs Mailgun · best platforms in India.
Plans from ₹528/month. Free trial, no credit card required.
Start Free TrialEmail triggered by an individual user's action rather than scheduled by a marketer. OTPs, password resets, order confirmations, shipping notifications, invoices and system alerts. Each goes to one recipient, is expected within seconds, and forms part of a transaction the user initiated.
Marketing is one message to many, scheduled by you, requiring explicit consent and one-click unsubscribe. Transactional is one message to one recipient, triggered by their action, expected immediately. Critically, they should never share a sending domain or IP pool.
Usually one of four causes: shared reputation with marketing campaigns, missing or misaligned SPF/DKIM/DMARC, queueing behind bulk sends on the same infrastructure, or overseas routing adding a round trip before delivery begins. Shared IP pools where another sender's behaviour affects yours are also common.
They form part of a transaction the user initiated, so they aren't marketing communications requiring separate opt-in. You remain the Data Fiduciary and still need lawful basis, retention limits and security safeguards — but an OTP doesn't require the marketing consent record a campaign does.
Either. SMTP relay when an existing application already sends mail and you only need a configuration change. The REST API when you want immediate accept or reject feedback in one round trip, idempotent requests to prevent duplicate OTPs, and richer per-message metadata.
For OTPs and other time-critical mail, yes. On a shared IP your delivery reflects the aggregate behaviour of every sender in that pool, which makes reliability unpredictable exactly where predictability matters most.
A subdomain reserved for system mail, such as mail.yourdomain.com, kept separate from the one used for campaigns. This isolates reputation so a promotional send cannot affect your login codes, and makes diagnosis considerably easier.
Yes. Message data, delivery logs and recipient records are stored and processed on AWS Mumbai (ap-south-1). Where data must remain inside your own network, the platform can be deployed on-premise.