Point your application at neuMails, swap three settings, and start sending. You get all the power of a fully managed SMTP server — dedicated IPs, TLS, automatic warm-up, bounce handling — with none of the maintenance of running one. Hosted on AWS Mumbai, billed in INR, backed by IST-hours support.
An SMTP relay is a service that accepts email from your application, website or business tool and delivers it to your recipients' inboxes on your behalf. Instead of your server talking directly to Gmail, Outlook or Yahoo — and being judged by them as an unknown sender — your mail routes through the relay's established, trusted infrastructure. The relay handles authentication, encryption, queuing, retries, bounce processing and IP reputation, so your emails arrive reliably even at high volume.
Think of it as the postal sorting office for your application's email. Your app drops the message off with valid credentials; the relay takes responsibility for getting it delivered, retrying temporary failures, suppressing dead addresses and keeping the sending IPs in good standing with every mailbox provider.
In practice, connecting to an SMTP relay means changing three values in your application's mail settings:
Host: smtp.neumails.com
Port: 587 (STARTTLS — recommended)
465 (implicit SSL/TLS)
2525 (STARTTLS — use when 587 is blocked)
Auth: Your neuMails SMTP username and password
That's the entire migration. No code rewrite, no new libraries — SMTP has been the universal language of email since 1982, and every application that can send mail speaks it.
The two terms get used interchangeably, but there's a real distinction — and understanding it explains why most businesses shouldn't run their own.
An SMTP server is the actual software that speaks the Simple Mail Transfer Protocol — accepting connections, authenticating senders, queuing messages and negotiating delivery with receiving mail servers. Postfix, Exim, Sendmail and Haraka are all SMTP servers. If you install one on a VPS, you own an SMTP server.
An SMTP relay is an SMTP server operated as a service — one you connect to rather than one you maintain. When you use neuMails, you're using enterprise-grade SMTP server infrastructure (high-throughput MTAs, dedicated IP pools, redundant nodes across availability zones) delivered through a single hostname and a set of credentials.
Running your own SMTP server made sense when the alternative didn't exist. Today, mailbox providers judge unknown IPs harshly, port 25 is blocked by most cloud providers by default, and a single misconfiguration can land your domain on a blocklist for weeks. A relay gives you the server without the liability.
The result: your application code stays exactly as it is, and everything after "send" gets dramatically more reliable.
Because SMTP is a universal standard, neuMails works as a drop-in relay for any system that sends mail:
If your tool has fields for SMTP host, port, username and password, it works with neuMails. Prefer an API? The same account also includes our REST Email API — use both interchangeably.
Every developer's first instinct is a free SMTP option — Gmail's SMTP server, a free tier from a global provider, or the SMTP service bundled with web hosting. All three work for testing. All three fail predictably in production:
Gmail / personal mailbox SMTP. Capped at roughly 500 recipients a day, with no dedicated IP, no bounce processing, no sending logs, and hard suspensions when Google's automated systems decide your OTPs look like bulk mail. Your "From" address is also tied to the mailbox, which breaks DMARC alignment for your business domain.
Free tiers of global relays. You send from shared IP pools alongside thousands of unknown senders. One spammer in the pool and your transactional email inherits their reputation. Daily caps (typically 100–300 emails) make them unusable beyond a prototype, support is community-forum-only, and billing is in USD the moment you outgrow the cap.
Web-hosting SMTP. Shared hosting mail servers are the most abused IP space on the internet. Deliverability to Gmail and Microsoft is effectively random, and your host can suspend mail on your account for volume spikes you consider normal.
What paid gets you — and why serious senders never look back:
neuMails plans start at ₹528/month — less than the engineering hour you'd spend each week nursing a free relay's problems.
On a shared IP, your deliverability is the average behaviour of everyone on that IP. On a dedicated IP, mailbox providers evaluate you and only you.
Every paying neuMails customer sends from dedicated IPs drawn from our own IP ranges — address space we own and control end to end, with matching forward and reverse DNS, correct PTR records, and full SPF/DKIM/DMARC alignment for your domain. That means:
Shared pools are fine for the first hundred emails. Dedicated IPs are how you make the next ten million predictable.
A brand-new IP has no history, and mailbox providers treat no history as suspicion. Blast 50,000 emails from a cold IP on day one and Gmail will throttle you, Microsoft will defer you with 451 errors, and Yahoo may block you outright — regardless of how legitimate your mail is.
IP warm-up is the process of ramping volume gradually so providers can observe consistent, well-received sending and extend trust. Done manually, it's a spreadsheet-driven grind of daily caps, per-provider quotas and constant log-watching over three to four weeks.
neuMails does it for you, automatically:
You send normally from day one; we make sure the infrastructure earns trust underneath you.
Two limits govern how fast mail actually moves, and they are not the same thing.
Your connection to us is the easy one. neuMails accepts multiple concurrent SMTP connections per account, with pipelining supported, so a queue worker pool can submit in parallel rather than serialising. For most applications this is never the bottleneck.
Our connection to the recipient is where the real constraint lives — and it isn't ours to set. Gmail, Microsoft and Yahoo each impose their own per-IP connection and volume ceilings, and those ceilings move based on your reputation. A well-warmed IP with clean engagement gets far more headroom than a new one.
This is why raw "emails per hour" figures are close to meaningless when comparing providers. What determines your real throughput is whether the delivery engine responds correctly when a provider pushes back: a 421 or 451 deferral means slow down, and hammering through it costs reputation that takes weeks to rebuild. Our engines back off per-provider and per-IP automatically, re-queue with exponential delay, and surface the deferral in your logs so you can see it happened.
Practical implications for planning:
Inbox vs spam folder isn't decided by your subject line. It's decided by sender reputation — the score Gmail, Microsoft, Yahoo and every other provider maintains on your IPs and your domain, built from bounce rates, spam complaints, spam-trap hits, engagement, authentication and volume consistency.
neuMails defends that score on every layer:
And because our infrastructure sits on AWS Mumbai, latency to Indian mailbox providers and Indian recipients of Gmail/Outlook is the lowest you can get — OTPs in seconds, not minutes.
Global relays treat India as an afterthought: USD billing, no GST invoice, support that wakes up when your business day ends. neuMails is the inverse:
See how we stack up: vs SendGrid · vs Mailgun · vs Brevo
Search for a bulk SMTP server or an SMTP service provider in India and you'll find three very different things sold under the same name. Knowing which you're being offered matters more than the price.
Resold shared SMTP. The cheapest listings — often a few hundred rupees a month — are reseller accounts on someone else's shared infrastructure. You get a hostname and credentials, but no dedicated IP, no control over who else sends from that IP, and typically no logs. Fine for low-stakes mail; unpredictable for OTPs.
Self-managed VPS with an MTA. You rent a server, install Postfix or PowerMTA, and own everything — including PTR records, blocklist monitoring, warm-up scheduling and the 2am page when Microsoft starts deferring. Viable if you have a deliverability engineer. Expensive if you don't.
Managed relay with dedicated IPs. Infrastructure someone else runs, IPs allocated to you alone, warm-up automated, bounces and complaints handled. This is what neuMails provides.
Questions worth asking any provider before you commit:
A dedicated SMTP server in the sense that matters — your own IP, your own reputation, your own logs — doesn't require you to operate one. That's precisely the distinction between running a server and using a relay.
Your existing sending code doesn't change. Your deliverability does.
Free trial with full SMTP access. Keep your existing sending code.
Start Free TrialAn SMTP relay delivers email sent by applications and business systems — OTPs, order confirmations, password resets, invoices, alerts and campaigns — through trusted infrastructure instead of your own server. It's used whenever software, rather than a person in a mail client, needs to send email reliably.
Functionally related, operationally different. An SMTP server is the software that transmits mail; an SMTP relay is that server run as a managed cloud service. With neuMails you get full SMTP server capability — dedicated IPs, queuing, TLS, DKIM signing — without installing or maintaining anything.
Port 587 with STARTTLS (recommended), port 465 with implicit SSL/TLS, and port 2525 with STARTTLS as a fallback. All require authentication over an encrypted connection. We don't accept unauthenticated relay on any port — that's what keeps our IPs, and therefore your deliverability, clean.
Use port 2525 with STARTTLS. Some cloud providers and corporate firewalls block 587 and 465 outbound to limit spam, and 2525 is the widely adopted alternative. It carries the same encryption and authentication requirements as 587. Port 25 is not offered for authenticated submission.
Ask whether the IP is genuinely dedicated and whose range it sits in, where the infrastructure is hosted, whether hard bounces are automatically suppressed before the next send, whether per-message logs are available, whether billing is in INR with a GST invoice, and what the support hours are. Cheap listings are often reseller accounts on shared IPs with no logs and no bounce handling.
For testing, yes. For production, free relays impose daily caps, shared IPs whose reputation you can't control, and no bounce handling — which means unpredictable inbox placement precisely when email matters most. Paid relay from ₹528/month removes all three constraints.
Yes. neuMails customers send from dedicated IPs in our own IP ranges, with correct PTR records and full authentication alignment. Your sending reputation belongs to you alone and is never affected by other senders.
Typically two to four weeks to reach full volume, depending on your sending patterns and recipient mix. neuMails automates the entire ramp — schedules, per-provider throttles and back-off on deferrals — so you don't manage it manually. You can send from day one; volume scales as trust builds.
Throughput is governed less by our infrastructure than by each mailbox provider's per-IP ceilings, which rise as your reputation improves. Raw emails-per-hour figures are therefore misleading when comparing providers. What matters is correct back-off on 421 and 451 deferrals, which our delivery engines handle automatically per provider and per IP.
No. Update three settings — SMTP host, port and credentials — in your application or plugin. Everything that already sends via SMTP (WordPress, MailWizz, Odoo, PHPMailer, Nodemailer, legacy ERPs) continues to work unchanged.
Yes, on the same account interchangeably. Use SMTP for tools and legacy systems, and the REST Email API for modern application integrations with the richest event data. Logs, suppression and analytics are unified across both.
Automatically. Hard bounces and complaints are added to your suppression list in real time and blocked from all future sends. This keeps your bounce and complaint rates inside the thresholds Gmail, Microsoft and Yahoo enforce — the single biggest factor in long-term deliverability.
Yes. All neuMails infrastructure runs in AWS Mumbai (ap-south-1). Message data, logs and subscriber data stay within India, which simplifies DPDP Act 2023 compliance and data-residency requirements for BFSI and regulated industries.
From a few hundred transactional emails a day to millions per month. Throughput scales with your plan and IP allocation; high-volume senders get additional dedicated IPs with automated warm-up for each.
Yes. Every message generates delivery, bounce, deferral, open and click events, visible in Email Logs and Email Analytics, exportable as CSV, and pushable to your systems via webhooks with automatic retry.