I think it has become pretty clear in 2026 that email delivery is changing and not necessarily in the traditional sense of "here is a message and I want to send it to a recipient."
Email sending has become much more about the controls, routing, security and other technical considerations that sit behind the message itself.
For a long time, the basic concept of email infrastructure was relatively straightforward. An application needed to send an email, it connected to an SMTP server or an email API, provided the message and recipient, and the infrastructure took care of the rest. But as applications have become more complex, so have their email requirements.
A single business may now have multiple applications, environments, customers, brands, domains, sending identities and teams all sending email through the same infrastructure. What once might have been one SMTP credential can now become dozens of different sending streams, each with its own requirements and security considerations.
This is something we have increasingly seen first-hand through Maileroo and our customers. The more systems we work with, the clearer it becomes that email infrastructure is no longer simply about sending an email. It is about controlling who can send, what they can send, where they can send it from, where they can send it to, which infrastructure they use and how those activities are separated from one another.
The evolution from simple email delivery
When we first built Maileroo, it was a much simpler product. The primary objective was straightforward: provide reliable outbound email delivery without forcing developers to build and maintain their own mail infrastructure.
At the time, the problem we were solving was essentially:
"I have an application that needs to send email. How do I reliably get that email delivered?"
And while that remains an important part of what we do, the requirements surrounding that simple question have changed significantly. As businesses have scaled their applications and sending requirements, we have seen more sophisticated questions emerge.
Who should be allowed to send through this account?
Which application is sending this email?
Which domain should that application be allowed to use?
Should a particular application be able to send to every recipient domain?
Which IP address should its messages leave from?
What happens if one application is compromised?
How do you separate different customers or projects while still managing everything from a single account?
These aren't really questions about sending an email anymore. They're questions about email infrastructure management.
The system behind the sending
This is probably one of the biggest changes we have noticed. The actual act of sending an email has become almost trivial. With an API, a developer can make a request and send a message in a matter of seconds. The complexity has moved elsewhere and it now sits in the systems and policies surrounding that request.
Think about a typical modern application:
Application
↓
Email API / SMTP
↓
Authentication
↓
Permission & Policy Checks
↓
Routing
↓
Delivery Infrastructure
↓
Recipient Mail ServerEvery stage can introduce its own requirements.
The application needs to authenticate.
The sending identity needs to be authorised.
The domain needs to be verified.
The request may need to originate from an approved environment or IP address.
The email may need to be routed through a particular outbound IP.
The recipient may need to fall within an allowed policy.
And only then does the message enter the actual delivery process.
This is why we increasingly think of modern email infrastructure as a control layer, rather than simply a delivery layer.
More control doesn't have to mean more complexity
Of course, there is a trade-off. Technical teams are generally capable of building many of these controls themselves.
You can create separate API credentials.
You can build your own permission systems.
You can restrict access by IP.
You can create internal routing rules.
You can maintain databases mapping applications to domains.
You can build logic to determine which recipients are permitted.
You can create separate environments for different clients.
The problem isn't necessarily whether you can build these things.
The problem is whether you should have to. Every additional control you build becomes another component that your team needs to maintain, monitor, test and secure.
A system that starts as:
if user_can_send:
send_email()can eventually become something much more complicated:
Is the application authorised?
↓
Is the API key valid?
↓
Is the request coming from an approved IP?
↓
Is this sender domain authorised?
↓
Is this From address permitted?
↓
Is this recipient domain permitted?
↓
Which outbound IP should be used?
↓
SendThat complexity exists for good reason.
But it doesn't mean developers should have to reinvent it for every application they build.
This is why we built Applications
The Applications feature in Maileroo came directly from this evolution in how customers were using email infrastructure.
Applications allow you to create separate, self-contained sending environments within a single Maileroo account. Each Application can have its own credentials, domains, IP restrictions, recipient restrictions and outbound routing configuration.
Instead of treating an entire Maileroo account as one large sending environment, Applications allow you to divide that infrastructure into controlled environments.
For example, imagine a business operates three separate systems:
E-commerce Platform
↓
Application A
CRM Platform
↓
Application B
Customer Portal
↓
Application CAll three can exist within the same Maileroo account while maintaining their own sending credentials and configuration.
This gives the organisation a much clearer distinction between its different email streams.
Applications aren't just about organisation
At first glance, you might look at Applications and think:
"This is just a way to organise my email credentials."
But the concept goes much further than that.
The real value is control and segregation.
Each Application can be configured with its own authorised domains, local-part restrictions, recipient-domain restrictions and IP allowlists. You can also specify which outbound IPs should be used for that Application.
That means you can create rules around the sending environment itself.
For example, you might have:
Application A — Customer Platform
Allowed to send from:
and
Application B — Marketing Platform
Allowed to send from:
Application C — Internal System
Restricted to your corporate IP addresses and only allowed to send to internal recipient domains.
All three can exist within the same Maileroo account while maintaining their own controls.
That is a very different approach from simply handing every system the same SMTP credentials.
Security is becoming part of email infrastructure
This is another area where email sending has changed significantly.
Historically, security around email often focused heavily on authentication protocols such as SPF, DKIM and DMARC.
Those remain extremely important.
But there is another layer of security that sits before the email is even sent.
You need to consider:
Who is allowed to send?
Where are they allowed to send from?
Which identities can they use?
Which recipients can they communicate with?
Which infrastructure should process those messages?
This is where application-level controls become particularly useful.
If a credential belonging to one application is compromised, having every system share the same unrestricted credentials creates a much larger potential blast radius.
Separating applications and restricting what each credential can do can help reduce that risk.
For example:
Maileroo Account
|
+---------------+---------------+
| | |
Application A Application B Application C
| | |
Domain A Domain B Domain C
IP rules IP rules IP rules
Recipient Recipient Recipient
rules rules rulesInstead of having one credential with access to everything, each environment can have its own defined boundaries.
This is a concept that has become increasingly important as email becomes more deeply integrated into business-critical applications.
Routing is becoming just as important as sending
Another major shift is the growing importance of where email is sent from.
For some businesses, the question isn't simply:
"Can I send this email?"
It is:
"Which infrastructure should send this email?"
Different applications may have different sending requirements.
You may want transactional traffic routed through one IP while another application uses a different outbound IP.
You may have dedicated infrastructure for a particular customer.
You may want different applications separated for reputation or operational reasons.
You may simply want to know exactly which system is responsible for a particular sending stream.
Modern email infrastructure therefore needs to provide more than connectivity.
It needs to provide routing control.
Maileroo Applications allow outbound IPs to be selected for individual Applications, with the option to fall back to the account's normal IP policy when required.
This means routing becomes part of the Application configuration rather than something that needs to be manually managed at the application level.
The rise of multi-tenant email infrastructure
Another reason this is becoming increasingly important is the rise of SaaS platforms.
A SaaS company might have hundreds or thousands of customers, and each customer may generate email through the platform.
Suddenly, the sending infrastructure needs to understand the difference between:
Customer A
Customer B
Customer C
Customer D
...while still allowing the SaaS provider to manage the overall infrastructure centrally.
This creates a multi-tenant problem.
You want centralised management, but you don't necessarily want every customer or application to share unrestricted access to the same sending environment.
This is where segregation becomes valuable.
Instead of thinking:
One account = one sending environment
we can start thinking:
One account = multiple controlled sending environments.
That's a much closer reflection of how modern software businesses actually operate.
The same applies to agencies
This isn't limited to SaaS companies.
Agencies are another great example.
An agency may manage email for dozens of different clients.
Traditionally, this can result in a collection of credentials, accounts and configurations scattered across different systems.
A centralised email infrastructure with separate Applications provides another approach.
You could have:
Agency Maileroo Account
|
+── Client A Application
|
+── Client B Application
|
+── Client C Application
|
+── Client D ApplicationEach Application can have its own SMTP credentials and API key, while domains, IP restrictions and routing can be configured independently.
This makes it easier to understand which client or project is responsible for which email traffic without needing completely separate infrastructure for every environment.
Observability matters too
As email infrastructure becomes more complex, visibility becomes increasingly important.
It's one thing to have multiple applications.
It's another thing to actually understand what each one is doing.
If something goes wrong, developers need to be able to answer questions such as:
Which application sent this message?
Which credentials were used?
Which domain was involved?
Where did the request originate?
Which outbound IP handled the message?
Was the message accepted?
Did it encounter a delivery failure?
This is why logging and monitoring become a natural extension of application-level email controls. Maileroo allows logs to be filtered by Application, making it possible to review activity associated with a particular sending environment. The goal isn't simply to provide more data, it's to make the data useful when you're trying to understand what your infrastructure is actually doing.
Email infrastructure is becoming policy-driven
Perhaps the biggest shift we see is that email sending is becoming increasingly policy-driven.
The traditional model looked something like:
Application → SMTP → RecipientThe modern model is closer to:
Application
↓
Authentication
↓
Application Policy
↓
Sender Policy
↓
Recipient Policy
↓
Routing Policy
↓
Delivery Infrastructure
↓
RecipientThe email itself hasn't necessarily become more complicated.
The rules around the email have.
And that isn't necessarily a bad thing.
As systems become more distributed and businesses become more dependent on email, having these controls becomes increasingly important.
What does this mean for developers?
For developers, I think the biggest change is that email infrastructure is increasingly becoming something you should be able to configure rather than build.
There will always be situations where custom infrastructure makes sense.
Large organisations with highly specific requirements may still want to build their own systems and controls. For most development teams, maintaining a complete email infrastructure stack isn't where they want to spend their engineering resources.
They want to build their application.
They want to build their product.
They want to build their customer experience.
They don't necessarily want to spend weeks building a permission system around SMTP credentials, maintaining routing rules or developing a system to separate different email streams.
That is where email infrastructure providers can provide more value.
Where we see email sending going next
If the last few years have taught us anything, it is that email infrastructure is becoming more sophisticated.
The next generation of email platforms won't simply compete on whether they can deliver an email.
They will compete on how much control they can provide around that delivery.
That means more granular permissions, better routing, stronger segregation, more detailed observability, more automation and increasingly sophisticated security controls.
The email itself may still look like:
From: [email protected]
To: [email protected]
Subject: Your order has shippedBut behind those few lines may be an entire infrastructure determining whether that message should be sent, who is allowed to send it, which identity can be used, which IP should handle it, where it should be routed and how the resulting delivery should be tracked.
And that is perhaps the biggest change in email sending in 2026.
The future of email isn't just about sending more. It's about giving developers more control over everything that happens around the send.
Building Maileroo around that idea
This evolution is also reflected in how we have approached Maileroo.
What started as a relatively straightforward outbound email delivery service has evolved as we've learned more about what businesses actually need from their email infrastructure.
Features such as Applications are a direct result of that learning. Rather than requiring developers to build these controls themselves, Maileroo is increasingly designed to provide them as part of the infrastructure.
Applications are one example of this: separate sending environments, independent SMTP and API credentials, domain restrictions, local-part controls, recipient-domain restrictions, IP allowlists and outbound routing can all be managed within a single Maileroo account. And ultimately, that's where we think email infrastructure is heading.
Less "here's an SMTP server." More "here's the infrastructure and control layer your applications need to send email safely, reliably and intelligently."
