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.

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

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.