Developers

Before you run your own mail server

2 November 2026 5 min read

For most people, running your own mail server isn't a good idea. Installing one is easy, and getting your messages into inboxes is the hard part. Before you start, you should know about four things: whether outgoing port 25 is open, the PTR (reverse DNS) record of your IP address, your SPF, DKIM and DMARC records, and the reputation of your IP address.

Large mailbox providers don't trust mail from a server they don't know. Even a correctly set up new server can land in spam, simply because it has no history. On top of that, the server has to stay up, stay updated and be watched for abuse.

When does it make sense?

Running your own server makes sense for learning, for a few mailboxes on a handful of domains, or when you want your data in your own hands. It doesn't make sense if your business depends on email, if you plan bulk sends such as newsletters, or if you don't have time to watch the server. You also have to back up the mailboxes yourself, because incoming mail sits on the server's disk.

Port 25

Mail servers deliver mail to each other on port 25. To receive mail, the port must be open for incoming connections. To send, it must be open for outgoing ones.
Many networks and providers restrict outgoing port 25 to prevent abuse. At Seturack it also starts closed on new servers, and you open it from your panel in one click.
Mail clients such as phones and Thunderbird use submission ports 587 or 465. These ports can't be used for delivery between servers.

You can test outgoing port 25 on your own server like this. If the output is "25 open", the connection can be made:

timeout 5 bash -c 'exec 3<>/dev/tcp/gmail-smtp-in.l.google.com/25' && echo "25 open" || echo "25 closed"

Sending bulk email to people who haven't asked for it, and building infrastructure for that, breaks Seturack's terms of service.

PTR, SPF, DKIM and DMARC

Receivers use these records to check that a message really comes from you. All of them live in DNS. You set most of them where you manage your domain, but the PTR record is defined by the owner of the IP address. Find out before you order whether your provider lets you set a PTR record for your server. If dig is missing, install it with sudo apt install -y dnsutils.

Record	What it does	Command to check it
PTR (reverse DNS)	Resolves an IP address to a name. Many receivers expect that name to resolve back to the same IP.	`dig -x 203.0.113.5 +short`
MX	Tells senders which server receives mail for your domain.	`dig +short MX example.com`
SPF	Lists which IP addresses may send mail for your domain.	`dig +short TXT example.com`
DKIM	Signs outgoing mail. The public key sits in DNS.	`dig +short TXT selector._domainkey.example.com`
DMARC	Tells receivers what to do when SPF or DKIM fails.	`dig +short TXT _dmarc.example.com`

According to Google's official sender guidelines, all senders must set up SPF or DKIM, the sending IP or domain must have valid forward and reverse DNS (PTR) records, mail must use TLS, and the spam rate must stay below 0.3 percent. Senders who send more than 5,000 messages a day to Gmail accounts must have all three of SPF, DKIM and DMARC.

IP reputation

Every IP address has a history. If the address you were given was abused before, it may be on public blocklists (DNSBLs). Look up your address on those lists before you send. A new address has no reputation. It builds up over time when you start with small volumes and send regular, expected mail. A sudden large burst usually makes a new address look bad at once.

Watch out for IPv6

If your server has IPv6, Postfix may send outgoing mail over IPv6 too. IPv6 needs its own PTR and SPF records. If you haven't set them up, force Postfix to IPv4. The Postfix documentation says this setting needs a restart, and a reload isn't enough:

sudo postconf -e "inet_protocols = ipv4"

sudo systemctl restart postfix

Resources and upkeep

Postfix and Dovecot run comfortably on a small server. Ready-made packages such as mailcow also bring a web interface, a spam filter and virus scanning. mailcow's official requirement is at least 6 GiB of RAM plus 1 GiB of swap in the default configuration. Other options exist too, such as Mail-in-a-Box and iRedMail. Whichever you choose, updates, backups and monitoring are your job.

Checklist before you send

Is outgoing port 25 open?
Is the PTR record set and does it resolve back to the same IP?
Are the SPF, DKIM and DMARC records published?
Is the TLS certificate valid?
Is the IP address on any blocklist?
Did a test message to yourself land in the inbox or in spam?

An easier way

For most projects, the most practical setup is to send transactional mail (password resets, order notifications) through an email delivery service, and to use a hosted mailbox service for your inbox. Your server only runs your application, and getting the mail delivered is left to specialists. If you still want to run your own server, check the records above before you install anything.