DEV Community: Hani Khanani

How to send Listmonk newsletters through OwnMailServer

Hani Khanani — Wed, 28 Oct 2026 14:59:55 +0000

To send newsletters and campaigns with OwnMailServer, run Listmonk for your contacts, lists and campaigns, and point its SMTP settings at us: smtp.ownmailserver.com, port 587, STARTTLS, with an API key as the password. Then slow Listmonk down to our 10 messages a second, cap it at your daily warm-up limit, and forward our bounce webhooks to Listmonk. It takes about an hour.

OwnMailServer is a sending service: it delivers email, handles bounces and complaints, warms up your sending and watches your reputation. It doesn't store contact lists or edit campaigns. Listmonk does, and it's free, open source and self-hosted, so your subscriber list stays in your own database.

What you need before you start

An approved OwnMailServer account with a verified sending domain. Listmonk's From address must be on that domain, or we refuse the email with 550. The API docs list the DNS records.
An API key, created in your dashboard under API keys & SMTP. Choose Sending only (the default), limited to your sending domain. It's the SMTP password.
A server with Docker to run Listmonk. A small VPS is enough for most lists.
A domain name for Listmonk with HTTPS, such as lists.example.com. Unsubscribe links, the subscription form and the archive all point to it, so readers must be able to reach it.
A list you can stand behind: people who signed up and expect your email. We review every account's list source, and bought or scraped lists get accounts paused quickly through bounces and complaints.

Step 1: Install Listmonk with Docker

Listmonk's official Docker Compose file starts Listmonk and its PostgreSQL database:

mkdir listmonk && cd listmonk
curl -LO https://github.com/knadh/listmonk/raw/master/docker-compose.yml
docker compose up -d

Listmonk listens on port 9000. Open http://<your-server>:9000 and create the Super Admin user. As of October 2026, the current stable release is v6.2.0, with v7 in beta. The compose file uses the stable image.

Put Listmonk behind a reverse proxy with HTTPS (nginx, Caddy or Traefik) on lists.example.com before you send anything. Then, in Settings → General:

Root URL: https://lists.example.com. Listmonk builds unsubscribe and tracking links from it. Leaving it on localhost breaks every unsubscribe link you send.
'From' emails: an address on your verified domain, such as Example News <news@example.com>.

Step 2: Connect Listmonk to OwnMailServer over SMTP

In Settings → SMTP, edit the first server (or add one) and enter:

Listmonk field	Value
Host	`smtp.ownmailserver.com`
Port	`587`
Auth protocol	`LOGIN` (`PLAIN` also works)
Username	`ownmailserver` (we accept any value)
Password	Your API key
TLS	`STARTTLS`
Skip TLS verification	Off
Max. connections	`2`
Retries	`2`

Save, then use Send e-mail on the SMTP settings page to send yourself a test. If the test fails:

535: the password isn't a valid API key.
550: the From address isn't on a verified domain, or the account is still pending approval.
Connection timeout: your server's firewall or hosting provider is blocking outbound port 587.

The SMTP section of our API docs lists every reply code.

Step 3: Match Listmonk's speed to our limits

Listmonk's defaults are built to send as fast as the mail server allows: 10 workers, each sending up to 10 messages a second. That's up to 100 a second. We accept 10 a second per account and answer the rest with a temporary 450. Listmonk counts those as errors and pauses the campaign once there are too many.

In Settings → Performance, set:

Setting	Value	Why
Concurrency	`2`	Two workers sending at once.
Message rate	`4`	2 × 4 = 8 messages a second, under our 10.
Batch size	`1000`	Fine as is; it only controls how many subscribers Listmonk reads from its database at a time.
Maximum error threshold	Leave the default	A paused campaign is a useful signal that something is wrong.

At 8 a second, Listmonk sends about 28,000 emails an hour. If you need more, ask us to raise your account's rate, then raise Message rate to match.

Stay under your warm-up cap

A new account can only reach a limited number of recipients in any 24 hours. The cap starts at a few hundred and grows about 25% after each clean day. Your dashboard shows the current number, and our warm-up guide explains how it grows. Past the cap, we answer with 450 until the window clears.

Listmonk can hold to that number itself. In Settings → Performance, turn on Enable sliding window limit and set:

Duration: 24h
Max. messages: your current daily cap

Raise Max. messages as your cap grows. A campaign bigger than the cap then goes out over several days instead of stopping halfway. Transactional mail sent through the same account counts toward the same cap, so leave some room for it.

Step 4: Keep one-click unsubscribe working

Gmail and Yahoo require bulk senders to offer one-click unsubscribe (RFC 8058) and to honour it within two days. See our guide to the Gmail and Yahoo sender requirements.

Listmonk handles this for you. In Settings → Privacy, keep Include List-Unsubscribe header on. Listmonk then adds List-Unsubscribe and List-Unsubscribe-Post headers that point at your Listmonk server, and records the unsubscribe on the subscriber when a reader clicks.

Here's how that works with OwnMailServer:

When an email already has its own List-Unsubscribe header, we don't add ours, so readers see exactly one Unsubscribe button.
We treat the email as marketing. If someone unsubscribed through one of our own links in the past, we won't send them Listmonk campaigns, but they still get your receipts and password resets.
Our DKIM signature covers both unsubscribe headers. Gmail and Yahoo only show the button when it does.

Keep your Root URL on public HTTPS. A one-click unsubscribe is a POST from Gmail's servers to that URL, and it fails if Listmonk can't be reached.

Step 5: Send bounces and complaints back to Listmonk

We already protect your sending: hard bounces and spam complaints go on your suppression list automatically. If Listmonk sends to a suppressed address, we drop that email. It isn't sent, isn't charged and doesn't count toward your cap. Your reputation is safe even if Listmonk never hears about the bounce.

Your Listmonk lists still go stale, though, and your campaign numbers include addresses that will never receive anything. To keep them clean, pass our webhook events to Listmonk's bounce endpoint.

In Listmonk:

In Settings → Bounces, turn on Enable bounce processing and Enable bounce webhooks.
Set the bounce actions. A sensible setup: Hard, count 1, Blocklist. Complaint, count 1, Blocklist. Soft, count 2, None.
In Users, create a user of type API whose role can post bounces, and copy its token.

In OwnMailServer: add a webhook in your dashboard for email.bounced and email.complained, pointing at the small relay below. Copy the signing secret it shows you once.

The relay checks our signature, then posts each event to Listmonk. It uses only Node.js built-ins (Node 18 or later):

// relay.mjs: OwnMailServer webhooks -> Listmonk bounces
import { createServer } from "node:http";
import { createHmac, timingSafeEqual } from "node:crypto";

const SECRET = process.env.OMS_WEBHOOK_SECRET;   // whsec_... from the OwnMailServer dashboard
const LISTMONK = process.env.LISTMONK_URL;       // https://lists.example.com
const AUTH = "Basic " + Buffer.from(`${process.env.LISTMONK_API_USER}:${process.env.LISTMONK_API_TOKEN}`).toString("base64");

// Standard Webhooks signature: base64 HMAC-SHA256 of "id.timestamp.body".
function verified(raw, h) {
  const id = h["webhook-id"], ts = h["webhook-timestamp"], sigs = h["webhook-signature"] ?? "";
  if (!id || Math.abs(Date.now() / 1000 - Number(ts)) > 300) return false;
  const key = Buffer.from(SECRET.replace(/^whsec_/, ""), "base64");
  const expected = Buffer.from(createHmac("sha256", key).update(`${id}.${ts}.${raw}`).digest("base64"));
  return sigs.split(" ").some((s) => {
    const sig = Buffer.from(s.replace(/^v1,/, ""));
    return sig.length === expected.length && timingSafeEqual(sig, expected);
  });
}

createServer((req, res) => {
  let raw = "";
  req.on("data", (chunk) => (raw += chunk));
  req.on("end", async () => {
    if (!verified(raw, req.headers)) return res.writeHead(401).end();
    const { type, data } = JSON.parse(raw);
    // Our "block" bounces (refused by policy) aren't dead addresses, so Listmonk gets them as soft.
    const kind = type === "email.complained" ? "complaint"
      : type === "email.bounced" ? (data.bounce?.type === "hard" ? "hard" : "soft") : null;
    if (kind) {
      const r = await fetch(`${LISTMONK}/webhooks/bounce`, {
        method: "POST",
        headers: { "Content-Type": "application/json", Authorization: AUTH },
        body: JSON.stringify({ email: data.recipient, source: "ownmailserver", type: kind,
          meta: { email_id: data.email_id, diagnostic: data.bounce?.diagnostic } }),
      });
      if (!r.ok) return res.writeHead(502).end();   // a non-2xx reply makes us retry later
    }
    res.writeHead(200).end();
  });
}).listen(8787);

Run it next to Listmonk, behind the same HTTPS proxy, for example at https://lists.example.com/oms-webhook. We only deliver webhooks to public HTTPS addresses. If Listmonk is down, the relay replies 502 and we retry for up to 24 hours.

Step 6: Send your first campaign

Lists: create a list. Choose Double opt-in for anything people join through a form. It costs a few signups and saves you from typos, fake addresses and spam traps.
Subscribers → Import: upload a CSV of people who agreed to hear from you. If you're moving from another tool, remove its unsubscribed and bounced contacts first.
Campaigns → New: write the email and pick the list. The From address must be on your verified domain.
Send a test to yourself and check it lands in the inbox, with the Unsubscribe button next to the sender's name in Gmail.
Start small. Send the first campaigns to your most engaged readers and grow from there as your cap grows.

After it goes out, the Claude connector or the Emails page in your dashboard shows delivery, bounces and complaints per message. Listmonk shows opens, clicks and unsubscribes per campaign. Use one tool's open and click tracking, not both, so links aren't rewritten twice.

When Listmonk isn't the right fit

Listmonk is a lean tool for teams comfortable running a server. It's a poor fit if:

Nobody on the team wants to run software. Listmonk needs updates, backups of its database and an HTTPS proxy. A hosted newsletter service is less work.
You need complex automations. Listmonk handles lists, segments, templates, campaigns and transactional templates. Multi-step journeys with branching are not its strength.
You can't add the HTTPS domain. Without a reachable Root URL, unsubscribe links break, and Gmail and Yahoo may filter your mail.

Listmonk also works with any SMTP server, including one you run yourself. Before your first campaign, run your domain through our email checker and make sure DMARC is in place.

Sending through OwnMailServer is pay as you go, $0.20 per 1,000 emails. See pricing for the details.

FAQ

Does OwnMailServer have its own newsletter or campaign editor?

Not yet. Today OwnMailServer sends email over an API and SMTP, and handles warm-up, bounces, complaints, suppressions and monitoring. Contacts, lists and campaign editing aren't built in. Listmonk fills that gap: it stores your subscribers and campaigns and hands each email to us over SMTP. You keep full control of your list, because it lives in your own database.

Is Listmonk free?

Yes. Listmonk is open source under the AGPL-3.0 license and costs nothing to use. You pay for the server you run it on, typically a small VPS, and for sending. You can run it next to an app you already host, since it only needs Docker and a PostgreSQL database, which its Docker Compose file sets up for you.

Why did Listmonk pause my campaign?

Listmonk pauses a campaign when sending errors pass its Maximum error threshold. With OwnMailServer, the usual cause is a temporary 450 reply: you sent faster than 10 messages a second, or reached your daily warm-up cap. Lower concurrency and message rate, or set a sliding window limit at your current cap, then resume the campaign. Check your dashboard for the cap.

Who handles unsubscribes, Listmonk or OwnMailServer?

Listmonk, if you leave its Include List-Unsubscribe header setting on. Listmonk adds the one-click unsubscribe headers and records the unsubscribe on the subscriber. When an email already carries its own List-Unsubscribe header, we don't add ours. We still sign both headers with DKIM, which Gmail and Yahoo require before they show the Unsubscribe button.

What happens when an address bounces?

We add hard bounces and spam complaints to your suppression list automatically. If Listmonk sends to that address again, we drop it, don't send it, and don't count it toward your warm-up cap. To clean the address out of Listmonk too, forward our bounce and complaint webhooks to Listmonk's bounce endpoint with the small script in this guide.

Originally published at ownmailserver.com.

How to send Laravel mail through OwnMailServer

Hani Khanani — Wed, 28 Oct 2026 14:54:24 +0000

To send Laravel mail through OwnMailServer, set MAIL_MAILER=smtp, MAIL_HOST=smtp.ownmailserver.com, MAIL_PORT=587, any MAIL_USERNAME and an API key as MAIL_PASSWORD in .env, with MAIL_FROM_ADDRESS on your verified domain. Leave MAIL_SCHEME empty so Laravel upgrades the connection with STARTTLS. Your mailables, notifications and password resets then go through us with no code changes.

This guide uses Laravel 11 to 13, which share the same mail configuration.

What you need before you start

An approved OwnMailServer account with a verified sending domain. The From address must be on it, or we refuse the message with 550. The API docs list the DNS records, and the DKIM guide explains them.
An API key, created in your dashboard under API keys & SMTP. Choose Sending only (the default), limited to your sending domain: SMTP only needs to send. Use separate keys for staging and production.

Step 1: Set the mail settings in .env

MAIL_MAILER=smtp
MAIL_SCHEME=null
MAIL_HOST=smtp.ownmailserver.com
MAIL_PORT=587
MAIL_USERNAME=ownmailserver
MAIL_PASSWORD=mp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
MAIL_FROM_ADDRESS="hello@acme.com"
MAIL_FROM_NAME="${APP_NAME}"

Setting	Value	Why
`MAIL_SCHEME`	empty or `null`	Port 587 starts plain and upgrades with STARTTLS. `smtps` is for port 465, which we don't offer.
`MAIL_USERNAME`	any value	We identify you by the API key.
`MAIL_PASSWORD`	an API key	The same key works for the API.
`MAIL_FROM_ADDRESS`	an address on your verified domain	The default for every mailable that doesn't set its own.

Laravel 11 replaced the old MAIL_ENCRYPTION setting with MAIL_SCHEME. If you upgraded an older app, delete MAIL_ENCRYPTION=tls from .env, since it no longer does anything.

If your deploy runs php artisan config:cache, Laravel stops reading .env at runtime, so clear or rebuild the cache and restart the queue workers after changing these:

php artisan config:cache
php artisan queue:restart

Step 2: Send a test

php artisan tinker is the quickest check:

Mail::raw('It works.', fn ($m) => $m->to('you@example.com')->subject('Laravel test'));

No exception means we accepted it. Look the address up in your OwnMailServer dashboard to see the delivery. If you get an exception, the SMTP code in it is explained in the table at the end of this guide.

Step 3: Send real mail with a mailable

Mailables are Laravel's way of describing each email. Generate one with a Markdown template:

php artisan make:mail OrderShipped --markdown=mail.orders.shipped

// app/Mail/OrderShipped.php
namespace App\Mail;

use App\Models\Order;
use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Mail\Mailable;
use Illuminate\Mail\Mailables\Content;
use Illuminate\Mail\Mailables\Envelope;
use Illuminate\Queue\SerializesModels;

class OrderShipped extends Mailable implements ShouldQueue
{
    use Queueable, SerializesModels;

    public $tries = 5;
    public $backoff = [10, 60, 300];

    public function __construct(public Order $order) {}

    public function envelope(): Envelope
    {
        return new Envelope(subject: "Your order #{$this->order->id} has shipped");
    }

    public function content(): Content
    {
        return new Content(markdown: 'mail.orders.shipped');
    }
}

Mail::to($order->customer)->send(new OrderShipped($order));

Because the class implements ShouldQueue, send puts it on the queue instead of sending during the web request, so a slow SMTP connection never slows a page down. Run a worker with php artisan queue:work.

The $tries and $backoff properties matter here. Some of our refusals are temporary: 450 when you send faster than 10 messages a second or reach your daily warm-up cap. Laravel then throws an exception, and the queue retries the job after 10 seconds, a minute and five minutes instead of dropping the email.

Notifications sent through the mail channel and Laravel's built-in password reset and email verification messages use the same mailer, so they go through us too.

Step 4: Keep your old provider as a failover

A new account's daily cap starts at a few hundred recipients and grows about 25% after each clean day (how warm-up works). Laravel's failover mailer lets you switch now without waiting for that: it tries mailers in order and moves on when one throws.

In config/mail.php, add your old provider as a second mailer, then list both:

'mailers' => [
    'smtp' => [ /* OwnMailServer, from .env as above */ ],

    'old' => [
        'transport' => 'smtp',
        'host' => env('OLD_MAIL_HOST'),
        'port' => env('OLD_MAIL_PORT', 587),
        'username' => env('OLD_MAIL_USERNAME'),
        'password' => env('OLD_MAIL_PASSWORD'),
    ],

    'failover' => [
        'transport' => 'failover',
        'mailers' => ['smtp', 'old'],
        'retry_after' => 60,
    ],
],

MAIL_MAILER=failover

Now an email we refuse, for example above your cap, goes out through the old provider instead. Watch your dashboard: once the cap is comfortably above your daily volume and the old provider has stopped picking up mail, set MAIL_MAILER=smtp and cancel it. Your old provider's domain records need to stay in place until then, so its mail still passes SPF and DKIM. Our SendGrid migration guide covers the DNS side.

Option: The HTTP API instead of SMTP

SMTP is the natural fit for Laravel, because every mailable, notification and package already uses it. For a one-off send where you want our response, such as the email id or an idempotency key, call the API with Laravel's HTTP client:

use Illuminate\Support\Facades\Http;

$response = Http::withToken(config('services.ownmailserver.key'))
    ->withHeaders(['Idempotency-Key' => "receipt-{$order->id}"])
    ->post('https://api.ownmailserver.com/emails', [
        'from' => 'Acme <hello@acme.com>',
        'to' => [$order->customer->email],
        'subject' => "Receipt for order #{$order->id}",
        'html' => view('mail.receipt', ['order' => $order])->render(),
    ])
    ->throw();

$emailId = $response->json('id');

Add 'ownmailserver' => ['key' => env('OMS_API_KEY')] to config/services.php. With the same Idempotency-Key within 24 hours, we return the first response and send nothing again, so a retried job can't email the customer twice.

If sending fails

Exception mentions	Cause	Fix
`Connection could not be established` / timed out	Outbound port 587 is blocked	Allow outbound 587 on your server or host's firewall
`535`	`MAIL_PASSWORD` isn't a valid API key	Paste the full key; clear the config cache
`550` domain isn't verified	The From address is on another domain	Set `MAIL_FROM_ADDRESS`, and any mailable's `from`, to your verified domain
`550` awaiting approval	Your account is still being reviewed	Wait for approval, usually within one business day
`450`	10 messages a second or the warm-up cap	Queued mail retries on its own; add failover for the cap
`452`	More than 50 recipients	Send to fewer people per message
`552`	Larger than 10 MB	Link to big files instead of attaching them

After 5 failed logins from one IP address we block that address for 15 minutes, so fix a wrong password before retrying in a loop.

When this isn't the right fit

If your app sends a few thousand emails a month, any SMTP provider's free or entry plan will do, and Laravel makes switching between them a change of .env. We suit apps that want their own IP from 200,000 emails a month, warm-up and monitoring handled, and bounces and complaints suppressed automatically. Sending costs $0.20 per 1,000 emails, with a $10 monthly minimum that covers the first 50,000.

FAQ

What is MAIL_SCHEME in Laravel?

Laravel 11 replaced MAIL_ENCRYPTION with MAIL_SCHEME. It takes smtp or smtps. Leave it empty, or set smtp, for port 587: Laravel connects in plain text and upgrades with STARTTLS when the server offers it, which ours requires. Use smtps only for port 465, which opens with TLS straight away. If you upgraded an older app, delete MAIL_ENCRYPTION from .env.

Why does Laravel still use my old mail settings?

Your configuration is probably cached. When you run php artisan config:cache, as most deploy scripts do, Laravel stops reading .env and uses the cached file. After you change the mail settings, run php artisan config:clear, or run config:cache again, and restart your queue workers, which keep the old settings in memory until they restart.

Can I use Laravel's Resend mailer with OwnMailServer?

Use SMTP instead. Laravel's Resend mailer uses Resend's PHP library, which reads its address only from the RESEND_BASE_URL environment variable with getenv. Once your config is cached that variable often isn't set, and the library quietly calls Resend instead. We test Resend's Node.js and Python SDKs against our API, not the PHP one, so SMTP is the dependable route.

How do I keep my old email provider as a backup?

Define a failover mailer in config/mail.php that lists our SMTP mailer first and your old provider second, then set MAIL_MAILER=failover. Laravel tries each mailer in order and moves to the next one when sending throws an error. During warm-up, mail above your daily cap goes out through the old provider until our cap is high enough.

How do I test Laravel email without sending it?

In automated tests, call Mail::fake() and assert with Mail::assertSent or assertQueued; nothing is sent. For local development, set MAIL_MAILER=log to write each email to the log, or point SMTP at a local catcher such as Mailpit. Use our SMTP settings only in staging and production, with a separate API key for each.

Originally published at ownmailserver.com.

How to send email from Next.js with OwnMailServer

Hani Khanani — Wed, 28 Oct 2026 14:48:53 +0000

To send email from Next.js, call an email API from server code: a route handler or a Server Action, never a client component. With OwnMailServer that's one fetch to POST https://api.ownmailserver.com/emails, with your API key read from an environment variable. If your app already uses Resend's SDK or React Email, keep the code: set RESEND_BASE_URL=https://api.ownmailserver.com and swap in our API key.

Your situation	Use	New packages
Starting fresh	`fetch` to `POST /emails`	None
Already on Resend's SDK	The same SDK with `RESEND_BASE_URL`	None
Want templates as React components	React Email, with either of the above	`@react-email/components`
A library that only speaks SMTP	Nodemailer to `smtp.ownmailserver.com:587`	`nodemailer`

The examples use the App Router. The same calls work in the Pages Router's API routes.

Step 1: Add your API key

You need an approved OwnMailServer account with a verified sending domain: the from address must be on it, or the API returns 403. Create an API key in your dashboard under API keys & SMTP. Choose Sending only (the default), limited to your sending domain: every call in this guide only sends. Then add it to .env.local:

OMS_API_KEY=mp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Don't prefix it with NEXT_PUBLIC_. Next.js inlines NEXT_PUBLIC_ variables into the JavaScript it sends to browsers, and even a sending-only key can send email as your domain. Add the same variable in your host's settings for production, such as Vercel's Environment Variables.

To make a mistake fail at build time rather than leak, put the send helper in a file that imports the server-only package:

// lib/email.ts
import "server-only";

type Email = { to: string | string[]; subject: string; html: string; text?: string; replyTo?: string };

export async function sendEmail(email: Email, idempotencyKey?: string) {
  const res = await fetch("https://api.ownmailserver.com/emails", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.OMS_API_KEY}`,
      "Content-Type": "application/json",
      ...(idempotencyKey && { "Idempotency-Key": idempotencyKey }),
    },
    body: JSON.stringify({
      from: "Acme <hello@acme.com>",
      to: email.to,
      subject: email.subject,
      html: email.html,
      text: email.text,
      reply_to: email.replyTo,
    }),
  });
  const body = await res.json();
  if (!res.ok) throw new Error(`${body.name}: ${body.message}`);
  return body.id as string;
}

If a client component imports this file, the build fails instead of shipping your key.

Step 2: Send from a route handler

A route handler is the right place for anything another service calls, or a form that posts JSON:

// app/api/contact/route.ts
import { sendEmail } from "@/lib/email";

export async function POST(request: Request) {
  const { name, email, message } = await request.json();
  if (typeof email !== "string" || !email.includes("@") || typeof message !== "string" || message.length > 5000) {
    return Response.json({ error: "Invalid input" }, { status: 400 });
  }
  await sendEmail({
    to: "sales@acme.com",
    replyTo: email,
    subject: `New enquiry from ${String(name).slice(0, 100)}`,
    html: `<p>${escapeHtml(message)}</p>`,
    text: message,
  });
  return Response.json({ ok: true });
}

const escapeHtml = (s: string) =>
  s.replace(/[&<>"']/g, (c) => ({ "&": "&amp;", "<": "&lt;", ">": "&gt;", '"': "&quot;", "'": "&#39;" })[c]!);

The form emails you, with the visitor's address in reply_to, so pressing Reply answers them. Never send to an address the visitor types, or from it: an open form that emails anyone is a spam relay, and a visitor's address in from is refused because it isn't your verified domain.

Step 3: Or send from a Server Action

For a form inside your app, a Server Action skips the API route:

// app/invite/actions.ts
"use server";
import { sendEmail } from "@/lib/email";
import { auth } from "@/lib/auth"; // your own session helper

export async function sendInvite(formData: FormData) {
  const user = await auth();
  if (!user) throw new Error("Not signed in");
  const to = String(formData.get("email"));
  const inviteId = crypto.randomUUID(); // in a real app, the id of the invite row you just saved
  await sendEmail(
    { to, subject: `${user.name} invited you to Acme`, html: `<p><a href="https://acme.com/invite/${inviteId}">Accept the invite</a></p>` },
    `invite-${inviteId}`,
  );
}

// app/invite/page.tsx
import { sendInvite } from "./actions";

export default function Page() {
  return (
    <form action={sendInvite}>
      <input name="email" type="email" required />
      <button type="submit">Send invite</button>
    </form>
  );
}

Server Actions are public endpoints that anyone can call, so check the session inside the action, as above, not only in the page.

The Idempotency-Key makes retries safe. If the same key arrives again within 24 hours, our API returns the first response and sends nothing, so a double-click, a retried request or a re-run job can't email someone twice. Use something tied to the event, like the invite or order id.

Using Resend's SDK or React Email

Our API follows Resend's request shapes, response shapes and errors, and we test Resend's own Node.js SDK, version 6, against it. If your app already uses it, change the environment, not the code:

RESEND_API_KEY=mp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx   # an OwnMailServer key
RESEND_BASE_URL=https://api.ownmailserver.com

React Email templates keep working. When you pass react, the SDK renders the component to HTML on your server and sends the HTML, so nothing depends on Resend's servers:

// app/api/welcome/route.tsx (JSX, so .tsx)
import { Resend } from "resend";
import { WelcomeEmail } from "@/emails/welcome";

const resend = new Resend(process.env.RESEND_API_KEY);

export async function POST(request: Request) {
  const { email, name, userId } = await request.json();
  const { data, error } = await resend.emails.send(
    { from: "Acme <hello@acme.com>", to: [email], subject: "Welcome to Acme", react: <WelcomeEmail name={name} /> },
    { idempotencyKey: `welcome-${userId}` },
  );
  if (error) return Response.json({ error }, { status: 500 });
  return Response.json({ id: data.id });
}

Rendering needs @react-email/components (or @react-email/render) installed. Without the SDK, call React Email's render() yourself and pass the HTML to sendEmail() from Step 1. The full switch, including webhooks and domains, is in moving from Resend.

SMTP with Nodemailer

If a library you can't change only speaks SMTP, Nodemailer works in the Node.js runtime:

import nodemailer from "nodemailer";

const transport = nodemailer.createTransport({
  host: "smtp.ownmailserver.com",
  port: 587,
  secure: false,      // starts plain, then upgrades with STARTTLS
  requireTLS: true,
  auth: { user: "ownmailserver", pass: process.env.OMS_API_KEY },
});

On serverless hosts, prefer the API. Every function call would open a new SMTP connection and log in, and an error comes back as an SMTP reply code instead of JSON. One HTTPS request is quicker and easier to debug.

Limits and errors to handle

10 requests a second per account. A burst gets 429 rate_limit_exceeded; wait for the seconds in the retry-after header, or send up to 100 emails in one POST /emails/batch request.
The warm-up cap. A new account's daily limit starts at a few hundred recipients and grows after each clean day (how warm-up works). Above it, sends get 429 daily_quota_exceeded until the last 24 hours have room again. Move your most important email first, and keep the old provider for bulk sends until the cap is high enough.
Suppressed addresses. We don't send to addresses that hard-bounced or complained. The email is stored as suppressed, so check its status or use webhooks if your app needs to know.
Accepted isn't delivered. A success response means we queued the email. To act on deliveries and bounces, add a webhook or look the email up with GET /emails/{id}.

When this isn't the right fit

If your app sends a few hundred emails a month, Resend's free tier, 3,000 emails a month as of October 2026, may be all you need, and Resend's developer experience is excellent. We suit apps that want their own IP once they pass 200,000 emails a month, managed warm-up and monitoring, and a Resend-compatible API, so switching back and forth is a change of environment variables. Sending through us costs $0.20 per 1,000 emails, with a $10 monthly minimum that covers the first 50,000.

FAQ

How do I send email from Next.js?

Call an email API from server code. In the App Router, that's a route handler such as app/api/contact/route.ts or a Server Action marked use server. Read the API key from an environment variable without the NEXT_PUBLIC_ prefix, so Next.js never sends it to the browser, and make one POST request to the provider's send endpoint. The response tells you the email was accepted.

Can I use Resend's SDK with OwnMailServer?

Yes. Our API follows Resend's request and response shapes, and we test Resend's own Node.js SDK, version 6, against it. Set RESEND_BASE_URL=https://api.ownmailserver.com, or pass baseUrl when you create the client, and use an OwnMailServer API key. Sending, batches, attachments, scheduling and idempotency keys all work.

Does React Email work without Resend?

Yes. React Email is an open-source library that turns React components into email HTML. Call its render function and send the HTML to any provider. If you use Resend's SDK with the react option, the SDK does that rendering on your server before it sends, so the same code works when it points at our API.

Should I use Nodemailer and SMTP in Next.js?

You can, in the Node.js runtime. On serverless hosts such as Vercel, the HTTPS API is usually simpler: each email is one request, with nothing to keep open between function calls, and errors come back as JSON. Use SMTP when a library you can't change only speaks SMTP. Our SMTP server is smtp.ownmailserver.com on port 587.

How do I stop a contact form from being abused?

Validate the input on the server, send the message to yourself rather than to an address the visitor types, put the visitor's address in reply_to, and rate-limit the route by IP. Add a CAPTCHA or a hidden honeypot field if bots find it. An open form that emails any address you're given will be found and used for spam.

Originally published at ownmailserver.com.

How to send Firebase email through OwnMailServer

Hani Khanani — Wed, 28 Oct 2026 14:43:22 +0000

Firebase doesn't ship a list of email providers, but it sends through any SMTP server or HTTPS API, so it works with OwnMailServer in three ways. Use custom SMTP in Firebase Auth for password resets and verification emails, the Trigger Email from Firestore extension to send by writing documents, or a Cloud Function that calls our API for full control. Most apps use the first plus one of the other two.

You want to send	Use	Code needed
Password resets, email verification, sign-in links	Firebase Auth custom SMTP	None
Emails written as Firestore documents	Trigger Email extension, or the function below	None / about 40 lines
Receipts, alerts, anything with your own template	A Cloud Function calling `POST /emails`	About 40 lines
Fully custom auth emails	A function with `generatePasswordResetLink`	About 30 lines

What you need before you start

An approved OwnMailServer account with a verified sending domain. Every From address must be on that domain, or we refuse the email with 550. The API docs list the DNS records, and the DKIM guide explains them.
An API key, created in your dashboard under API keys & SMTP. Choose Sending only (the default), limited to your sending domain: it can send and nothing else. It's the SMTP password and the API bearer token. Create one per use, so you can revoke one without breaking the others.
For Cloud Functions or extensions: a Firebase project on the Blaze plan and the Firebase CLI.

Option 1: Firebase Auth emails over custom SMTP

Firebase Auth sends its own emails for password resets, email address verification, email link sign-in and email change. By default they come from a Firebase sender. Point them at us and they come from your domain, signed with your DKIM key, with bounces in your dashboard.

In the Firebase console, open Authentication, then Templates, then SMTP settings, turn it on and enter:

Field	Value
Sender address	An address on your verified domain, such as `no-reply@acme.com`
SMTP server host	`smtp.ownmailserver.com`
Port	`587`
Username	`ownmailserver` (we accept any value)
Password	Your API key
Security mode	`STARTTLS`

Save, then trigger a password reset for a test account. If nothing arrives, look the address up in your dashboard first. A 535 means the password isn't a valid API key, and a 550 means the sender domain isn't verified. If the message isn't there at all, turn SMTP off and try again: if Firebase's own sender then delivers, the settings are the problem.

Firebase still writes these emails and their links, so you edit the text in the same Templates screen. If you've upgraded to Identity Platform with multi-tenancy, Google's docs say tenants must be set to inherit custom SMTP settings, or their users keep getting the default sender.

Option 2: The Trigger Email from Firestore extension

The Trigger Email extension (firebase/firestore-send-email) watches a collection. Each new document becomes an email, and the extension writes the delivery state back onto the document.

Install it from the console or the CLI:

firebase ext:install firebase/firestore-send-email

When it asks for settings:

Parameter	Value
Authentication Type	Username & Password
SMTP connection URI	`smtp://ownmailserver@smtp.ownmailserver.com:587`
SMTP password	Your API key (stored in Secret Manager)
Email documents collection	`mail`
Default FROM address	`Acme <no-reply@acme.com>`

Use smtp:// with port 587, not smtps://: the connection starts plain and upgrades with STARTTLS, which we require before login. Then send an email by adding a document:

import { getFirestore, collection, addDoc } from "firebase/firestore";

await addDoc(collection(getFirestore(), "mail"), {
  to: ["jane@example.com"],
  message: {
    subject: "Your receipt",
    text: "Thanks for your order.",
    html: "<p>Thanks for your order.</p>",
  },
});

Two cautions. If clients can write to mail, anyone signed in to your app can email anyone, so write these documents from trusted server code or lock the collection down with security rules. And Firebase says the Extensions service shuts down on March 31, 2027: installed extensions keep running, but you can't reconfigure or update them after that. For a new project, use Option 3, which reads the same document shape.

Option 3: A Cloud Function that calls our API

A second-generation Cloud Function can call POST /emails with plain fetch, which Node.js 18 and later include. This one replaces the extension: it sends every new mail document and records the result on it.

Store the API key as a secret first:

firebase functions:secrets:set OMS_API_KEY

// functions/index.js
import { onDocumentCreated } from "firebase-functions/v2/firestore";
import { defineSecret } from "firebase-functions/params";

const OMS_API_KEY = defineSecret("OMS_API_KEY");

export const sendMail = onDocumentCreated(
  { document: "mail/{id}", secrets: [OMS_API_KEY] },
  async (event) => {
    const doc = event.data.data();
    const res = await fetch("https://api.ownmailserver.com/emails", {
      method: "POST",
      headers: {
        Authorization: `Bearer ${OMS_API_KEY.value()}`,
        "Content-Type": "application/json",
        // Firestore triggers can run more than once; the key stops a second send.
        "Idempotency-Key": `mail-${event.params.id}`,
      },
      body: JSON.stringify({
        from: doc.from ?? "Acme <no-reply@acme.com>",
        to: doc.to,
        subject: doc.message.subject,
        html: doc.message.html,
        text: doc.message.text,
      }),
    });
    const body = await res.json();
    if (!res.ok) {
      await event.data.ref.update({ delivery: { state: "ERROR", error: `${body.name}: ${body.message}` } });
      // 429 and 5xx are worth retrying; turn on retries in the function's settings.
      if (res.status === 429 || res.status >= 500) throw new Error(body.message);
      return;
    }
    await event.data.ref.update({ delivery: { state: "SENT", id: body.id } });
  },
);

firebase deploy --only functions

The Idempotency-Key header matters here. Firestore triggers deliver at least once, so a function can run twice for one document. With the same key within 24 hours, our API returns the first response and sends nothing again.

From here, the rest of the API works the same way: scheduled sends, batches of up to 100, tags and webhooks for deliveries and bounces. Our API also follows Resend's request shapes, so if you already call Resend from a function, you can keep the code and change the base URL.

Option 4: Custom auth emails with your own template

If you want auth emails in your own design, let the Admin SDK create the link and send it yourself:

// Same functions/index.js as above, so OMS_API_KEY is already defined.
import { onCall } from "firebase-functions/v2/https";
import { initializeApp } from "firebase-admin/app";
import { getAuth } from "firebase-admin/auth";

initializeApp();

export const requestPasswordReset = onCall({ secrets: [OMS_API_KEY] }, async (req) => {
  const email = String(req.data.email ?? "");
  let link;
  try {
    link = await getAuth().generatePasswordResetLink(email, { url: "https://acme.com/login" });
  } catch {
    return { ok: true }; // Don't reveal whether the account exists.
  }
  await fetch("https://api.ownmailserver.com/emails", {
    method: "POST",
    headers: { Authorization: `Bearer ${OMS_API_KEY.value()}`, "Content-Type": "application/json" },
    body: JSON.stringify({
      from: "Acme <no-reply@acme.com>",
      to: [email],
      subject: "Reset your Acme password",
      html: `<p>Click to choose a new password:</p><p><a href="${link}">Reset password</a></p>`,
    }),
  });
  return { ok: true };
});

generateEmailVerificationLink and generateSignInWithEmailLink work the same way. Call this function from your app instead of the client SDK's sendPasswordResetEmail. It's a public endpoint, so protect it with App Check or a rate limit, or it becomes a way to flood inboxes from your domain.

Limits to plan for

10 requests or messages a second per account. A burst from a batch job gets 429 from the API or 450 over SMTP; retry with backoff, or use POST /emails/batch.
Warm-up cap. A new account's daily limit starts at a few hundred recipients and rises after each clean day (how warm-up works). Password resets count, so move your highest-volume email last, and keep your old provider for it until the cap is high enough.
50 recipients and 10 MB per message.
Suppressions. We drop email to addresses that hard-bounced or complained, and don't count it toward your cap. Fix typos in sign-up forms early, since every bad address bounces.

When this isn't the right fit

If you send a few hundred auth emails a month, Firebase's default sender is free and you may not need any of this. The reasons to switch are your own domain on every email, bounce and complaint data you can see, and one provider for auth and app email. At our pay-as-you-go pricing, the $10 monthly minimum covers the first 50,000 emails.

FAQ

Does Firebase integrate with OwnMailServer?

Yes, through standard SMTP and HTTPS rather than a listed integration. Firebase Auth can send password reset and verification emails through any custom SMTP server, the Trigger Email from Firestore extension accepts any SMTP connection URI, and Cloud Functions can call our REST API with fetch. All three take a few minutes once your sending domain is verified.

Can Firebase Auth send password reset emails through my own SMTP server?

Yes. In the Firebase console, open Authentication, then Templates, then SMTP settings. Turn it on and enter a sender address on your verified domain, smtp.ownmailserver.com, port 587, STARTTLS, any username and an API key as the password. Firebase keeps its own templates and links; we deliver the email and record bounces. Confirm the menu names in your console, since Google moves them occasionally.

Is the Trigger Email from Firestore extension going away?

Firebase says the Extensions service is deprecated and shuts down on March 31, 2027. Installed extensions keep running, but after that date you can't update, reconfigure or uninstall them. If you use Trigger Email today it keeps working, but for a new project a short Cloud Function that calls our API is the safer choice, and this guide includes one.

Do I need the Firebase Blaze plan?

For Cloud Functions and extensions, yes: both need the pay-as-you-go Blaze plan, and functions can't reach outside services without it. Firebase Auth's SMTP setting doesn't depend on Cloud Functions. Firebase's own usage charges are separate from ours, which are $0.20 per 1,000 emails with a $10 monthly minimum.

Can I put the API key in my Firebase web or mobile app?

No. Even a sending-only key can send email as your domain, and a full-access key can also manage your account, so it belongs on the server only. Keep it in Secret Manager through defineSecret, and have the app write a Firestore document or call a callable function instead. Lock that path down with security rules or App Check so strangers can't use your app to send email.

Originally published at ownmailserver.com.

How to turn TradingView alerts into futures orders with a webhook

Hani Khanani — Wed, 28 Oct 2026 14:39:18 +0000

TradingView can't place futures orders at your broker by itself, but every alert can POST a message to a URL. Put a small server behind that URL, have it read the message and call your broker's API, and your alerts become orders. This post covers how TradingView sends webhooks, how to write the alert message, and the problems a receiver has to handle before you trust it with a live account.

How TradingView sends a webhook

When an alert fires and Webhook URL is ticked in the alert's notifications, TradingView sends an HTTP POST to that URL with the alert's Message as the body. As of October 2026, TradingView's help page on webhooks says:

Webhook alerts only work with 2-factor authentication turned on for your TradingView account.
Only ports 80 and 443 are accepted. https://example.com:8443/hook won't work.
If your server takes longer than 3 seconds to respond, the request is cancelled.
If the message is valid JSON, the request has Content-Type: application/json. Otherwise it's text/plain.
IPv6 isn't supported, so your hostname needs an A record.
Requests come from four published IP addresses (52.89.214.238, 34.212.75.30, 54.218.53.128 and 52.32.178.7), which you can allowlist.
Webhooks can occasionally fail to arrive. The alert log has a Webhook status column for checking.

TradingView also says not to put passwords or other credentials in the message body. That matters later.

Writing the alert message

Make the message JSON, so it arrives as application/json and your server can parse it without guessing. A minimal order looks like this:

{
  "action": "buy",
  "symbol": "MNQ1!",
  "qty": 1,
  "orderType": "market"
}

You don't want to hard-code buy and 1 for a strategy that both enters and exits. TradingView fills in placeholders in double curly braces when the alert fires. For a Pine Script strategy(), create the alert on the strategy itself with the trigger Order fills only, and use:

{
  "action": "{{strategy.order.action}}",
  "symbol": "{{ticker}}",
  "qty": {{strategy.order.contracts}},
  "orderType": "market"
}

On each fill, strategy.order.action becomes buy or sell, strategy.order.contracts becomes the number of contracts and ticker becomes the chart's symbol. Leave qty unquoted so it arrives as a number.

These strategy.* placeholders don't exist for an indicator(). There you either write fixed values into each alert, or build the whole message in Pine and send it with alert():

msg = '{"action":"' + (isLong ? "buy" : "sell") + '","symbol":"' + syminfo.ticker +
      '","qty":' + str.tostring(qty) + ',"orderType":"market"}'
alert(msg, alert.freq_once_per_bar_close)

A minimal receiver

Here's the shape of a receiver in Node.js with Express. The secret is in the URL path rather than the body, so each strategy gets its own URL that you can revoke, and placeOrder stands for your broker's API call:

import express from "express";

const app = express();
app.use(express.json());

const seen = new Map(); // body -> time, to drop duplicate deliveries

app.post("/hook/:token", (req, res) => {
  if (req.params.token !== process.env.HOOK_TOKEN) return res.sendStatus(404);

  const { action, symbol, qty, orderType = "market" } = req.body ?? {};
  if (!["buy", "sell"].includes(action) || !symbol || !Number.isInteger(qty) || qty < 1) {
    return res.status(400).json({ error: "bad alert message" });
  }

  const key = JSON.stringify(req.body);
  if (seen.has(key) && Date.now() - seen.get(key) < 5_000) return res.sendStatus(200);
  seen.set(key, Date.now());

  // Answer TradingView first, then trade: the broker call may take longer than 3 seconds.
  res.sendStatus(202);
  placeOrder({ action, symbol, qty, orderType }).catch((err) => console.error("order failed", err));
});

app.listen(3000); // behind a reverse proxy on 443 with a real TLS certificate

It's short, but each line answers one of the problems below.

What a receiver has to get right

The 3-second limit. A broker API call that has to log in, refresh a token or wait for an acknowledgement can easily take longer than 3 seconds. Answer TradingView first and place the order afterwards, or better, put it on a queue with retries. Then log the broker's answer somewhere you'll actually look.

Duplicates. Several alerts can fire on the same bar, and a retry can deliver the same message twice. A receiver that turns every POST into an order will one day double your position. The 5-second window above is the bare minimum. A real one records each order it placed, and the broker's own idempotency key if it has one.

Contract rollover. MNQ1! is TradingView's continuous contract, not something a futures broker can trade. Your receiver has to map it to the current front-month contract, such as MNQZ6, and keep doing that correctly after every quarterly roll. Hard-coding the month works until the day it silently sends orders to an expiring contract.

Exits. "Close my position" is less simple than it sounds. Flattening the whole account also cancels resting orders and closes positions in other symbols that your alert never mentioned. Decide which one you mean, and to exit one symbol, send the opposite side for that quantity.

Brackets. If you send a take-profit and a stop-loss with the entry, they have to be linked as one-cancels-other (OCO) at the broker. Otherwise, when the target fills, the stop is still working and can open a new position the wrong way.

Accounts that stop existing. Prop-firm evaluation accounts get reset, breached or replaced. The alert keeps firing at an account the broker no longer reports, and every order is rejected. If nothing tells you, you find out at the end of the day.

Auth and logging. Use HTTPS, keep the token out of the message body, and log every alert next to the order it produced, or the error it got. When a trade looks wrong, that log is the only way to tell whether TradingView, your receiver or the broker caused it.

Test on a simulated account first. Run the whole path, from alert to fill, on a demo or sim account until the logs match your strategy's trades.

The shortcut: a hosted webhook

If you'd rather not run and maintain that server, this is what we built into Signal Trade App, a futures trade copier for Tradovate, Rithmic, NinjaTrader and ProjectX accounts. You create a webhook token on the Signals page, paste its URL into the TradingView alert, and use the same JSON as above:

{
  "action": "{{strategy.order.action}}",
  "symbol": "{{ticker}}",
  "qty": {{strategy.order.contracts}},
  "orderType": "market",
  "takeProfit": 4550.00,
  "stopLoss": 4490.00
}

It handles the problems above like this:

Continuous symbols such as MNQ1! or ES1! resolve to the current front-month contract, including after rollovers.
takeProfit and stopLoss work with market, limit and stop entries, and the two exit legs are linked as OCO at the broker.
{"action": "close"} flattens the whole account. If you also name a symbol while the account holds a different one, the close is refused rather than closing a position the alert never mentioned.
A token is tied to one account. If the broker stops reporting that account, the Signals page flags the token instead of failing silently.
If the token points at a leader account, the order is copied to its follower accounts with each follower's own ratio and risk limits.

There are limits: one take-profit and one stop-loss per entry, no trailing or breakeven stops from a single webhook, and no OCO between two separate entry orders. For those you'd use the REST API. The TradingView trade copier page has the full setup.

Whichever route you take, keep the alert message as JSON, test on a sim account first, and keep a log of every alert next to the order it produced.

Automated trading can lose money quickly. Nothing here is trading advice.

How to set up Supabase custom SMTP with OwnMailServer

Hani Khanani — Wed, 28 Oct 2026 14:30:53 +0000

Every production Supabase project needs custom SMTP, because the built-in sender only emails your own team and allows 2 messages an hour. To send through OwnMailServer, open your project's Authentication settings, go to SMTP, and enter smtp.ownmailserver.com, port 587, any username and an API key as the password, with a From address on your verified domain. Then raise Supabase's 30-an-hour starting limit to match your volume. It takes about ten minutes.

Approach	Good for	Code
Custom SMTP	Most projects: Supabase's templates, sent from your domain	None
Send Email Hook + our API	Your own templates, languages per user, logging	One Edge Function

Why Supabase needs custom SMTP

Supabase Auth sends email for signup confirmation, magic links, password resets, invitations, email changes and reauthentication. Out of the box it uses a shared sender that, as of October 2026, Supabase documents like this:

It only delivers to addresses in your organization's Team settings. Anyone else gets Email address not authorized.
It allows 2 messages an hour, and Supabase says this can change without notice.
It has no delivery or uptime guarantee.

That's enough to try Supabase, not to run an app. With custom SMTP, sign-in emails come from your domain, signed with your DKIM key, and every bounce and complaint shows up in your dashboard.

What you need before you start

An approved OwnMailServer account with a verified sending domain. The From address must be on that domain, or we refuse the email with 550. The API docs list the DNS records, and the DKIM guide explains them.
An API key, created in your dashboard under API keys & SMTP. Choose Sending only (the default), limited to your sending domain, so the key Supabase stores can't do anything but send. Make one just for Supabase, so you can revoke it without touching your other apps.
Ideally a separate From address or subdomain for auth email, such as no-reply@auth.acme.com. Supabase recommends this too: if a marketing campaign draws complaints, your password resets aren't caught up in it.

Step 1: Enter the SMTP settings

In the Supabase dashboard, open your project, then Authentication, then the SMTP settings, and turn on custom SMTP:

Field	Value
Sender email	`no-reply@auth.acme.com` (on your verified domain)
Sender name	Your app's name, such as `Acme`
Host	`smtp.ownmailserver.com`
Port	`587`
Username	`ownmailserver` (we accept any value)
Password	Your API key

Save. From now on Supabase can email any address. Supabase connects on 587, upgrades with STARTTLS and logs in, which is what we require.

To set the same thing from a script or CI, use Supabase's Management API with an access token from your account settings:

curl -X PATCH "https://api.supabase.com/v1/projects/$PROJECT_REF/config/auth" \
  -H "Authorization: Bearer $SUPABASE_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "external_email_enabled": true,
    "smtp_admin_email": "no-reply@auth.acme.com",
    "smtp_sender_name": "Acme",
    "smtp_host": "smtp.ownmailserver.com",
    "smtp_port": "587",
    "smtp_user": "ownmailserver",
    "smtp_pass": "'"$OMS_API_KEY"'"
  }'

Step 2: Raise the rate limit, in step with warm-up

When you turn on custom SMTP, Supabase sets a deliberately low limit: 30 auth emails an hour. Change it on the Rate Limits page in the Authentication settings.

Two limits now apply, and the lower one wins:

Supabase's hourly limit, which you set.
Our daily warm-up cap. A new account starts at a few hundred recipients a day and rises about 25% after each clean day (how warm-up works). Your dashboard shows today's cap.

If Supabase allows more than our cap, we answer with a temporary 450 and Supabase reports a sending error. So raise Supabase's limit to roughly your cap divided by the hours your users are active, and raise it again as the cap grows. Auth email is usually low volume, so most projects never get close.

Step 3: Test it

const { error } = await supabase.auth.resetPasswordForEmail("jane@example.com", {
  redirectTo: "https://acme.com/update-password",
});

Then search for the address in your OwnMailServer dashboard to see the delivery, or ask the Claude connector what happened to it. If nothing arrived:

You see	Cause	Fix
Supabase: `Email address not authorized`	Custom SMTP isn't saved or enabled	Save the SMTP settings again
`535` / authentication failed	Password isn't a valid API key	Paste the full key, or create a new one
`550`	Sender domain isn't verified, or the account is pending	Finish domain setup in the dashboard
`450`	Warm-up cap or 10 a second reached	Wait, or lower Supabase's rate limit
Supabase: rate limit exceeded	Supabase's own hourly limit	Raise it under Rate Limits

After 5 failed logins from one IP address we block that address for 15 minutes, so fix a wrong password before retrying many times.

Step 4: Edit the templates

Supabase writes these emails, so you change the wording under Authentication, then Email Templates: confirm signup, invite, magic link, change email address, reset password and reauthentication. Templates use Go template variables: put .ConfirmationURL or .Token inside double curly braces.

Keep auth emails plain: a short line, one button, the same link as text, and no tracking or marketing. That's what mailbox providers expect from a password reset, and it's what gets it to the inbox quickly.

Option B: A Send Email Hook that calls our API

If you want your own templates, per-user languages or a record of each send in your database, use Supabase's Send Email Hook. When the hook is on, Supabase stops using SMTP and calls your endpoint for every auth email. You build the email and send it through POST /emails.

Create an Edge Function and its secrets. The hook secret comes from Authentication, then Hooks, when you add a Send Email Hook pointing to the function's URL:

supabase functions new send-email
supabase secrets set OMS_API_KEY=... SEND_EMAIL_HOOK_SECRET="v1,whsec_..."

// supabase/functions/send-email/index.ts
import { Webhook } from "https://esm.sh/standardwebhooks@1.0.0";

const hookSecret = Deno.env.get("SEND_EMAIL_HOOK_SECRET")!.replace("v1,whsec_", "");
const PROJECT_REF = "your-project-ref";

const subjects: Record<string, string> = {
  signup: "Confirm your email",
  magiclink: "Your sign-in link",
  recovery: "Reset your password",
  invite: "You've been invited",
  email_change: "Confirm your new email address",
  reauthentication: "Your confirmation code",
};

Deno.serve(async (req) => {
  const payload = await req.text();
  const headers = Object.fromEntries(req.headers);
  let user, email_data;
  try {
    ({ user, email_data } = new Webhook(hookSecret).verify(payload, headers) as any);
  } catch {
    return new Response(JSON.stringify({ error: { http_code: 401, message: "Invalid signature" } }), { status: 401 });
  }

  const link = `https://${PROJECT_REF}.supabase.co/auth/v1/verify?` + new URLSearchParams({
    token: email_data.token_hash,
    type: email_data.email_action_type,
    redirect_to: email_data.redirect_to,
  });

  const res = await fetch("https://api.ownmailserver.com/emails", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${Deno.env.get("OMS_API_KEY")}`,
      "Content-Type": "application/json",
      // The same hook call retried won't send twice.
      "Idempotency-Key": `supabase-${email_data.token_hash}`,
    },
    body: JSON.stringify({
      from: "Acme <no-reply@auth.acme.com>",
      to: [user.email],
      subject: subjects[email_data.email_action_type] ?? "Message from Acme",
      html: `<p><a href="${link}">Continue</a></p><p>Or enter this code: ${email_data.token}</p>`,
      text: `Continue: ${link}\nOr enter this code: ${email_data.token}`,
    }),
  });
  if (!res.ok) {
    const body = await res.json();
    return new Response(JSON.stringify({ error: { http_code: res.status, message: body.message } }), { status: 500 });
  }
  return new Response("{}", { status: 200, headers: { "Content-Type": "application/json" } });
});

supabase functions deploy send-email --no-verify-jwt

Deploy with --no-verify-jwt: Supabase Auth signs the hook call with the hook secret, not a user's JWT, and the function checks that signature itself.

Two details from Supabase's docs to handle before you rely on it. With Secure Email Change on, an email_change call carries two token pairs, one for each address, and Supabase notes the field names are reversed from what you'd expect, so follow its hook docs for that case. Newer versions of the hook can also send security notifications, such as password_changed_notification; give those their own subject and text rather than the fallback above.

When this isn't the right fit

If your project only sends a handful of auth emails, any SMTP provider with a free tier will do, and Supabase's limits are the real constraint, not cost. We're a good fit when you want auth and app email from one provider on your own domain, with bounces, complaints and warm-up handled for you. The Firebase guide covers the same setup for Firebase, and pay-as-you-go pricing is $0.20 per 1,000 emails with a $10 monthly minimum.

FAQ

Why does Supabase say "Email address not authorized"?

Your project is still using Supabase's built-in email sender, which only delivers to members of your Supabase organization's team. Any other address gets that error. Set up custom SMTP in your project's Authentication settings and Supabase can email anyone. The built-in sender is meant for trying Supabase out, and Supabase says it has no delivery guarantee.

How do I raise Supabase's email rate limit?

Set up custom SMTP first: the built-in sender is fixed at 2 emails an hour. After that, Supabase starts you at 30 emails an hour, which you can raise on the project's Rate Limits page in the Authentication settings. Raise it in steps that match your warm-up cap with us, so the extra email isn't refused during your first weeks.

What SMTP port should I use for Supabase?

Use 587. Supabase connects, upgrades the connection with STARTTLS and then logs in, which is what we require. Port 25 isn't for authenticated sending, and we don't offer 465. If Supabase reports a login error, the password is usually wrong: it must be a full API key from your OwnMailServer dashboard.

Can I change the text of Supabase auth emails?

Yes. Supabase's Email Templates page lets you edit the subject and HTML of each email, such as confirm signup, magic link and reset password, and custom SMTP sends whatever you write there. For full control, such as your own template system or languages per user, use a Send Email Hook and build each email yourself.

Should Supabase auth emails use a separate domain?

It helps. Supabase recommends separate sending domains or From addresses for auth and marketing email, such as auth.example.com and marketing.example.com. Mailbox providers judge each domain's reputation, so a newsletter that draws complaints won't drag your password resets into spam. With us, verify the subdomain as its own sending domain and use it as Supabase's sender address.

Originally published at ownmailserver.com.

How to set up Auth0 custom SMTP with OwnMailServer

Hani Khanani — Wed, 28 Oct 2026 14:30:06 +0000

Auth0's built-in email sender is only for testing, so every production tenant needs its own provider. To send through OwnMailServer, open Branding, then Email Provider, turn on Use my own email provider, choose SMTP, and enter smtp.ownmailserver.com, port 587, any username and an API key as the password, with a From address on your verified domain. Then click Send Test Email. It takes about ten minutes.

Approach	Good for	Code
SMTP	Most tenants: Auth0's templates, sent from your domain	None
Custom Provider Action + our API	Your own logic per message type, retries, logging	One Action

Why Auth0 needs its own email provider

Auth0 sends email for verification, password resets, verification codes, MFA codes, welcome messages, blocked-account notices and organization invitations. Out of the box it uses a built-in sender that, as of October 2026, Auth0 documents like this:

All emails come from no-reply@auth0user.net. You can't change the From address.
It allows 10 emails a minute, of every type together.
You can't use custom email templates.

Auth0 says to use it for testing only. With your own provider, sign-in emails come from your domain, signed with your DKIM key, and every bounce and complaint shows up in your dashboard.

What you need before you start

An approved OwnMailServer account with a verified sending domain. The From address must be on that domain, or we refuse the email with 550. The API docs list the DNS records, and the DKIM guide explains them.
An API key, created in your dashboard under API keys & SMTP. Choose Sending only (the default), limited to your sending domain, so the key Auth0 stores can't do anything but send. Make one just for Auth0, so you can revoke it without touching your other apps.
Ideally a separate subdomain for auth email, such as no-reply@auth.acme.com. Mailbox providers judge each domain's reputation, so a newsletter that draws complaints won't pull your password resets into spam.

Step 1: Enter the SMTP settings

In the Auth0 Dashboard, open Branding, then Email Provider. Turn on Use my own email provider, select SMTP, and fill in:

Field	Value
From	`no-reply@auth.acme.com` (on your verified domain)
Host	`smtp.ownmailserver.com`
Port	`587`
Username	`ownmailserver` (we accept any value)
Password	Your API key

Click Save. Auth0 lists four requirements for an SMTP server, and we meet each one:

Auth0 requires	OwnMailServer
SMTP AUTH with the LOGIN method	LOGIN and PLAIN, after STARTTLS
TLS 1.2 or later	Yes, on port 587
A certificate from a public certificate authority	Let's Encrypt, valid for `smtp.ownmailserver.com`
Accept connections from Auth0's IP addresses	We accept connections from anywhere and check the API key

If you change the host, port or username later, Auth0 asks for the password again, so keep the API key somewhere safe, such as your secrets manager.

To set the same thing from a script or CI, use Auth0's Management API with a token that has the update:email_provider scope. Use POST the first time and PATCH to change it:

curl -X PATCH "https://$AUTH0_DOMAIN/api/v2/emails/provider" \
  -H "Authorization: Bearer $AUTH0_MGMT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "smtp",
    "enabled": true,
    "default_from_address": "no-reply@auth.acme.com",
    "credentials": {
      "smtp_host": "smtp.ownmailserver.com",
      "smtp_port": 587,
      "smtp_user": "ownmailserver",
      "smtp_pass": "'"$OMS_API_KEY"'"
    }
  }'

Step 2: Send a test email

Click Send Test Email on the same page. Then search for the address in your OwnMailServer dashboard to see the delivery, or ask the Claude connector what happened to it. If nothing arrives after a few minutes, check Monitoring, then Logs in Auth0 for a failed send:

You see	Cause	Fix
`535` / authentication failed	Password isn't a valid API key	Paste the full key, or create a new one
`550`	From domain isn't verified, or the account is pending	Finish domain setup in the dashboard
`450`	Warm-up cap or 10 a second reached	Wait; Auth0 logs the failure
`421` too many failed logins	5 failed logins from one IP address	Fix the password, wait 15 minutes
Email still from `auth0user.net`	The provider toggle is off or not saved	Turn on Use my own email provider and save

Step 3: Edit the templates

With your own provider set up, open Branding, then Email Templates to change each email: verification email (link and code), change password, welcome email, MFA enrollment, blocked account and others. Each template has its own From field, which overrides the default, so keep it on your verified domain too. Templates use Liquid: put a variable such as url, user.email or application.name inside double curly braces.

Option B: A Custom Provider Action that calls our API

If you want your own logic, such as logging each send or handling message types differently, choose Custom Provider under Branding, then Email Provider. Auth0 then stops using SMTP and runs an Action on the custom-email-provider trigger for every email, passing the rendered subject, HTML and text. Your Action sends them through POST /emails.

Enter the From address, add your API key as a secret named OMS_API_KEY (the key icon in the editor), and use this code:

exports.onExecuteCustomEmailProvider = async (event, api) => {
  const n = event.notification;

  let res;
  try {
    res = await fetch("https://api.ownmailserver.com/emails", {
      method: "POST",
      headers: {
        Authorization: `Bearer ${event.secrets.OMS_API_KEY}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({
        from: n.from,
        to: n.to,
        subject: n.subject,
        html: n.html,
        text: n.text,
        tags: [{ name: "auth0", value: n.message_type }],
      }),
    });
  } catch (err) {
    api.notification.retry(`Network error: ${err.message}`);
    return;
  }

  if (res.ok) return;
  const body = (await res.text()).slice(0, 500);
  // 429 (rate or daily cap) and 5xx are temporary: Auth0 retries up to 5 times.
  if (res.status === 429 || res.status >= 500) api.notification.retry(`OwnMailServer ${res.status}: ${body}`);
  else api.notification.drop(`OwnMailServer ${res.status}: ${body}`);
};

Save to deploy it, then click Send Test Email. Errors such as an unverified domain (4xx other than 429) won't fix themselves, so the Action drops them and Auth0 logs the reason instead of retrying. The tags value records Auth0's message type with each email, such as reset_email or verify_email, so you can tell them apart later.

An Action is a tenant-wide setting: only one Action can be bound to the custom-email-provider trigger. If you manage Auth0 with Terraform, the auth0_email_provider resource with name = "custom" does the same thing.

Keep auth email within your warm-up cap

A new OwnMailServer account starts at a few hundred recipients a day and rises about 25% after each clean day (how warm-up works). Your dashboard shows today's cap. Verification and reset emails rarely come close. If you're moving an existing tenant with many daily signups, keep the old provider meanwhile and switch Auth0 over once the cap covers a normal day, as described in our migration guide.

When this isn't the right fit

If your tenant only sends a handful of auth emails, any SMTP provider with a free tier will do, and Auth0's 10-a-minute test sender is the real problem, not cost. We're a good fit when you want auth and app email from one provider on your own domain, with bounces, complaints and warm-up handled for you. The Supabase guide and Firebase guide cover the same setup for those platforms, and pay-as-you-go pricing is $0.20 per 1,000 emails with a $10 monthly minimum.

FAQ

Why do my Auth0 emails come from no-reply@auth0user.net?

Your tenant still uses Auth0's built-in email provider. It always sends from no-reply@auth0user.net, allows 10 emails a minute and doesn't let you use custom templates. Auth0 says it is for testing only. Turn on Use my own email provider under Branding, Email Provider, set up SMTP or another provider, and your emails come from your own domain.

What SMTP port should I use for Auth0?

Use 587. Auth0 recommends it because it's the current standard port for sending and supports TLS, and it's the port we offer: Auth0 connects, upgrades the connection with STARTTLS and logs in with the LOGIN method. We don't offer 465, and port 25 isn't for authenticated sending. If Auth0 reports a login failure, the password must be a full OwnMailServer API key.

Does Auth0 need my SMTP server to allow its IP addresses?

Auth0 requires your SMTP server to accept connections from Auth0's IP addresses, and lists them under Branding, Email Provider. Our SMTP server accepts connections from anywhere and checks the API key instead, so you don't need to add anything. A firewall on your side only matters if you run your own mail server.

Can I send Auth0 emails through an API instead of SMTP?

Yes. Choose Custom Provider under Branding, Email Provider and write an Action for the custom-email-provider trigger. Auth0 passes it the rendered subject, HTML and text, and your code sends them with our POST /emails endpoint. The Action can ask Auth0 to retry up to 5 times when we answer with a temporary error.

How many Auth0 emails can I send on a new OwnMailServer account?

A new account starts with a daily cap of a few hundred recipients, and the cap rises about 25% after each clean day. Auth email such as verification and password resets is usually low volume, so most apps stay well under it. If you also send a large welcome email to every new signup, keep that in mind while the cap grows.

Originally published at ownmailserver.com.