Campaign management, transactional sending, SMTP relay, APIs and analytics — the complete neuMails platform, deployed inside your own data centre. Subscriber data never leaves your environment. Fully white-labelled, so your customers see your brand and nobody else's.
The term gets stretched to cover several very different arrangements, and the differences matter enormously if you're buying against a compliance requirement.
SaaS with a dedicated IP is still SaaS. Your sending reputation is isolated from other customers, which is valuable, but the application, the database and every subscriber record still sit in the vendor's cloud. If your requirement is "personal data must not leave our infrastructure," a dedicated IP does not satisfy it — and buying one because a salesperson framed it as "dedicated" is a common and expensive misunderstanding.
Self-hosted software means you buy a licence, download an installer, and become responsible for everything: deployment, MTA configuration, IP reputation, blocklist monitoring, upgrades, and the 2am incident when Microsoft starts deferring. Several vendors sell this. It works well if you employ someone who understands deliverability. It works badly if you don't, and the failure mode is silent — mail that quietly stops reaching inboxes.
Managed on-premise is the middle path, and it's what neuMails provides. The platform runs on infrastructure you own and control, inside your network boundary. Data residency is absolute. But deployment, tuning, MTA configuration, warm-up strategy and ongoing deliverability engineering come from a team that does this daily.
You get the control of self-hosting without inheriting a discipline your organisation may not want to build in-house.
For most businesses, SaaS email is the right answer, and we'll say so. On-premise earns its complexity in three situations.
Organisations with data residency mandates. Banks, insurers, NBFCs, healthcare providers, government bodies and their vendors — anywhere "where does subscriber data physically sit" has to be answered with a server, not a region dropdown. When an auditor asks who else can access the database, "nobody outside this building" is a materially different answer from "our vendor's access controls."
High-volume senders penalised by per-email pricing. SaaS pricing scales with volume by design. Past a certain monthly send, you're paying a marginal cost on every message for infrastructure whose actual marginal cost is close to zero. Owning the platform converts a variable cost into a largely fixed one.
Hosting providers, agencies, telcos and MSPs who want to sell email. Reselling someone else's SaaS means your customer signs up on another company's platform, sees another company's branding, and belongs — commercially and technically — to that company. Deploying your own means the customer relationship, the pricing and the data are yours. See solutions for agencies.
If none of those describe you, our SaaS plans will serve you better and cost less.
The full stack, not a cut-down edition. Specifically:
It is the same engine that runs the neuMails cloud platform. Not a stripped "enterprise edition" that lags the SaaS product by two releases.
A typical deployment separates three layers, which can sit on one machine for modest volumes or scale horizontally for large ones.
Application layer — the web interface, campaign engine, API endpoints and scheduler. This is what your team and, in reseller deployments, your customers log into.
Database layer — subscriber records, segments, campaign history, suppression lists and event data. This is the component that matters most for residency: it is the personal data, and it sits on your storage.
Delivery layer — the MTA, which accepts messages from the application layer and handles the actual SMTP conversations with recipient mail servers. This is where IP reputation lives, where throttling decisions are made, and where throughput is determined.
The delivery layer binds to your IP addresses and accepts submission on standard SMTP ports — 587 with STARTTLS, 465 with implicit TLS, and 2525 as a fallback where 587 is blocked. Outbound delivery requires port 25 open from your network to the internet, which is worth confirming early because some corporate networks block it by default.
Deployments can run entirely air-gapped from our infrastructure if required, with updates delivered as signed packages rather than pulled from a repository. Where you prefer, we can retain remote management access for monitoring and support — that's a contractual choice, not a technical requirement.
Requirements scale with target throughput, so precise sizing comes out of technical discovery rather than a spec sheet. The baseline is:
We size CPU, memory, storage and IP allocation against your actual sending profile: peak hourly throughput, message size, retention requirements and how many separate reputations you need. Two organisations sending the same monthly volume can have quite different requirements depending on whether that volume arrives evenly or in campaign spikes.
Under India's Digital Personal Data Protection Act, your organisation is the data fiduciary. Using a vendor doesn't transfer that responsibility — it adds a processor whose practices you must be able to account for.
On-premise deployment changes the shape of several obligations:
For regulated sectors this matters more. RBI's storage requirements for payment system data, and similar sectoral expectations in insurance and healthcare, are considerably easier to evidence when the infrastructure is demonstrably yours.
To be clear about what deployment does and doesn't achieve: running the platform yourself does not make you compliant. You still need lawful consent and the records to prove it, defined retention periods, a breach response process and documented access controls. What it removes is an entire category of questions about somebody else's infrastructure. More detail on our DPDP compliance page.
SaaS genuinely wins on speed, simplicity and low-volume economics. On-premise wins on control, residency, brand ownership and high-volume cost. Anyone who tells you one is universally better is selling rather than advising.
The cost case rests on a structural difference rather than a discount.
SaaS pricing is metered — per email, per contact, or both. That model is efficient at low volume, because you pay only for what you use and the vendor absorbs infrastructure cost. But the marginal cost of delivering one more email on infrastructure you already operate is effectively zero, while the marginal price on a metered plan is not. As volume grows, the gap between those two numbers widens.
On-premise converts most of that variable cost into fixed cost: platform licensing, servers, IP addresses and operational effort. Those don't change much whether you send five million emails a month or fifteen.
Which means there is a crossover volume above which owning the platform costs less per email than renting it. Where exactly that sits depends on your sending profile, retention requirements and whether you operate the infrastructure yourself or have us manage it. For most organisations it falls somewhere in the millions of emails per month — but it's worth modelling against your actual numbers rather than trusting a rule of thumb, and we'll do that with you honestly, including telling you if you're below the line.
For resellers the calculation is different again, because the platform becomes revenue rather than cost. Margin is the gap between what you charge your customers and your fixed operating cost — a gap that widens with every tenant you add.
For hosting providers, agencies, telcos and MSPs, the point isn't just running the software — it's that nothing in the experience says anyone else's name.
Your customer signs up on your platform, uses your product, and pays you. The infrastructure underneath is an implementation detail they never encounter.
Moving an existing sending operation is a staged project, not a switch. A typical sequence:
One thing worth stating plainly: sending reputation does not migrate with your data. Your new IPs start from zero regardless of how well your previous platform performed. Warm-up typically takes two to four weeks to reach full volume, and any plan that promises an instant switch at full send rate is one that will damage your deliverability.
Deployment models vary by how much you want to operate yourself:
Whichever model, support runs on IST hours from Noida, by engineers who work with Indian ISPs and Indian sending patterns daily. Response commitments, escalation paths and update cadence are set in the contract rather than assumed.
Tell us your volume, compliance requirements and tenancy model. We'll come back with an architecture, a sizing estimate and an honest view on whether on-premise is right for you.
Talk to Our TeamCampaign, transactional and delivery software installed on servers your organisation owns or controls, rather than accessed as a service from a vendor's cloud. Subscriber data, message content and logs reside on your infrastructure. The vendor supplies the software, deployment and support; you supply and control the environment.
A dedicated IP isolates your sending reputation, but the platform, database and subscriber records still live in the vendor's cloud. On-premise means the application and the data sit inside your own environment. If your requirement is that subscriber data must not leave your infrastructure, a dedicated IP does not satisfy it.
No — it makes several obligations simpler to evidence. Because personal data stays within infrastructure you control, questions about cross-border transfer, sub-processors and data location have direct answers. You remain the data fiduciary and still need consent records, retention policies, access controls and breach procedures.
The complete platform: campaign management and automation, transactional sending over SMTP relay and REST API, subscriber and list management, analytics, delivery logs and deliverability tooling. It is the same engine that runs the neuMails SaaS, in your environment rather than ours.
Yes. Interface branding, logo, colour scheme, login domain, sending domains and customer-facing pages such as unsubscribe and preference centres all carry your brand. For resellers, your customers never encounter the neuMails name.
At minimum: Linux servers (RHEL or Debian-based), static IPs with reverse DNS control, a domain with DNS management, NTP synchronisation, and outbound port 25 permitted. Exact CPU, memory, storage and IP count depend on target throughput and are scoped during technical discovery.
Decided per contract. Options range from fully managed operation by our team with remote access, through co-managed arrangements, to a supported model where your team operates the platform with our escalation support and update packages.
It depends on volume. SaaS scales per email or per contact, so cost rises with growth. On-premise shifts most cost to licensing plus infrastructure, which is largely fixed. There is a crossover point above which on-premise costs less per email — for most organisations that sits in the millions of emails per month. Below it, SaaS is the better economic choice and we'll say so.
Yes. Subscriber lists, segments, suppression lists, templates and sending domains transfer. Automation flows are typically rebuilt rather than imported. Sending reputation does not transfer — new IPs require warm-up, so migrations are staged with a parallel-run period.
Yes. Deployments can run fully isolated from our infrastructure, with updates supplied as signed packages. Retaining remote management access for monitoring and support is a contractual choice, not a technical requirement.