DEV Community: EQVPS

Running a mail server on a VPS: what actually keeps you out of spam

EQVPS — Sat, 04 Jul 2026 09:15:59 +0000

Your mail server works. Postfix starts, the logs look clean, you send a test message to your Gmail — and it lands in spam. Or it just disappears. Nothing in your config is broken. The software did exactly what you told it to.

The problem is that the server on the other end doesn't trust your IP yet, and email hides a whole stack of small trust checks that all have to line up before a stranger's inbox lets you in. Get those right and delivery mostly takes care of itself. Miss one and you're shouting into a spam folder.

Three things carry most of the weight: reverse DNS, sender authentication, and whether your host even lets you talk on port 25. None of them are hard. They're just easy to forget, and each one is a quiet veto.

The one everyone forgets: reverse DNS

Forward DNS is the part you know — a name points to an IP. Reverse DNS is the mirror: an IP points back to a name. That record is called a PTR, and it lives with whoever controls the IP, not in your domain's zone.

Here's why it matters. When your server opens a connection to Gmail's SMTP, one of the first things the receiving side does is a reverse lookup on your IP — who is this? Run it yourself:

dig -x 203.0.113.19 +short

If that comes back with something like static.203-0-113-19.rev.example-isp.net, or comes back empty, you've already lost points. That generic name says "some random VPS," and worse, it doesn't match the hostname your server introduces itself as in the HELO greeting. Receiving servers flag that mismatch hard. Some reject outright.

What they want to see is a PTR that matches your mail hostname. If your server says HELO mail.example.com, the reverse lookup on its IP should return mail.example.com. Forward and reverse agree, the story is consistent, and you look like a real mail server instead of a hijacked box.

Setting a PTR has traditionally meant opening a support ticket with whoever owns the IP block and waiting. On EQVPS dedicated-IP plans it's a field in your dashboard — type the hostname, it writes straight to the registry through the provider's API, and it's live in seconds. That's the whole point of doing it self-serve: reverse DNS is the step people skip because it used to be annoying.

Authentication: SPF, DKIM, DMARC

These three DNS records tell receiving servers that mail claiming to be from your domain really is. Skip them and you're an unverified stranger.

SPF is a TXT record listing which servers are allowed to send for your domain. Gmail checks it and asks: did this message come from an IP you authorized?
DKIM cryptographically signs each outgoing message. The receiver pulls your public key from DNS and verifies the signature wasn't forged in transit.
DMARC ties the two together and tells receivers what to do when a check fails — nothing, quarantine, or reject — and where to send reports.

You want all three. SPF and DKIM prove the mail is legitimately yours; DMARC turns that proof into a policy. It's maybe twenty minutes of DNS edits, and it's the difference between "verified sender" and "who?"

Port 25, and why it's shut

Here's the one that surprises people. Outbound port 25 — the port mail servers use to talk to each other — is blocked by default on essentially every VPS host. Us too.

That's deliberate. Port 25 is the classic spam cannon, so it stays closed until you ask for it and say what you're actually sending. We open it per request rather than leaving it open for anyone who spins up a server.

And there's an honest caveat here worth stating plainly: with an open port 25 comes responsibility. One compromised script or a misconfigured relay pumping out spam, and your IP's reputation is gone — sometimes for weeks. On a shared subnet that mess splashes onto your neighbors, which is exactly why hosts are cautious about it. If you ask us to open 25, keep your server clean, because the reputation you're protecting is partly ours too.

Why the dedicated IP isn't optional

All of this circles back to one requirement: the IP has to be yours. On a NAT setup or a shared address you can't set your own PTR, because the address isn't exclusively yours to point. You also inherit whatever reputation the shared IP already carries — and you have no idea what the last tenant did with it.

A dedicated IP gives you a PTR you control, a reputation that's yours to build, and a clean starting point. For outbound mail that's not a nice-to-have; it's the floor.

The honest bottom line

Self-hosting email in 2026 is real, ongoing work. It's not set-and-forget — you'll watch blocklists, rotate DKIM keys, and occasionally figure out why one specific provider started greylisting you. If this is a low-stakes side project, honestly, forwarding through an existing mail provider will save you headaches.

But if you want actual control — your data, your domain, nobody else reading the headers — it's very doable on a small VPS. The trust plumbing above is about 90% of the battle, and none of it is exotic. Get a dedicated IP, set the PTR to match your hostname, publish SPF/DKIM/DMARC, ask us to open port 25, then send a test through a tool like mail-tester.com and fix whatever it flags. Do that and you're not shouting into a spam folder anymore — you're a mail server people's inboxes actually trust.

FAQ

Do I need a dedicated IP to run a mail server?

Effectively yes. Deliverability depends on a reverse DNS (PTR) record that matches your mail hostname, and you can only set a PTR on an IP that is exclusively yours. On a shared or NAT address you don't control the PTR, so receiving servers see a generic or mismatched hostname and treat you as suspicious. A dedicated IP is the baseline for outbound mail.

What is a PTR record and why does email need it?

A PTR record is reverse DNS — it maps your IP back to a hostname, the opposite of a normal A record. When your server connects to Gmail or Outlook, the receiving side looks up who owns your IP. If the PTR is missing or generic (like static.203-0-113-19.rev.example-isp.net), that's an immediate strike against you. Mail servers expect the PTR to match the name your server announces in HELO.

Why is outbound port 25 blocked by default on most VPS hosts?

Port 25 is the single biggest spam vector, so hosts keep it closed until you ask and explain what you're sending. It's not a bug — it's abuse prevention. One compromised script blasting spam can burn an IP's reputation, and on a shared subnet that damage spills onto other customers. Reputable hosts, EQVPS included, open it per request rather than by default.

Can I run a mail server on a NAT or shared IP?

You can receive mail through port forwarding, but sending reliably is another story. Without your own IP you can't set a matching PTR, and you inherit whatever reputation the shared address already has — good or bad. For anything you need delivered, use a dedicated IP with a clean history and a PTR you control.

Is self-hosting email actually worth it in 2026?

It depends on why. If you want control over your data and your domain with no third party in the loop, it's very doable on a small VPS. But deliverability is ongoing work — you watch blocklists, rotate DKIM keys, and keep the IP clean. For a low-stakes side project, forwarding through an existing provider is less pain. Self-host when control matters more than convenience.

Self-host n8n on a VPS with Docker

EQVPS — Thu, 25 Jun 2026 09:12:20 +0000

n8n is the kind of tool you start using lightly and then quietly route half your operations through. At which point "it's running on someone's cloud seat, metered per execution, with my API keys living on their servers" starts to feel less great. Self-hosting fixes all three — flat cost, no execution cap, and your keys stay on a box you own. With Docker it's a fifteen-minute job.

How much server it actually needs

Honest numbers first, so you don't over- or under-buy:

~2 GB RAM is the sweet spot — n8n plus its Postgres database plus normal workflows sit comfortably here.
1 GB works if your workflows are light, but you'll notice it on bigger runs.
4 GB if you do heavy parallel executions or push large payloads through.

n8n isn't CPU-hungry at rest; it spikes during runs. A 2-core box is fine for most setups. (More on matching specs to workload in the sizing guide.)

The Docker setup

On a fresh Ubuntu/Debian box, install Docker:

curl -fsSL https://get.docker.com | sudo sh

Make a folder and a docker-compose.yml — n8n with a persistent volume and Postgres:

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: always
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - N8N_HOST=n8n.yourdomain.com
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.yourdomain.com/
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=db
      - DB_POSTGRESDB_PASSWORD=change-me
    volumes:
      - ./n8n-data:/home/node/.n8n
    depends_on: [db]
  db:
    image: postgres:16
    restart: always
    environment:
      - POSTGRES_PASSWORD=change-me
      - POSTGRES_DB=n8n
    volumes:
      - ./db-data:/var/lib/postgresql/data

sudo docker compose up -d

Two things worth pointing out: the volumes (n8n-data, db-data) are what keep your workflows alive across restarts and upgrades — don't skip them. And n8n is bound to 127.0.0.1, not 0.0.0.0 — it's not exposed to the internet directly. That's deliberate; the next step handles access safely.

Access: HTTPS or a tunnel

Public URL (needed for OAuth nodes and webhooks): point a subdomain at the server and run a reverse proxy (Caddy is the least-effort — automatic HTTPS) in front of 127.0.0.1:5678. This is where a dedicated-IP plan fits, since you control ports and DNS.
Just for yourself, no domain: skip the proxy and reach it over an SSH tunnel — ssh -L 5678:127.0.0.1:5678 user@server, then open localhost:5678. Works fine on a NAT VPS.

Lock it down and keep it up

n8n holds your API keys and credentials, so the box must be tight: do the security checklist (SSH keys, firewall, no password login) before you put real credentials in. restart: always in the compose file already means Docker brings n8n back after a crash or reboot — that's your uptime handled.

Is it worth it?

Be honest with yourself about volume. If you run automations constantly, self-hosting wins on cost (flat vs per-execution) and removes any workflow/run limits. If you trigger a few flows a month, a hosted seat is less hassle. But the control argument stands regardless: your workflows, your data, your keys — on your server, not rented. For most people who got serious about n8n, that's the deciding factor.

A 2 GB box, a compose file, a domain (or a tunnel), and you're running your own automation hub — payable in crypto with no KYC, live in minutes.

FAQ

How much RAM does self-hosted n8n need?

Around 2 GB is the comfortable sweet spot for n8n plus its Postgres database and normal workflows. It runs in 1 GB if workflows are light, but you'll feel it during bigger runs. Heavy parallel executions or large payloads — go to 4 GB.

Do I need Docker to self-host n8n?

It's by far the easiest way — one compose file gives you n8n, a database and persistent storage, and upgrades are a single pull. You can install via npm instead, but Docker saves you the dependency and upgrade headaches.

Is self-hosting n8n cheaper than n8n cloud?

If you run a steady stream of automations, yes — a flat monthly VPS beats per-execution pricing, and there's no workflow or execution cap. For a handful of runs a month, a hosted seat may be simpler. The other reason people self-host is control: your data and API keys never leave your server.

Do I need a domain for n8n?

For OAuth-based nodes (Google, etc.) and clean HTTPS, yes — point a domain at the server and put n8n behind a reverse proxy with a certificate. For purely internal use you can reach it over an SSH tunnel without a domain.

Can n8n run on a NAT VPS or do I need a dedicated IP?

Internal/SSH-tunnel use works on a NAT box. If you want a public URL with your own domain and HTTPS (needed for some OAuth callbacks and webhooks), a dedicated-IP plan is the cleaner fit since you control all ports.

Originally published at eqvps.com.

How an AI agent buys and runs its own server over MCP

EQVPS — Wed, 24 Jun 2026 11:54:21 +0000

An AI agent can write a scraper, debug it, and tell you exactly where to deploy it. Then it stops. Because the next step — actually renting the server — almost always needs a human: open an account, maybe pass an identity check, type a card number into a checkout. The agent did the hard part and now waits on you for the boring part.

That gap is the whole reason this exists. We took the human out of the middle.

Where autonomy usually breaks

Think about what "renting a server" really involves on a normal host. A signup form. An email to confirm. Billing details, sometimes ID. A card at checkout. A dashboard to find the IP. Every one of those assumes a person sitting there.

An agent can't sit there. It can call an API, hold a token, make decisions — but it can't receive a verification email or pull out a credit card. So the moment infrastructure enters the picture, the autonomous workflow turns back into a human workflow with extra steps. You wanted an agent that ships; you got an agent that files a ticket.

The flow, end to end

On EQVPS the same actions are MCP tools (16 of them) plus a REST API — and crucially, the agent can get its own credentials. Here's the actual sequence:

// 1. Get an account — token comes back immediately, no email, no human
register_account({ first_name: "Ada", last_name: "Agent", email: "ada@example.com" })
//    → { token: "..." }   send it as Authorization: Bearer <token> from here on

// 2. See what's available
list_plans()
//    → plans with specs, prices, and OS image ids

// 3. Make sure there's money on the balance
get_balance()
//    → { balance: 25, currency: "USD" }

// 4. Order — this debits the balance and provisions the box
order_vps({ product: "nano", os_id: 1, hostname: "ada-worker" })
//    → { service_id, paid_from_balance: true }

// 5. Read the keys to its own new server
get_vps_status({ service_id })
//    → { ip, ssh_port, password }   ~60 seconds after ordering

Five calls and the agent is SSH'd into a machine it rented itself. No dashboard, nobody approving each step. If you'd rather drive it from plain HTTP, the same endpoints exist over REST — MCP or REST, your call.

The honest part: what's automated, what isn't

Ordering is fully autonomous. Funding the balance isn't — not yet. Right now someone puts crypto on the balance once (USDC/USDT, or a card on-ramp), and from that point the agent orders, scales and cancels on its own, spending only what's there.

The end state everyone pictures — an agent paying on-chain, per request, with no pre-funding — is the x402 style, and we think it's where this goes. We haven't wired it up. It needs USDC-settled rails and a few things we don't run today, so rather than slap "fully autonomous payments" on the box, here's the truth: autonomous ordering now, autonomous funding later. The prepaid balance is the bridge, and honestly it doubles as a spend cap you probably want anyway.

A couple of real details

The MCP server speaks Streamable HTTP at https://mcp.eqvps.com/mcp, so it drops into any MCP client without a local shim. Auth is a Bearer token the agent mints itself with register_account — the same token works across MCP and REST, against the same account and balance. Sessions are tracked server-side, so a long-running agent can hold one connection and keep calling tools.

One practical note from running this: treat the token and the returned root password like the secrets they are. The agent should store them, not echo them into logs or chat. The balance caps the financial blast radius; basic secret hygiene caps the rest.

Why it matters

For now most of our actual customers are humans who happen to like paying in crypto — we're not going to pretend the web is overrun with autonomous agents buying servers. But the direction is clear. As agents take on longer, real tasks, "can it get and run its own infrastructure?" stops being a party trick and becomes a requirement. When that day fully arrives, the rails need to already be there.

They are. Add the MCP server to your agent — start with connecting an MCP client — fund a small balance, and let it rent its first server. About a minute to root.

FAQ

Can an AI agent really buy a server on its own?

Yes — the ordering part is fully autonomous. Over our MCP server the agent calls register_account to get a token, then order_vps, which spends from a prepaid balance and provisions the VPS. It reads back SSH access from get_vps_status. No human clicks through a checkout. The one thing a human (or a funded agent wallet) does first is put crypto on the balance; after that the agent runs on its own.

How does the agent pay?

From a prepaid balance. You fund it once with USDC or USDT (or a card via the on-ramp), and order_vps debits that balance per order. The agent never holds your wallet keys, and it can't spend more than what's on the balance — which is also your safety cap.

What is MCP provisioning?

MCP (Model Context Protocol) lets an agent call tools directly inside clients like Claude, Cursor or Cline. 'MCP provisioning' just means the whole rent-a-server flow — register, pay, order, get root — is exposed as MCP tools the agent calls itself, instead of a web dashboard a person clicks.

Is this fully hands-off?

Ordering is. Funding isn't quite there yet: today someone tops up the balance with crypto, and then the agent is autonomous. Fully on-chain per-request payment (the x402 style) is on our radar but not wired up — we'd rather say that plainly than pretend.

What does the agent need to get started?

Just the MCP server URL (https://mcp.eqvps.com/mcp) added to its client. It calls register_account and gets a Bearer token in the response — no email confirmation, no human step. From there every action is a tool call.

Originally published at eqvps.com.