Email deliverability & sending — Docs

Nimbopanel runs a full mail stack (Postfix, Dovecot, OpenDKIM) for your customers. Receiving email works as soon as your DNS is set. Sending to the outside world needs one extra step on almost every budget VPS — this is the part people most often get stuck on, so it's worth understanding.

Receiving works out of the box

Once you've added the mail DNS records (below), your server accepts mail for your hosted domains, stores it, and serves it over secure IMAP (port 993) and webmail. Nothing else is needed to receive.

Publish these records at your DNS host (Nimbopanel generates them automatically in each account's zone — copy the values into Cloudflare / your registrar):

Type	Name	Value
MX	`@`	`mail.yourdomain.com` (priority 10)
TXT	`@`	`v=spf1 mx a:mail.yourdomain.com ~all` (SPF)
TXT	`_dmarc`	`v=DMARC1; p=none; rua=mailto:postmaster@yourdomain.com`
TXT	`<selector>._domainkey`	the DKIM public key shown in the panel's Email tool

Your own domain — the one the panel itself sends from (receipts, alerts, how-to-pay emails) — usually has no hosting account. Open System → Mail deliverability and click Publish mail records: the panel writes these records into its own DNS zone and turns on DKIM signing in one step. If that domain's DNS is hosted elsewhere, the same button shows you the exact values to add there.

First: find out whether you need a relay at all

Delivery to a recipient's mail server always uses port 25 — that is the SMTP standard, not a setting — and many providers block it outbound to stop spam. It is on the provider's network, not your server, so you cannot turn it off yourself, even as root. When it is blocked, messages sit in the queue for days and then bounce, which looks exactly like "sent, but never arrived".

The panel measures this rather than assuming it. Open the admin System page and read the Outgoing mail card. It says one of four things:

The card says	What it means
port 25 is open	This server can deliver directly. A relay is optional — set one up only if you want a delivery service's reputation instead of this server's IP.
sent through a relay	A relay is configured and in use.
This server cannot deliver email to the internet	Port 25 is blocked. Everything sent to an outside address will bounce. Set up a relay below.
Could not determine whether port 25 works	The check itself could not finish. Read the detail line; do not treat this as "fine".

You do not have to go looking for it. When the server cannot deliver, a banner appears at the top of every page in the panel with a Set up a relay button — because from inside the panel a blocked send looks exactly like a successful one, and nobody opens a settings card they have no reason to suspect.

The verdict is decided over IPv4, because that is where a provider's filter lives. A dual-stack server can reach a mail host over IPv6 while being entirely unable to deliver in practice, and that is exactly the false "healthy" reading this check exists to avoid.

Do not assume your provider blocks it because of its reputation. Measured on a Contabo server in August 2026, port 25 was open — the long-standing claim that they block it did not hold for that machine. Read the card.

If it is blocked

There are two ways around it:

Ask your provider to unblock port 25 — some will, after your account ages or you open a ticket explaining you run a mail server. Best if they allow it, and pair it with a custom rDNS/PTR (see Provider notes). But many providers won't lift it quickly.
Use an SMTP relay — mail goes out through a reputable provider on port 587 (which is not blocked), from IPs with good reputation. This is the recommended, self-service path — it works today without waiting on your provider, and usually delivers better than sending directly from a cheap VPS IP anyway.

Set up a relay (recommended)

1. Pick a relay provider and create an account:

Provider	Free tier	Notes
Brevo	300 emails/day, no card	Easiest to start
SendGrid	100/day	Simple SMTP
Amazon SES	pay-as-you-go (cheapest at scale)	Needs domain verification + leaving the sandbox

Volume note: transactional relays are meant for your mail. If you'll relay large volumes of many customers' mail, use a provider that permits it (e.g. SES set up correctly) or get port 25 unblocked.

2. Get the SMTP credentials from the provider's dashboard — the SMTP tab (not the "API keys" tab):

SMTP server (e.g. smtp-relay.brevo.com)
Port 587
Login (this is a specific SMTP login the provider shows — often not your account email)
SMTP key / password

If your provider has an "authorized IPs" security setting, add your server's IP to it, or SMTP authentication will be refused.

3. Enter them in the panel. The same Outgoing mail card has the form. Pick your provider from the Relay provider dropdown — Brevo, SendGrid, Mailgun, Amazon SES, Gmail / Google Workspace, or Another server I own — and the host, port and SPF value fill in, along with a note about what that provider expects as a username. (SendGrid's is literally the word apikey; Gmail needs an App Password, not the account password.)

Then press Test & save relay. It authenticates against the relay before saving anything. If the relay refuses the credentials you are told so and nothing is changed — you cannot end up with a saved relay that has never worked.

Two things about the password: it is handed straight to the mail server and never stored in the panel's database, so it cannot be read back, and you must retype it on every change. Turn relay off removes it again.

You do not need root or a text editor for any of this.

Make mail land in the inbox (not spam)

Getting mail out is step one; getting it into the inbox needs authentication that the recipient (Gmail, Outlook) can verify:

SPF — mail sent through a relay leaves from the relay's IPs, so the relay has to be named in your SPF record. Saving a relay rewrites the SPF record of every hosted domain for you — that is what the SPF include field on the form is for, and it is prefilled from the provider you chose. This is the step that most often gets missed when a relay is configured by hand, and the one that decides whether relayed mail is trusted.
DKIM — Nimbopanel signs your domains with its own DKIM key automatically, and publishes the record. If your relay also asks you to verify the domain in its dashboard, add the DKIM records it gives you alongside.
DMARC — Nimbopanel publishes a safe p=none DMARC record per domain; you can tighten it later.

With SPF, DKIM, and DMARC all passing, your customers' mail is trusted and lands in the inbox. A message that made it all the way shows status=sent in the mail log, and a real recipient's headers read dkim=pass spf=pass dmarc=pass.