DEV Community: Bucabay

Mautic email deliverability: replace SMTP with the Symfony Mailer DSN transport

Bucabay — Sat, 08 Aug 2026 17:41:11 +0000

Mautic is a marketing-automation platform, so email is the product, not a side effect.
A contact form on a CMS sends a handful of messages a day; a Mautic campaign to a real
segment can fan out to thousands in one send. That makes Mautic's mail transport the single
highest-leverage setting in the whole install — and most Mautic docs still point you at
generic SMTP.

Mautic 5 doesn't need SMTP for this anymore. It moved from SwiftMailer to Symfony Mailer,
which resolves transports from a DSN string, and MailKite ships a first-party transport
for exactly that: mailkite/symfony-mailer.
Install it, set one field, and Mautic's send errors go from a numeric SMTP code to the
API's own explanation of what actually went wrong.

Why this beats pointing Mautic at SMTP

Generic SMTP gives you a status code and, if you're lucky, a line of server text. It also
means every send is a full protocol round-trip: connect, EHLO, AUTH, MAIL FROM, RCPT TO,
DATA. The DSN transport skips the protocol layer and calls the MailKite API directly, and
when something's wrong — an unverified domain, a suppressed recipient, a rate limit — it
says so:

Unable to send an email: Can't send yet — domain not verified. (MailKite API status 403).

Compare that to 550 5.7.1 Relaying denied and try to explain to a client why their
newsletter didn't go out.

Install the transport

composer require mailkite/symfony-mailer

Requires PHP 8.1+ and Symfony Mailer 6.4 or 7.x — both satisfied by any current Mautic 5
install.

Set the DSN

Get an API key from the MailKite dashboard, then set it as
Mautic's Mailer DSN. Where this lives depends on how your instance is configured — either
.env.local (or wherever your host reads MAILER_DSN) or, on some Mautic installs,
Configuration → Email Settings → Service: DSN:

MAILER_DSN=mailkite+api://mk_live_xxx@default

The API key sits in the DSN's user slot — there's no separate SMTP username to invent, and
no password field to keep in sync with it. Mautic autoconfigures the transport factory the
moment the package is installed; nothing else to register.

Clear Mautic's cache after changing the DSN:

bin/console cache:clear

Verify your sending domain

The from address on every campaign has to be on a domain with SPF and DKIM published in
MailKite — that's true whether you're sending through this transport or plain SMTP, and
it's the actual determinant of whether Mautic's mail lands in the inbox or spam. See
mailkite.dev/docs/quickstart if you haven't set
that up yet.

Test it

Create a test email in the Mautic editor and use Send test. Check the MailKite
dashboard's message log to confirm delivery — if it fails, the error you see in Mautic now
comes straight from the API instead of a generic SMTP rejection.

No shell access? Fall back to SMTP

Some managed Mautic hosts don't give you Composer access. In that case, the plain SMTP path
still works — same domain, same API key as the password, just without the honest-error
behavior described above:

Setting	Value
SMTP Host	`smtp.mailkite.dev`
SMTP Port	`587`
Encryption	TLS (STARTTLS)
Username	`mailkite`
Password	Your API key (`mk_live_…`)

A note on campaign-scale sending

Symfony Mailer transports — this one included — send one email per request; that's the
contract every transport follows, not a MailKite-specific limitation. Mautic's own
campaign/batch layer is what turns a segment send into individual calls, so this doesn't
change how a campaign send behaves. If you're calling the MailKite API directly, outside
Mautic, for a very large one-off send, use the PHP SDK's sendBatch() instead of looping
individual sends.

Troubleshooting

DSN not picked up — clear the cache (bin/console cache:clear) after any change to MAILER_DSN.
"User is not set" — the API key has to be in the DSN's user slot: mailkite+api://mk_live_xxx@default, not mailkite+api://default.
535 Authentication failed (SMTP fallback path only) — the password field must be your mk_live_… API key, not a separate SMTP credential.
Campaign sends but individual test doesn't (or vice versa) — check that the specific from address used matches a verified domain; Mautic allows setting different from addresses per campaign.

Full transport reference, the mapping table, and what the transport refuses rather than
silently drops:
mailkite.dev/docs/integrations/symfony-mailer.
Platform-specific config reference:
mailkite.dev/docs/integrations/mautic.

Originally published at mailkite.dev.

One DSN, three PHP ecosystems: MailKite's Symfony Mailer transport

Bucabay — Fri, 07 Aug 2026 17:39:30 +0000

mailkite/symfony-mailer resolves a mailkite+api:// DSN into a first-party Symfony Mailer transport — which means Mautic, PrestaShop, Drupal, and any plain Symfony app all get it from one package, with honest errors instead of a generic SMTP rejection.

TL;DR: mailkite/symfony-mailer is a new package that turns mailkite+api://API_KEY@default into a valid Symfony Mailer DSN. One composer require, and every MailerInterface::send() in a Symfony app — or in Mautic, PrestaShop, or anything else built on Symfony Mailer — delivers through MailKite's Send API instead of SMTP. It's extracted from our existing mailkite/laravel package, which now depends on it rather than carrying its own copy of the mapping logic. 15 tests, no network, all green. composer require mailkite/symfony-mailer will resolve once the package clears Packagist's one-time submission step — until then, install straight from the GitHub repo (v0.1.0 is tagged).

Why one package reaches three ecosystems

Symfony Mailer resolves transports from a DSN string. That's a small design choice with a large consequence: any platform built on Symfony Mailer inherits the same extension point, whether or not that platform has anything else to do with Symfony.

use MailKite\Mailer\Transport\MailKiteTransportFactory;
use Symfony\Component\Mailer\Mailer;
use Symfony\Component\Mailer\Transport\Dsn;

$transport = (new MailKiteTransportFactory())->create(
    Dsn::fromString('mailkite+api://mk_live_xxx@default')
);
$mailer = new Mailer($transport);

Write a TransportFactoryInterface implementation once, and it's live everywhere that mechanism is used:

A plain Symfony app — set MAILER_DSN in .env, done. Autoconfiguration picks up the factory the moment the package is installed.
Mautic 5+ — replaced SwiftMailer with Symfony Mailer and a DSN field in Configuration → Email Settings. Mautic is worth calling out specifically: it's a marketing-automation platform, so email volume per install runs far ahead of a typical CMS or CRM contact form.
PrestaShop 8+ — Symfony-based mailer since PS8, same DSN mechanism.
Drupal, via the Symfony Mailer Lite module — a smaller install base (17,528 sites) but the same wiring.

We didn't build four integrations. We built one, and the DSN did the rest.

What was actually new here — and what wasn't

The transport itself isn't new code. It's the same AbstractTransport subclass that's lived inside mailkite/laravel since that package shipped: doSend() converts a SentMessage into a MailKite send payload via MessageConverter::toEmail(), calls the API, and stamps the returned message ID back onto the message.

What's new is the factory — the piece that resolves a DSN string into that transport — and moving the transport itself out from under Laravel so it isn't Laravel's to own:

final class MailKiteTransportFactory extends AbstractTransportFactory
{
    public function create(Dsn $dsn): TransportInterface
    {
        $apiKey = $this->getUser($dsn); // throws IncompleteDsnException if missing
        $host = $dsn->getHost();
        $endpoint = $host === 'default'
            ? 'https://api.mailkite.dev'
            : sprintf('https://%s%s', $host, $dsn->getPort() !== null ? ':' . $dsn->getPort() : '');

        return new MailKiteTransport(new Client($apiKey, $endpoint));
    }

    protected function getSupportedSchemes(): array
    {
        return ['mailkite', 'mailkite+api'];
    }
}

mailkite/laravel's composer.json now requires mailkite/symfony-mailer and its MailKiteServiceProvider instantiates MailKite\Mailer\Transport\MailKiteTransport directly — the ~200 lines of address, body, and attachment mapping logic exist in exactly one place. The Laravel package's own test suite dropped from 14 tests to 4, because it's no longer testing logic it doesn't own; it tests wiring (does MAIL_MAILER=mailkite resolve to the right transport, does the SDK client singleton bind, does a missing key throw a helpful error).

Honest failures instead of a generic SMTP rejection

This is the part worth dwelling on if you're currently pointing Mautic, PrestaShop, or Drupal at generic SMTP. SMTP gives you a numeric code and maybe a line of server-specific text. The MailKite API returns its own error message — "domain not verified," a suppressed recipient, a rate limit — and this transport surfaces it verbatim instead of translating it into an SMTP-shaped abstraction that loses the detail:

try {
    $mailer->send($email);
} catch (TransportException $e) {
    // "Unable to send an email: Can't send yet — domain not verified. (MailKite API status 403)."
}

The same honesty applies to what the transport won't silently drop:

Situation	What happens
Custom header (`X-Campaign`, a tag/metadata header)	Throws — the API's envelope has no room for it, so refusing beats a header that quietly never arrives
Inline (`cid:`-embedded) image	Throws — the API has no Content-ID support; host the image at a URL instead
More than one reply-to address	Throws — the API accepts exactly one
Unverified `from` domain	Throws with the API's own message and HTTP status

Every one of those is a case where a generic SMTP transport would either accept the message and let it fail downstream, or reject it with a code that doesn't say why. This one tells you the actual reason at the call site.

The batch-sending trade-off, made explicit

Symfony-provided transports send one email per request — that's the TransportInterface contract, and MailKiteTransport follows it like every other bridge. Most third-party Symfony Mailer transports stop there: no batch path, full stop, one HTTP round-trip per recipient no matter how many you're sending.

We didn't want to pretend our transport batches when it doesn't, so it's documented instead: for high-volume sends — a Mautic campaign to a real list, a PrestaShop order-email backlog — call the PHP SDK's sendBatch() directly rather than looping mailer->send() per message. It's a different code path for a different job, not a workaround bolted onto the transport.

Try it

composer require mailkite/symfony-mailer

# .env
MAILER_DSN=mailkite+api://mk_live_xxx@default

Full mapping table, troubleshooting, and the Mautic-specific walkthrough: mailkite.dev/docs/integrations/symfony-mailer. Running Mautic specifically? See mailkite.dev/docs/integrations/mautic for the DSN field location and an SMTP fallback for managed hosts without shell access.

Using Laravel instead of raw Symfony Mailer? mailkite/laravel wraps this same transport with MAIL_MAILER=mailkite and Laravel's own config conventions — nothing to change there, it's already using the code in this post.

Originally published at mailkite.dev.

MailKite now ships a native mailer for six more frameworks

Bucabay — Thu, 06 Aug 2026 17:41:44 +0000

MailKite shipped native mail integrations for Spring Boot, ASP.NET Core, Next.js, NestJS, Flask, and FastAPI in one day — three new packages, two verified starters with no new code, and two real bugs found in already-published packages along the way.

Six frameworks, one day, three new packages. mailkite-spring-boot-starter gives Spring Boot a native JavaMailSender. MailKite.AspNetCore gives ASP.NET Core Identity a native IEmailSender. next-mailkite gives Next.js a signature-verified inbound webhook route it didn't have before. NestJS and Flask and FastAPI got runnable starters instead of packages, on purpose, for reasons explained below — and building all six surfaced two real bugs in code we'd already shipped, which we fixed rather than buried.

The fastest one to show is ASP.NET Core, because the whole idea — swap one interface, every existing call site keeps working — is clearest there. IEmailSender is the interface ASP.NET Core Identity already calls for every account-confirmation and password-reset email; MailKite.AspNetCore implements it:

// starters/aspnet-core/Program.cs
builder.Services.AddDefaultIdentity<IdentityUser>(options => options.SignIn.RequireConfirmedAccount = true)
    .AddEntityFrameworkStores<ApplicationDbContext>();

// MailKite: every account-confirmation / password-reset email Identity sends goes through
// POST /v1/send via the official MailKite .NET SDK.
builder.Services.AddMailKiteEmailSender(builder.Configuration, options =>
{
    // FromAddress/FromName come from appsettings' "MailKite" section; ApiKey falls back to
    // the MAILKITE_API_KEY environment variable — never commit a real key here.
});

That's the entire integration. No controller changes, no template rewrites — Identity's Register and ForgotPassword pages just start sending through MailKite. We ran this starter for real: dotnet build clean, the app boots, /Identity/Account/Register and /Identity/Account/ForgotPassword both render, and DI resolves the sender correctly at startup.

New package	Already worked	No seam — docs only
Spring Boot — `JavaMailSender`	NestJS — `@nestjs-modules/mailer` + `nodemailer-mailkite-transport`	Flask — Flask-Mail → `smtplib`
ASP.NET Core — `IEmailSender`	verified, shipped a starter only	FastAPI — `fastapi-mail` → `aiosmtplib`
Next.js — webhook + `sendEmail()`		runnable starters, SMTP relay or SDK

Found while building, not before: nodemailer-mailkite-transport@0.1.0's ESM-only exports map breaks require() in NestJS's CJS build (fixed locally in 0.1.1, unreleased) · the Python SDK throws an unhandled JSONDecodeError when Cloudflare's WAF returns a non-JSON body (confirmed independently on Flask and FastAPI).

Same day, three integration shapes — matched to what each framework's mail layer actually exposes, not forced to fit one template.

Spring Boot: the largest audience we didn't already have a play for

In 2025, 15.6% of professional developers reported using Spring Boot (Stack Overflow Developer Survey, 2025) — the biggest framework population on this list that MailKite had no first-party integration for before today. Spring's own mail abstraction is MailSender/JavaMailSender, the same seam spring-boot-starter-mail fills, and mailkite-spring-boot-starter implements both:

<!-- starters/spring-boot/pom.xml -->
<dependency>
  <groupId>dev.mailkite</groupId>
  <artifactId>mailkite-spring-boot-starter</artifactId>
  <version>0.1.0</version>
</dependency>

# application.properties — MAILKITE_API_KEY env var binds to mailkite.api-key automatically
mailkite.default-from=${MAILKITE_DEFAULT_FROM:hello@yourdomain.com}

Set MAILKITE_API_KEY and any existing @Service calling JavaMailSender starts delivering through MailKite — no new code paths. We didn't stop at mvn package: the demo app actually ran (mvn spring-boot:run), rendered its send form, and a real POST reached the live MailKite API and came back with the API's own auth error, proving the full chain — controller → MailKiteMailSender → SDK → api.mailkite.dev — is wired correctly end to end. Nine unit tests pass locally.

ASP.NET Core: .NET's largest audience, tied at the top

ASP.NET Core tied for the largest professional-developer framework share in the 2025 survey at 21.3% (Stack Overflow, 2025). MailKite.AspNetCore also implements the newer generic IEmailSender<TUser> that .NET 8's Identity API endpoints expect, so both the classic Identity UI and the newer minimal-API Identity story are covered by the same package.

Next.js: the single most-used framework, and it had almost nothing

Next.js was the single most-used framework in the entire 2025 survey at 21.5% (Stack Overflow, 2025) — ahead of Express, ahead of ASP.NET Core, ahead of everything. Until today, the only MailKite-and-Next.js code in this repo was a five-line REST snippet. next-mailkite is a real package: a signature-verified inbound webhook route handler for the App Router, plus a sendEmail() wrapper.

// starters/nextjs/app/api/mailkite/inbound/route.ts
import { createMailKiteRouteHandler } from 'next-mailkite';
import handler from '@/lib/mailkite-handler';

export const { POST } = createMailKiteRouteHandler(handler);

That one export verifies the x-mailkite-signature header and dispatches the parsed event to your own handler — no hand-rolled HMAC. We didn't just unit-test it: the starter's /inbound log page rendered a real HMAC-signed synthetic webhook payload end to end, and tsc/next build are both clean (13/13 vitest cases passing on the package itself).

NestJS: the honest answer was "it already worked"

NestJS is a structured TypeScript framework with its own mail convention: @nestjs-modules/mailer's MailerModule takes any nodemailer transport object. Our existing nodemailer-mailkite-transport package already is a nodemailer transport object. So instead of writing a nestjs-mailkite wrapper package nobody needed, we verified the real configuration and shipped a starter:

// starters/nestjs/src/mail/mail.module.ts
import { MailerModule } from '@nestjs-modules/mailer';
import { mailkiteTransport } from 'nodemailer-mailkite-transport';

MailerModule.forRoot({
  transport: mailkiteTransport({ apiKey: process.env.MAILKITE_API_KEY }),
});

Building this the honest way — actually running dist/main.js, not just type-checking — is what surfaced the first real bug below.

Flask and FastAPI: no seam to plug into, so no package

Neither Flask-Mail nor fastapi-mail/fastapi-mailman expose a swappable transport the way Django's EMAIL_BACKEND, Rails' ActionMailer, Laravel's Mail::extend, or the frameworks above do — both wrap smtplib/aiosmtplib directly. There's nothing to register a MailKite adapter into. So both got a runnable starter instead: Flask-Mail pointed at MailKite's SMTP relay (or the Python SDK directly, for API mode), and a FastAPI app calling the Python SDK from inside run_in_threadpool so a synchronous SDK call never blocks the event loop.

Worth flagging directly: FastAPI's PyPI downloads now exceed Flask's — roughly 490M versus 197M monthly as of July 2026 (pepy.tech, 2026). That growth doesn't create a code opportunity here. Usage share and buildable integration surface are different axes, and this is the clearest place in the whole batch where they diverge.

Two real bugs, found by actually running the thing

Both of these came from running the starters, not just compiling them — and we're not burying either one.

nodemailer-mailkite-transport@0.1.0's package.json exports map is ESM-only. NestJS's default build output is CommonJS, and building + actually running the NestJS starter reproduced ERR_PACKAGE_PATH_NOT_EXPORTED on require(). Node ≥22.12 can load a true ES module through require() directly — the file format was never the problem — the exports map just had no condition that matched CJS resolution. The fix (adding require/default conditions, no source change) is written and tested locally as 0.1.1; it hasn't shipped to npm yet.

The Python SDK throws an unhandled JSONDecodeError instead of a clean MailKiteError. api.mailkite.dev sits behind Cloudflare, which returns a non-JSON 403 body to requests with no (or a blocked) User-Agent header — confirmed independently while building both the Flask and FastAPI starters, using nothing but bare urllib. The SDK's error path doesn't guard the non-JSON case, so it crashes instead of surfacing a normal error. Both starters ship a defensive workaround at the call site; the real fix — a User-Agent header and a guarded parse in sdks/python — is still pending.

Neither bug blocks anything you'd build today. Both are logged in docs/integrations/RELEASING.md in the source repo so they don't get lost between "found" and "fixed."

What this doesn't cover yet

A Symfony Mailer transport (mailkite/symfony-mailer, covering Symfony itself plus Mautic and PrestaShop) shipped the same day on a separate track — see /docs/integrations/symfony-mailer for that one. Django is covered by an open pull request against Anymail, the ecosystem's standard multi-provider backend, not yet merged. Publishing MailKite.AspNetCore to NuGet is blocked on the base .NET SDK itself landing there first; mailkite-spring-boot-starter needs its own Maven Central publish wired up. None of that changes what's runnable today — every starter and package above builds and runs against the real API right now.

Frequently asked questions

Why did NestJS and Flask/FastAPI get starters but no new package?

Because a new package should exist only when it closes a real gap. NestJS's existing mailer ecosystem already accepts our transport with zero glue code; Flask and FastAPI have no pluggable mail interface for a package to register into at all. Shipping wrapper code nobody needs is worse than shipping none.

Is the `nodemailer-mailkite-transport` bug affecting me right now?

Only if you consume it via require() from a CommonJS build — most directly hit if you're using it inside NestJS or another Nest-style CJS project. ESM consumers (including the plain Node.js/Express path this package originally targeted) were never affected. The fix is written and tested; it's waiting on a version bump and publish.

Does MailKite still support plain SMTP for these frameworks?

Yes — every framework here can also just point its mail library's SMTP settings at MailKite's relay; that's exactly the path Flask and FastAPI use today. The packages exist for frameworks where a native transport gets you logging, batch sends, and dashboard visibility that SMTP alone can't express.

Where's the code?

Packages: integrations/spring-boot-starter/, integrations/aspnet-core/, integrations/next-mailkite/. Runnable demos: starters/spring-boot/, starters/aspnet-core/, starters/nextjs/, starters/nestjs/, starters/flask/, starters/fastapi/. Full docs are linked from each framework's page under /docs/integrations.

Originally published at mailkite.dev.

MailKite Server: our SMTP + IMAP edges are now open source

Bucabay — Sat, 01 Aug 2026 00:00:00 +0000

TL;DR: the mail-server half of MailKite is now open source:
github.com/mailkite/server — the Haraka MX edge,
the SMTP submission edge, the IMAP server, a zero-dependency SQLite backend, and a web
console. AGPL-3.0. Runs on any Node ≥ 22.5 host: a $5 VPS, Docker, Fly, Railway. Five
releases in, it receives real internet mail, dispatches signed inbound webhooks, and
relays outbound through a smarthost — including MailKite Cloud itself.

What's in it

Every component is a stateless protocol head. All state sits behind one small HTTP
contract — five IMAP read endpoints, an inbound ingest hook, an SMTP auth check, and a
relay endpoint (docs/contract.md).
That design is the whole trick: the bundled SQLite backend and MailKite Cloud are just
two implementations of the same contract, so the edges and the web console run unchanged
against either.

mta/ — inbound MX (Haraka): accepts on :25, POSTs raw RFC822 to your backend as a signed webhook, with live anti-open-relay recipient checks.
mta-submit/ — submission (:587/:465): SMTP AUTH for apps that only speak SMTP.
imap/ — IMAP4 on :993: read your received mail from Thunderbird, Apple Mail, or your agent's IMAP library.
api-local/ — the reference backend: one Node process, node:sqlite, zero npm dependencies. Per-domain inbound webhooks (HMAC-signed dispatch with a durable retry queue) and smarthost outbound — point SMARTHOST at any SMTP relay, or set SMARTHOST=cloud to send through MailKite Cloud's deliverability while keeping storage on your box.
ui/ — the web console: domains and DNS records, message log, credentials, webhooks. Signs in with an emailed magic link; first run bootstraps the admin WordPress-style.

These aren't a code drop — the SMTP/IMAP edges are the same code serving MailKite
production today, and the conformance suite that gates the repo runs against both
backends.

One MX, many backends

The MX edge routes per recipient domain across multiple backends
(docs/multi-backend.md):
each backend claims its domains, RCPT checks consult every claim list, and accepted mail
is signed and ingested to whichever backend owns the recipient. We run this in our own
production — the same MX that fronts MailKite Cloud also delivers to a self-hosted
backend. Which means you can skip running port 25 entirely and point our hosted MX at
your self-hosted install.

Already running Haraka?

You don't need to adopt the repo. The plugins are on npm as
haraka-plugin-mailkite:

npm install haraka-plugin-mailkite
# config/plugins: add "mailkite"; config/mailkite.ini: role = mx  (or submit)

Your existing MX or submission server then speaks the contract to any backend — the
bundled SQLite one, MailKite Cloud, or your own implementation.

Why open source it

Email infrastructure buyers are (rightly) lock-in-averse. The honest answer is to make
the server open and keep the hosted product what it should be: deliverability, IP
reputation, retention, webhooks at scale, and a human when something breaks. Self-host
the parts that are yours; rent the parts that are genuinely hard to run — the
SMARTHOST=cloud hybrid is exactly that split, one env var at a time.

If you'd rather not babysit port 25: the same web console connects to
MailKite Cloud with one credential swap.

License

AGPL-3.0 for the code; the MailKite name and logo stay trademarked (forks rebrand).
Contributions welcome — see
CONTRIBUTING.md.

I've launched 4 SaaS startups this year - my template

Bucabay — Sat, 18 Jul 2026 04:39:51 +0000

I've been on a SaaS startup building and launching spree this year since I lost half my web development contracts to AI. I think many developers have been in the same boat.

Instead of looking for more development work (which is in real flux at the moment) I decided to instead launch my own SaaSes.. SaaSs?

The first thing I noticed as many have, is AI can scaffold a UI very quickly - in 30 minutes I had a SaaS website - yay! It was quite bland but well designed - ok - nothing fancy. Then came iterating on that website, which took days - then weeks to get it right. AI seems to fix something and break something else at the same time - this went on forever.

Now the bigger development effort for a SaaS is the backend - the dashboard and the multi-tenancy, the stripe plans/payments integrations, the email sending, authentication, team management, ACL, privacy, security... the list get's long pretty quick - but it is finite if you want it to be.

So if you spent one week on the website, prepare to spend a month on the dashboard and 6 months on the backend.

Quickly I learnt the important rule. Make a few choices upfront that minimizes your development. Like the 80/20 rule - but also the discipline to follow through.

Choose the most important features of your SaaS. Figure out your value proposition and the pain point you fix. Focus only on that and build just that and launch. Don't build anything else - truly - do not.

If you are building an email sending platform, just build a backend that sends emails. Hook into into your necessary SaaS features, which are authentication, payments.

The good part is that you realize quickly that you are building a few things over and over, payment, auth, dashboard UI, users profile, teams. (At first, don't even build teams - it's not needed for your main goal - just the fix to the pain point).

Now - this story is sequential - from when I started to what I learned along the way. However, it's not how you should build a SaaS - it's just the story. To build a SaaS now focus first on the most important thing - your AI development environment. Spend 2-3 days on that. Seriously, your SaaS will take at least a month to build, 2-3 days on the environment your AI will work in will pay off 100 fold.

I use Claude most the time so it pays to read up on the best practices - https://platform.claude.com/docs/en/about-claude/use-case-guides/overview

I also use a number of other Agents for differnet purposes. GLM2.5 at this time is as good as latest Claude Opus but faster. I use it for smaller fixes that are isolated. For very quick generation - an idea I want to scaffold I will use three differnet agents at once - Claude, GLM, DeepSeek (I now US doesn't like DeepSeek but it's the fastest model almost on par with Claude just for one shot research), combine their ideas into one and then have Claude optimize and choose the best mix.

The reason I do 3 models is that they open up the possibility space of the response. Claude is optimized for US users and tied to US laws and government controls - it will reply with that as the scoping context that limits the openess of it's reponse. This is critical to understand for marketing research.

GLM and DeepSeek are open models, general and non US focused, they give broader replies and consider non-US views. Their reponse is not as limited. Especially if you're researching non-US markets their response is valuable.

Now back to how to actually build your SaaS.

The 20/20 vision of hindsight. To actually build your SaaS - research first. Start with where your visitors will be coming from. Are you going to focus on Google searches? SEO? Paid Ads? If it's paid Ads, what is your search phrases, how much are the CPC on those - how dense is that market and how rooted are the current leaders? When you answer these questions your choice of SaaS becomes a lot more likely to succeed.

List the ways you will get customers

Use my existing network (X, LinkedIn, Dev.to)
Paid Google Ads
Paid Posts on Instagram
SEO
Posting on Reddit, Hacker News
Making blog posts
Creating freebies (Templates, Open Source libraries)
Listings on directories

How will your target your specific customers

My linkedin is mostly software engineers - my SaaS is AI image generator - not the right fit - I'll just spam 10K linkedin contacts...

These answers start allowing you to see which paths will actually bring customers to your SaaS, which changes the choices you make for your SaaS.

Paid Google Ads - How much is CPC on AI Image generator. What's the CPA if I can make at least 2% sign up and then 2% of those buy the paid plan which is $20. Anwser that and you'll realize AI Image Generator is too costly for google ads unless you've got a huge ad budget.

Now this goes on.. you'll notice something. What you thought was a good idea for a SaaS usually isn't from a marketing first point of view. When you envision how your customers find your SaaS and how many will sign up and purhcase a subscription.

You'll notice the good SaaS is one that you research well and find need that is not filled well and marketing for it is reasonable. What was hard was figuring out what that need was.

Now I can't tell you what those needs are - I'm still researching and building. This is just where I've landed after launching 4 startups (one very 2-3 months) this year.

To help you on your journey of building your SaaS I've created a boilerplate - https://saas-startup.mailkite.dev/

It is purposefully basic, what's important is the framework is Agent research first. Take a look at the github - https://github.com/mailkite/saas-startup

and importantly the AGENTS.md (CLAUDE.md equivalent) - https://github.com/mailkite/saas-startup/blob/main/AGENTS.md

If forces the agent to research the market and build UI, UX, features based on it's research. Documents the research, catelogs and refines. Over time the development will stay linear - not become a big pile of spaghetti AI code.

Please share your thoughts and experience in building SaaS - the new best thing this year.

Build software that heals itself in the agentic era

Bucabay — Wed, 01 Jul 2026 22:16:28 +0000

Disclosure: I build MailKite, and the open-source mail-parse library I use as the example is ours. But the pattern is the point — it isn't MailKite-specific, and you can apply it to anything that eats messy input.

Self-healing software is a system architected so that, when it hits input the real world throws at it, it doesn't crash and it doesn't stay broken: it records a structured, PII-free failure signature, and that signature feeds a repair loop — increasingly, an AI agent — that turns the breakage into a permanent fix behind automated gates. In the agentic era the bottleneck is no longer writing the fix; a capable agent can do that. The bottleneck is architecting your software so an agent's fix is safe, automatic, and cumulative. This post is that pattern. I'll use our open-source MIME parser (mail-parse) as the running example — messy input is where software goes to die — but the shape applies to almost any system that eats hostile real-world data.

Two honesty notes before I start, because a post that blurs shipped and planned isn't worth reading. First: this is part one of a two-part series — part one is the architecture and what runs today; part two comes after the fully autonomous loop ships and we've watched it heal real input in the wild. Second: I'll label each piece shipped or in progress as I go, and there's a status table at the end.

The loop the agentic era changes

The classic repair loop is slow and human-shaped: a bug slips into production → someone eventually files an issue → a human reproduces it, writes a patch, ships a release → weeks later every install benefits. It works, but it's measured in weeks and gated on a human being in the loop for every single fix.

Agents change what's possible here, not by being trusted to write perfect code, but by being fast and tireless at the boring middle. The interesting question stops being "can an agent write the fix?" (increasingly, yes) and becomes: when an agent can propose a fix in seconds, how do you build software so that letting it do so isn't reckless? Answer that, and your system stops accumulating breakage — every new way the world is wrong becomes a one-time event.

Five design moves make it work. I'll state each generally, then ground it in the parser.

1. Never crash — turn every failure into a structured signal

The foundation of a self-healing system is that failure is a first-class, structured output, not an exception that unwinds the stack. If your software dies on bad input, there's nothing to heal; if it silently mangles it, there's nothing to detect. The discipline is: always produce the best result you can, and alongside it a machine-readable record of everything you had to paper over.

In the parser (shipped): mail-parse never throws. An unclosed MIME boundary pops the orphaned context and emits BOUNDARY_NOT_CLOSED; a charset that won't decode falls back and emits UNKNOWN_CHARSET. You always get a message and a typed list of what was wrong with it. Those diagnostics aren't logging — they're the raw material every downstream loop runs on.

import { parse } from "@mailkite/mail-parse";

// parse() never throws — even on a broken message it returns a best-effort
// result *plus* a typed list of everything it had to paper over.
const msg = parse(rawMime);

msg.subject;      // decoded as far as it could
msg.attachments;  // whatever it could recover
msg.diagnostics;
// → [
//     { code: "BOUNDARY_NOT_CLOSED", scope: "structure" },
//     { code: "UNKNOWN_CHARSET",     scope: "part", contentType: "text/html" },
//   ]

2. Make fixes additive, not surgery — a plugin seam

If every fix means editing the core, fixes are risky, they collide, and no agent (or human) should be trusted to make them at speed. The move is a registry: a seam where new behavior is a self-contained, narrowly-scoped, contained unit — it can't take down the whole system, and it's obvious what it touches.

In the parser (shipped): fixups are middleware in a PostCSS-style registry — each declares a phase, a match predicate, and a handler, and a middleware that throws becomes a contained MIDDLEWARE_ERROR diagnostic while the chain keeps going. A new format quirk is a new middleware with a narrow predicate, not a patch threaded through the core. That containment is exactly what later lets a generated fix be admitted without betting the system on it.

// A new format quirk is a self-contained middleware with a narrow predicate —
// not a patch threaded through the core.
const tnef = {
  phase: "decode",
  match: (part) => part.contentType === "application/ms-tnef",
  handler: (part) => extractWinmailDat(part),
};

registry.use(tnef);
// If handler throws, the parser records a contained MIDDLEWARE_ERROR
// diagnostic and the rest of the chain keeps running.

3. Name failures identically everywhere — without leaking data

To fix a class of breakage you first have to name it, the same way across every install, without ever collecting private data. That's a failure signature: a deterministic hash over structure only. It does two things at once — it lets a thousand installs hitting the same bug collapse into one prioritized signal, and it gives the repair loop a precise, shareable target.

In the parser (shipped): the signature is an FNV-1a hash over PII-free features — diagnostic codes, content-type, transfer-encoding, a byte-shape fingerprint, mailer family, structure path — and never bytes, addresses, or subjects. Two installs on opposite sides of the world hitting the same Outlook-TNEF quirk compute the same hash. A multi-granularity rollup lets you cluster loosely or tightly. (It's pinned identical across our TypeScript, Python, and Go ports by a golden-corpus test, so the herd can't drift.)

interface FailureSignature {
  hash: string;                 // = fnv1a(canonicalize(features))
  features: {
    scope: "envelope" | "structure" | "part";
    diagnosticCodes: string[];  // e.g. ["UNKNOWN_CHARSET"]
    contentType?: string;       // the offending leaf's declared type
    transferEncoding?: string;
    byteSignature?: string;     // hex magic of the first N bytes — never content
    mailerFamily?: string;      // X-Mailer normalized → "Outlook/16"
    structurePath?: string;     // "multipart/mixed>…>application/ms-tnef"
  };
}

Nothing in there is content — no subject, no addresses, no body bytes — so the same broken email produces the same hash in every language:

from mailparse import compute_signature

sig = compute_signature({
    "scope": "part",
    "diagnosticCodes": ["UNKNOWN_CHARSET"],
    "contentType": "text/plain",
    "transferEncoding": "base64",
})
sig["hash"]  # "13586f32bb2840c6" — byte-identical in Node, Python, and Go

4. Two loops: fix the core for everyone, patch the edge safely

Self-healing has two speeds, and you want both.

The cold loop — fix the library for everyone. (Shipped.) When the parser degrades it emits a FailureReport. Where it goes is the deployer's choice — reporting is opt-in, with no default phone-home — but point the built-in reporter at the core repo and it files exactly one deduplicated GitHub issue per signature (a hidden parse-signature: marker makes it idempotent; N installs → 1 issue), containing the structural signature and, in writing, no message content. A responder — a human, or an AI coding routine triggered by the issue — reproduces from the scrubbed signature, fixes the core, and opens a PR that CI won't merge unless a golden corpus and a benign-input regression set both stay green. The fix ships to every install, in every language.
The hot loop — patch one edge now. (In progress: designed, next.) A library release takes time, and some quirks are concentrated in a single tenant's weird upstream system. For those, the design is an agent, handed the sealed failing fixture, that writes a narrowly-scoped middleware plus a golden test pinning its behavior — a stopgap that heals that edge immediately while the cold loop fixes the root cause for everyone.

5. Trust the gates, not the generator — the security crux

Here's the part the agentic era forces you to get right, because the hot loop means running code a model wrote against real production data. You do not make that safe by trusting the model. You make it safe by building an architecture where a fully compromised or simply wrong generated fix still can't do harm. Almost the entire hot-loop design (in progress) is that safety envelope:

Sandboxed execution. Generated fixes run as Wasm (Extism) with deny-by-default capabilities and a hard CPU/fuel budget — no network, no filesystem, no ambient authority. A bad fix can transform its input or burn its fuel and die; it can't reach anything else. (Generation and CI run in a separate sandbox, isolated from production.)
Adversarial gates the model doesn't author. A fix is admitted only if it clears system-owned tests: it must fire zero times against a benign corpus of well-formed input (no collateral damage), it must satisfy the golden test generated from the failing case (it actually fixes the thing), and it must clear a specificity floor (its predicate is narrow, not a catch-all). The agent proposes; adversarial tests dispose.
Canary, then commit. An admitted fix rolls out at 5% → 25% → 100%, watched against a structural agreement metric — a bad fix is caught on a sliver of traffic, not all of it.
A kill switch per fix. Every generated unit is individually disableable by config, no redeploy — instant, reversible rollback.

// What the hot-loop agent generates (designed, next): a narrowly-scoped
// middleware that fires ONLY on the failing signature — plus a golden test.
export default {
  phase: "decode",
  match: (part) =>
    part.contentType === "text/html" &&
    part.charset === "x-user-defined",   // the one quirk, nothing else
  handler: (part) => decodeAs(part, "windows-1252"),
};
// Admitted only if it fires zero times on the benign corpus, passes the
// golden test from the failing case, and clears the specificity floor —
// none of which the agent wrote.

That's what makes autonomy defensible: a vetted fix can auto-promote with no human in the loop — not because we trust the model, but because what stands between a generated fix and production isn't anyone's judgment, it's a sandbox it can't escape, a battery of adversarial tests it didn't write, a canary that bounds blast radius, and a switch that undoes it. This is the same thesis behind how we built our agent inbox: in the agentic era you stop trying to make the model un-foolable and instead bound what a fooled model is allowed to do.

Where else this pattern fits

MIME is a vivid example because email is gloriously broken, but the pattern fits anywhere software meets messy, adversarial, or drifting real-world input. The same five moves — tolerant core, plugin seam, anonymous failure signature, cold/hot loops, gated sandbox — map cleanly onto:

Ingesting messy formats. CSV and bank-statement imports, PDF/OCR extraction, HTML scraping, log parsing, address and phone normalization. Every one is a hostile-input boundary that today either throws or silently corrupts. Signature the failure, let an agent add a scoped normalizer, gate it on a golden corpus.
Third-party API and webhook adapters. Upstream payloads drift or go malformed and your integration breaks in prod. An adapter that emits a schema-drift signature instead of a 500 lets an agent write a narrow shim for that provider's quirk — sandboxed, canaried — while a core fix follows.
Data pipelines / ETL schema drift. An upstream column gets renamed or a type changes; the pipeline emits a signature rather than poisoning the warehouse, and an agent proposes the mapping behind tests that must stay green on the historical data.
Abuse, spam, and fraud rules. A new evasion pattern is exactly a new failure signature. An agent generates a candidate rule that must fire zero times against a known-good corpus before it's canaried — the benign-corpus gate is the whole safety story, and it's identical to the parser's.
Client and device compatibility shims. Quirky browsers, email clients, IoT firmware, legacy POS terminals — each non-conforming client is a per-quirk plugin, added on demand, contained, and kill-switchable, instead of a growing tangle of if (userAgent...) in the core.

In each case the expensive, human-shaped part — noticing, reproducing, scoping, testing — is what the pattern automates, and the sandbox-plus-gates is what makes automating it safe.

What's live today vs. what's next

Capability	Status
Tolerant core (never throws, typed diagnostics)	✅ Live
Additive plugin seam (registry, contained fixes)	✅ Live
PII-free failure signatures (deterministic, deduping)	✅ Live
Cross-language parity (golden corpus + signature pinning)	✅ Live
Shadow harness (observe-only, structure-only compare)	✅ Live
Cold loop (opt-in, anonymous, deduplicated GitHub issues)	✅ Live
Hot loop (AI-generated fixes)	🔧 Designed, next
Wasm sandbox + capability/fuel limits	🔧 Designed, next
Adversarial gates, canary rollout, per-fix kill switch	🔧 Designed, next

FAQ

What does "self-healing software" actually mean here today?
Today: the system never dies on bad input, it records a precise PII-free signature of what broke, and identical signatures across all installs collapse into one deduplicated GitHub issue that drives a fix shipped to everyone. The fully autonomous part — an agent generating and shipping a sandboxed fix with no human in the loop — is designed and coming next.

Isn't letting an AI agent patch production reckless?
It would be if you trusted the agent's output. The design doesn't: generated fixes run as capability-denied Wasm with a fuel budget, are admitted only by adversarial tests the agent didn't write (benign-corpus zero-fire, a golden test from the failing case, a specificity floor), are canaried, and are individually kill-switchable. You trust the gates and the isolation, not the model.

Does any of this send my data anywhere?
No. Reporting is opt-in with no default phone-home, and the failure signature is structural only — codes, types, byte-shape, mailer family — never bytes, addresses, or subjects.

Can I apply the pattern without a MIME parser?
Yes — that's the point. Any boundary where you eat messy real-world input (imports, scrapers, API adapters, ETL, abuse rules, compatibility shims) can adopt the same five moves: tolerant core, plugin seam, anonymous failure signature, cold/hot loops, and a gated sandbox for generated fixes.

Software will always meet a new way the world is wrong; the agentic era is a chance to make each new way a one-time event instead of a permanent scar. mail-parse is our open-source instance of the pattern, in TypeScript, Python, and Go — see the libraries, and if you'd rather get the parsed message without running any of it, point a domain at MailKite.

Part two comes after the autonomous loop ships. Everything labeled in progress above — the AI hot loop, the Wasm sandbox, the adversarial gates and canary rollout — gets its own post once it's live and we've watched it heal real input. And that feedback is the whole point: it arrives only through the anonymous, opt-in failure signal described above — structural, PII-free, and never sent unless you wire up a reporter — so part two will be written from what actually broke in the wild, not from a single byte of anyone's data.

This post was first published on the MailKite blog. Related: You can't prompt your way out of prompt injection applies the same "trust the architecture, not the model" philosophy to AI agents with email.

DEV Community: Bucabay

Mautic email deliverability: replace SMTP with the Symfony Mailer DSN transport

Why this beats pointing Mautic at SMTP

Install the transport

Set the DSN

Verify your sending domain

Test it

No shell access? Fall back to SMTP

A note on campaign-scale sending

Troubleshooting

One DSN, three PHP ecosystems: MailKite's Symfony Mailer transport

Why one package reaches three ecosystems

What was actually new here — and what wasn't

Honest failures instead of a generic SMTP rejection

The batch-sending trade-off, made explicit

Try it

MailKite now ships a native mailer for six more frameworks

Spring Boot: the largest audience we didn't already have a play for

ASP.NET Core: .NET's largest audience, tied at the top

Next.js: the single most-used framework, and it had almost nothing

NestJS: the honest answer was "it already worked"

Flask and FastAPI: no seam to plug into, so no package

Two real bugs, found by actually running the thing

What this doesn't cover yet

Frequently asked questions

Why did NestJS and Flask/FastAPI get starters but no new package?

Is the nodemailer-mailkite-transport bug affecting me right now?

Does MailKite still support plain SMTP for these frameworks?

Where's the code?

MailKite Server: our SMTP + IMAP edges are now open source

What's in it

One MX, many backends

Already running Haraka?

Why open source it

License

I've launched 4 SaaS startups this year - my template

Build software that heals itself in the agentic era

The loop the agentic era changes

1. Never crash — turn every failure into a structured signal

2. Make fixes additive, not surgery — a plugin seam

3. Name failures identically everywhere — without leaking data

4. Two loops: fix the core for everyone, patch the edge safely

5. Trust the gates, not the generator — the security crux

Where else this pattern fits

What's live today vs. what's next

FAQ

Is the `nodemailer-mailkite-transport` bug affecting me right now?