ISPConfig Email Setup: A Beginner's Step-by-Step Guide

A few years ago a client of ours moved their company email to a fresh ISPConfig server. Their team created twelve mailboxes in one afternoon, logged in to webmail, sent test messages to each other, and called the job done. Three weeks later their accounts person asked why customers were ignoring payment reminders. The reminders were not ignored. They were sitting in spam folders, because nobody had published SPF or DKIM records for the new domain. Everything inside the panel worked. Everything outside it was broken.

That afternoon gave me the one line I now repeat to every new engineer: the mailbox is the easy part, the DNS is the product.

This guide walks through ISPConfig email setup the way I wish someone had walked that team through it. Domain, mailbox, password, quota, client settings, DNS, webmail, the mistakes that cost weeks, and the security habits that keep a small mail server out of trouble. I have run my own servers on ISPConfig for five years now, and most of the routine work around them is automated today. But automation only helps when you understand what it is doing. So let us start by hand.

Why a working mailbox is not a working email setup

ISPConfig is a free, open source hosting control panel that manages websites, email, DNS and databases on a Linux server through one web interface. Under the hood it configures Postfix to send and receive mail, Dovecot to serve IMAP and POP3, and Rspamd or Amavis to filter spam. When you click Save, the panel writes the right lines into those programs for you. That part is reliable. I have rarely seen it fail.

Here is the catch. Whether your message lands in an inbox is not decided by your server. It is decided by the receiving server, and that server asks two questions: is this domain really allowed to send from this machine, and has this message been tampered with? Both answers live in DNS, which sits outside the mail form, often outside ISPConfig entirely, at your registrar or at Cloudflare. The panel cannot show you green for something it does not control.

Think of a mailbox as a post office box. Creating the box is a form. Getting the postman to find it, and getting other post offices to accept letters stamped with your name, is a separate piece of work. In 2026 that second piece is no longer optional, because the big receivers have turned their recommendations into rules.

Where the usual ISPConfig tutorials stop too early

Most guides on the internet are excellent at building the server. The HowtoForge "Perfect Server" series is the reason many of us run ISPConfig at all, and I still send people there for installation. But those guides were written for administrators who already understand DNS, so they end at roughly the point where a beginner's problems begin: "add your domain and mailbox, and you are done."

The panel's defaults do not help. A new mailbox ships with a quota of 0, which means unlimited. The spam filter policy is "not enabled". The DKIM box on the mail domain is unticked. Each default is sensible for a test machine and risky for a business, and nothing on the screen tells a first-time user which is which.

So treat the framework below as the chapter those installation guides assume you have already read.

The seven-step ISPConfig email setup I use today

What do you need before creating a mailbox in ISPConfig?

A domain whose DNS records you can edit comes first, then a mail server hostname such as mail.example.com with an A record and a valid TLS certificate, an ISPConfig login whose client owns that domain, and a password manager to store what you are about to generate. Those four things are the whole checklist, and without the DNS access the rest of this guide cannot be finished.

Check the hostname first. Open the ISPConfig server's address in a browser and look at the certificate. The name on that certificate is the name you will give to every email client later, and if it does not match, every phone in the company will show a security warning on the first day.

Step 1: Add the mail domain

In the panel, open the Email tab, choose Email Domain in the left menu, and click Add new Domain. Pick the server, pick the client, type the bare domain (example.com, not mail.example.com), and tick Active. Now tick Enable DKIM, leave the selector as "default", and click the button to generate a private key. A grey box appears underneath showing a long TXT record. Copy it into a text file now. You will need it in step 5, and people who plan to "come back for it later" are the people whose reminders go to spam.

Step 2: Create the mailbox

Go to Email Mailbox and click Add new Mailbox. Type the person's real name, type the part before the @ sign, and choose the domain from the dropdown. You will only see domains you added in step 1, which is why the order matters. One mailbox per human. For role addresses such as sales@ or support@, use Email Alias to point them at a real person's mailbox instead of creating more boxes; fewer passwords means fewer things to leak.

Step 3: Set the password and the quota

Click the Generate Password link rather than inventing one. ISPConfig produces a random string and shows a strength meter; I never accept anything under 16 characters. Then the quota, in megabytes. Here I will disagree with common advice. Many administrators leave it at 0 because "disk is cheap". I think that is wrong. A quota limits the damage when one account is compromised and starts receiving or storing junk; the price of disk has nothing to do with it. On our servers staff mailboxes get 2048 MB and accounts mailboxes get 5120 MB, numbers we arrived at by watching usage for a year, not by theory.

On the same form, set the spam filter policy to Normal, and tick Disable POP3 unless someone genuinely needs it. Save.

Which SMTP and IMAP settings do ISPConfig mailboxes use?

An ISPConfig mailbox uses the full email address as the username, the mail server hostname as both the incoming and outgoing server, port 993 with SSL/TLS for IMAP, and port 587 with STARTTLS or port 465 with SSL/TLS for SMTP. Outgoing mail requires authentication with the same username and password. POP3, where enabled, uses port 995.

Step 4 is this card, which I hand to every new joiner. RFC 8314, published in January 2018, recommends implicit TLS on 465 and 993 over the older plain-then-upgrade ports, and modern clients such as Outlook, Apple Mail and Thunderbird accept either.

Step 5: Publish the DNS records: MX, SPF, DKIM and DMARC

Back to the post office. The MX record is the signboard that tells other mail servers where your letters should be delivered; it points at mail.example.com with a priority of 10. SPF is the list of postmen allowed to carry letters with your name on them. DKIM is a wax seal that proves a letter was not opened on the way. DMARC is your instruction for what receivers should do with a letter that fails the first two.

If ISPConfig also hosts your DNS, open the DNS tab, find the zone, and add records of type MX, TXT, DKIM and DMARC. The DKIM record type in ISPConfig reads the public key from the mail domain you created in step 1, so you do not have to paste it by hand. If your DNS lives at the registrar or at Cloudflare, add the same four records there and paste the DKIM text from step 1 as a TXT record named default._domainkey.

For SPF, keep it short. According to RFC 7208, a receiver may perform at most 10 DNS lookups while evaluating your record, and a record that exceeds the limit returns a permanent error, which is worse than no SPF at all. For a single ISPConfig server, "v=spf1 mx a ~all" does the job. For DKIM, RFC 8301 requires signing keys of at least 1024 bits and recommends 2048, and the key ISPConfig generates meets that. Start DMARC at "v=DMARC1; p=none; rua=mailto:dmarc@example.com" and tighten it to quarantine after a month of clean reports.

Why bother with all four? Because the receivers have stopped asking nicely. Google's sender guidelines, updated for February 2024, require SPF, DKIM and DMARC from anyone sending 5,000 or more messages a day to Gmail, and the same Google guidance tells smaller senders to set up SPF or DKIM at minimum. Yahoo published matching rules at the same time. A small company does not send 5,000 messages a day, but it does send invoices to people who use Gmail.

Step 6: Open webmail and send the first test

ISPConfig usually ships with Roundcube webmail, reached at the mail server hostname followed by /webmail, though some installations place it on port 8080 or on each website's domain. Ask whoever installed the server which path they chose, then log in with the full address and the generated password. If login works here but fails in Outlook, the problem is the client settings, not the mailbox. That single distinction saves hours of guessing.

Step 7: Verify from the outside

Send one message from the new mailbox to a Gmail account you control. Open it in Gmail, choose Show original, and read the three lines at the top: SPF, DKIM and DMARC should each say PASS. This takes two minutes and it is the only test that matters. Had the client in my opening story done this once, they would have saved three weeks and several awkward phone calls.

Common ISPConfig email mistakes and how to avoid them

• Giving clients the domain name (example.com) as the mail server instead of the hostname on the certificate, which produces a security warning on every device.
• Creating the mailbox before the mail domain exists. The domain dropdown is empty and people assume the panel is broken.
• Pasting the DKIM key with line breaks or quotation marks included. Copy from the panel into a plain text editor first, then into DNS as one unbroken string.
• Forgetting the reverse DNS (PTR) record for the server IP. ISPConfig cannot set it; your hosting provider does, and several large receivers reject mail from an IP without one.
• Testing only in webmail.
• Leaving spam filtering off "for now" and discovering a month later that the sales mailbox has 9,000 unread messages.

Security habits for a small mail server

Mail servers are attacked constantly because a stolen mailbox is valuable: it resets passwords everywhere else. Verizon's 2024 Data Breach Investigations Report found that stolen credentials appeared in 31% of the breaches it analysed over the previous ten years, and that 68% of breaches involved a human element such as a phished or reused password. For a mail server the lesson is direct: the password is the perimeter.

Four habits cover most of the risk. Generate every password and store it in a shared vault, never in a chat message or a spreadsheet. Keep the panel's TLS-only defaults, so no password ever travels in plain text. Watch the authentication log and block IPs that fail repeatedly; fail2ban does this well with Dovecot and Postfix. And set your DMARC policy to quarantine once reports are clean, so that if someone spoofs your domain, receivers already know what to do.

One rule on my team has no exceptions: nobody receives a server or mailbox password over chat. When a developer needs to get into a machine, the credential is fetched by a tool on their behalf and the session is logged. They never see it. This sounds strict until the first time an ex-contractor's laptop goes missing.

What five years of automating ISPConfig taught me

Before we automated anything, one of my developers spent most of a Friday creating mailboxes for a client's new office, one form at a time, pasting each password into a document that was then emailed to the client. Every step above, done twenty times, with a human copying strings between screens. He did not make a mistake. But he could have, and the Friday was gone.

ISPConfig has a remote API that exposes almost everything the panel does, including mail domains, mailboxes, aliases and DNS zones. That is where our automation lives today. One action creates a website's domain, its Let's Encrypt certificate, its shell user and its database; by our own measurement it takes about three minutes against the better part of an afternoon by hand. DNS records are checked and written at the registrar through its API, so an SPF record cannot be duplicated by accident. Credentials are generated, encrypted and stored in a vault, and handed to the person or process that needs them without ever appearing in a chat window.

The piece my team uses most is an SSH utility. Type the name of any ISPConfig domain and it opens a shell on the right server as the right user, fetching the credential server-side and logging the session for audit. We exposed the same capabilities through a Model Context Protocol server, which means an AI coding tool such as Claude Code can do the work by sentence: provision a domain, add a database, or guide a junior engineer through a task on a remote server, without the engineer or the AI ever seeing a password. The same remote API can create fifty mailboxes from a spreadsheet in one run, with quotas, spam policies and DKIM set the way this guide describes.

The widely held view is that a good control panel removes the need for automation. I think the opposite is true. The panel is what makes automation safe, because it gives you a single, consistent API instead of a dozen hand-edited config files.

If your company runs ISPConfig and you want this kind of customisation, write to my team at IndiaNIC or at hello@indianic.com. We already have the automations, the MCP tools and the SSH utility; adapting them to your servers is a short project.

And one question for you before you close this tab: which of the seven steps does your current email setup skip? Find out this week, because the answer is probably sitting in a spam folder somewhere. Tell me in the comments, or take the question to your team on Monday.

Frequently asked questions

How do I create an email account in ISPConfig?

In ISPConfig, open the Email tab, add the mail domain under Email Domain with DKIM enabled, then go to Email Mailbox and click Add new Mailbox. Enter the name, the address, a generated password of at least 16 characters and a quota in megabytes, set the spam filter policy, and save. Then publish MX, SPF, DKIM and DMARC records in DNS.

Why does my ISPConfig email go to spam?

Missing SPF or DKIM records, two SPF records on one domain, or a server IP with no reverse DNS entry are the usual reasons ISPConfig email lands in spam. Send a test to Gmail, open Show original, and check that SPF, DKIM and DMARC all say PASS. Fix whichever fails, and allow up to 24 hours for DNS changes to spread.

Can ISPConfig mailbox creation be automated?

Yes. ISPConfig exposes a remote API covering mail domains, mailboxes, aliases and DNS zones, so mailboxes can be created from a spreadsheet or a script with quotas, spam policies and DKIM set consistently. Teams that use AI coding tools can wrap the same API in an MCP server and run these tasks by typing a sentence, with credentials brokered rather than shared.