All projects

Mail infrastructure

Our own email service — Postfix/OpenDKIM SMTP, DKIM-signed sends and campaigns across domains behind one API key.

Node.jsPostfixDKIM
WebEdge Mailer login screenshotDev-story
01

Challenge

Every product needed to send email — confirmations, alerts, campaigns — and we did not want each one wiring up SMTP, DKIM and a sender reputation on its own.

02

What we did

One mail service: an API that signs with DKIM, manages from-addresses and API keys, and handles transactional sends plus scheduled campaigns with open/click stats and automation triggers. Apps POST to `mailer.webedge.dev/api/v1/send` with a key.

03

Result

The calendar, ePokalbis and other apps send through this one service, and deliverability (DKIM, from-address) is managed in one place instead of per project.

Dev-story article

Mail infrastructure: how the project was built

Every app of ours needs to send email — codes, receipts, alerts, campaigns — and the usual answer is a third-party sender you cannot see into and pay per message. We wanted our own path: a real SMTP stack we run, DKIM-signed and multi-domain, behind a single API so no individual app ever touches SMTP.

Sections

05

Modules

04

Stack

Node.js + Postfix

01

Why the project exists

Every product needed to send email — confirmations, alerts, campaigns — and we did not want each one wiring up SMTP, DKIM and a sender reputation on its own.

Every app of ours needs to send email — codes, receipts, alerts, campaigns — and the usual answer is a third-party sender you cannot see into and pay per message. We wanted our own path: a real SMTP stack we run, DKIM-signed and multi-domain, behind a single API so no individual app ever touches SMTP.

02

What was built

One mail service: an API that signs with DKIM, manages from-addresses and API keys, and handles transactional sends plus scheduled campaigns with open/click stats and automation triggers. Apps POST to `mailer.webedge.dev/api/v1/send` with a key.

It started as an own-SMTP core (Postfix + OpenDKIM + a REST API), grew into a professional v2 service, and then a v3 with multi-domain support, a Vue dashboard and an auth system. Apps hand a message to one API key; the service signs it (DKIM/SPF/DMARC), sends it and records what actually went out, and it sits behind an nginx reverse proxy.

03

Main modules and user path

M01

One API key, one integration point: transactional sends and scheduled campaigns go through the same service, so no app ships its own SMTP credentials or logic.

M02

DKIM-signed and multi-domain: OpenDKIM signs outbound mail per domain, so deliverability and domain reputation are handled centrally rather than per app.

M03

A Vue dashboard and auth system make it operable — domains, sends and campaigns are managed in a UI instead of config files.

M04

It runs behind an nginx reverse proxy with trust-proxy handling, so the service sees real client addresses and stays deployable as normal infrastructure.

04

Architecture and technology decisions

Built with Node.js, Postfix, DKIM.

A Node.js service; Postfix + OpenDKIM for the SMTP and signing layer; a REST API as the single entry point; a Vue frontend and auth for operation; an nginx reverse proxy in front.

05

Result and lessons

The calendar, ePokalbis and other apps send through this one service, and deliverability (DKIM, from-address) is managed in one place instead of per project.

A mailer we own end to end: DKIM-signed transactional email and campaigns across domains behind one API key, so every WebEdge app sends through one controlled, observable path instead of a rented black box.

Read next

These projects share nearby technical or product decisions, so they show how the same principle behaves in another context.

Have a similar idea?

Discuss your project