Setting up your own mail server gives you complete control over your email infrastructure instead of depending on a third party mailbox provider. This guide shows you how to configure postfix and dovecot together with Roundcube webmail on a Centos 7 VPS, covering everything from DNS records through to a working browser based inbox secured with a real SSL certificate. Whether you are building a small business mail server or simply want to learn how professional email infrastructure works, this walkthrough will take you through every step needed to configure postfix and dovecot correctly the first time. 

This 2026 edition merges what were previously two separate posts into a single guide, and it corrects several package and version details that no longer work on a real Centos 7 server today. If you have tried to configure postfix and dovecot using an older guide and hit repository errors or broken PHP extensions, the notes throughout this guide explain exactly why, and what to use instead. Mail servers are unforgiving of small mistakes, a single wrong DNS record or a missing firewall rule can mean mail silently fails to deliver, so this guide is deliberately thorough about the reasoning behind each step rather than just listing commands to copy. 

A Note on Centos 7 Before You Begin 

Centos 7 reached its official end of life on June 30, 2024, and its default package mirrors were taken offline shortly after. Before you can install anything, including the packages needed to configure postfix and dovecot, you need to redirect yum to the Centos Vault, an archive of the final released packages. 

# Back up existing repo files 
sudo mkdir -p /etc/yum.repos.d/old 
sudo mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/old/ 2>/dev/null 
 
# Point yum at the CentOS Vault archive instead of the dead mirrors 
sudo sed -e 's/mirror.centos.org/vault.centos.org/g' \ 
         -e 's/^#.*baseurl=http/baseurl=http/g' \ 
         -e 's/^mirrorlist=http/#mirrorlist=http/g' \ 
         -i /etc/yum.repos.d/old/CentOS-Base.repo 2>/dev/null 
 
sudo yum clean all 
sudo yum makecache 

Once yum makecache completes without 404 errors, you are ready to configure postfix and dovecot on your server. Since Centos 7 no longer receives security patches, treat this setup as suitable for testing, learning, or an existing legacy mail server, and plan a migration to AlmaLinux 9 or Rocky Linux 9 for any new production mail server. A mail server in particular is a poor candidate for staying on an unsupported operating system long term, since it is directly exposed to the internet on multiple ports and handles sensitive credentials and message content. 

Prerequisites: 

• A VPS running Centos 7 with a static IP address, ideally a Linux VPS Server with enough RAM to comfortably run Postfix, Dovecot, Apache, MariaDB, and PHP-FPM together 
• A domain name (for example, yourdomain.com) where you can manage DNS records 
• Root or sudo access to the server 

Understanding the Components Before You Configure Postfix and Dovecot 

Before diving into commands, it helps to understand what each piece of software actually does, since a mail server is really three separate applications working together rather than one single program. Postfix is a Mail Transfer Agent, responsible for accepting outgoing mail from a client and delivering it to other mail servers using SMTP, and for accepting incoming mail from other servers on the internet. Postfix alone, however, has no concept of a mailbox that a user can log into and browse; it only moves mail from one place to another. 

This is where Dovecot comes in. Once you configure postfix and dovecot to work together, Dovecot takes over the job of storing incoming mail in a per-user mailbox format and exposing that mailbox to email clients through the IMAP and POP3 protocols. IMAP keeps mail synchronized on the server and is the protocol almost all modern webmail clients and mobile mail apps use, while POP3 downloads mail to a single device and is mostly a legacy option today. Roundcube, the third component, is simply a web application that speaks IMAP to Dovecot on the back end and presents a familiar inbox interface in the browser on the front end, similar in concept to Gmail or Outlook Web Access. 

Understanding this division of responsibility matters because when something goes wrong later, it tells you where to look. If mail cannot be sent at all, the problem is almost always in Postfix. If mail arrives but a user cannot log in to read it, the problem is almost always in Dovecot or in the way you configured authentication between Postfix and Dovecot. If login works from a desktop mail client but not from Roundcube, the problem is almost always in the Apache or PHP layer supporting Roundcube rather than in the mail server itself. 

Part 1: Configure Postfix and Dovecot 

Step 1: Preliminary Server Configuration 

1.1 Configure the Firewall 

Allow the necessary services through the firewall before you configure postfix and dovecot, since a correctly configured mail server that cannot be reached from outside will still fail every delivery test: 

sudo firewall-cmd --permanent --add-service={http,https,smtp,smtps,imap,imaps,pop3,pop3s} 
sudo firewall-cmd --reload 

1.2 Configure SELinux 

Instead of disabling SELinux entirely, which is a security risk, set it to permissive mode. This lets you configure postfix and dovecot while SELinux logs any policy violations without blocking the service, which is useful for troubleshooting without giving up the protection SELinux provides once you are ready to move to enforcing mode: 

sudo setenforce 0 
sudo sed -i 's/^SELINUX=.*/SELINUX=permissive/g' /etc/selinux/config 

If you later want to move back to enforcing mode once the mail server is fully working, review the audit log at /var/log/audit/audit.log for any denials logged while the server was in permissive mode, then use audit2allow to generate the specific policy exceptions your setup needs before re-enabling enforcing mode. 

Step 2: Configure DNS Records 

To configure postfix and dovecot successfully, your domain needs the correct DNS records pointing at your server. Configure these in your domain registrar’s control panel. 

Record Type	Name / Host	Type	Value	Priority	TTL
A Record	mail	A	your_server_ip	N/A	300 (or default)
MX Record	@ (or leave blank)	MX	mail.yourdomain.com	10	3600 (or default)

DNS changes can take anywhere from a few minutes up to 48 hours to propagate globally, so start this step early. Use a public DNS lookup tool or run dig yourdomain.com from a separate machine to confirm your records have propagated before testing mail flow. It is worth noting that many receiving mail servers, including large providers like Gmail and Outlook, will reject or heavily spam-filter mail from a domain that has no reverse DNS (PTR) record matching the sending server’s IP address, so ask your VPS provider to set the PTR record for your server’s IP to match mail.yourdomain.com before you plan to send real mail to external recipients. 

Step 3: Install and Configure Postfix 

3.1 Install Postfix 

Postfix is available in the default Centos repositories, so once your Vault redirection is in place, install it normally: 

sudo yum -y install postfix 

3.2 Configure Main Settings 

Edit the main Postfix configuration file: 

sudo vi /etc/postfix/main.cf 

Modify or add the following lines, replacing yourdomain.com with your actual domain, to configure postfix correctly: 

myhostname = mail.yourdomain.com 
mydomain = yourdomain.com 
myorigin = $mydomain 
inet_interfaces = all 
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain 
mynetworks = 127.0.0.0/8, [::1]/128 
home_mailbox = Maildir/ 

3.3 Start and Enable Postfix 

sudo systemctl enable postfix 
sudo systemctl start postfix 

Step 4: Test Postfix 

4.1 Create a Test User 

sudo useradd admin 
sudo passwd admin 
# Set a strong password when prompted 

4.2 Test Sending Mail Locally 

Use telnet to simulate an SMTP conversation and confirm you were able to configure postfix and dovecot correctly at this stage: 

sudo yum install -y telnet 
telnet localhost 25 

Once connected, run the following commands in the telnet session: 

EHLO localhost 
MAIL FROM: <[email protected]> 
RCPT TO: <[email protected]> 
DATA 
Subject: Test Postfix Mail 
 
This is a test email from Postfix. 
. 
QUIT 

4.3 Verify Mail Delivery 

If successful, the email will be delivered to the user’s Maildir directory. 

sudo ls -l /home/admin/Maildir/new/ 
# You should see a new file here. Use cat to view its contents. 

Step 5: Install and Configure Dovecot 

5.1 Install Dovecot 

sudo yum -y install dovecot 

5.2 Configure Protocols and Mail Location 

Edit the main Dovecot config file to enable protocols, which is a required part of how you configure postfix and dovecot to work together: 

sudo vi /etc/dovecot/dovecot.conf 

Ensure this line is uncommented and active: 

protocols = imap pop3 lmtp 

Now set the mail directory format to match Postfix: 

sudo vi /etc/dovecot/conf.d/10-mail.conf 

Find and modify the mail_location line: 

mail_location = maildir:~/Maildir 

5.3 Configure Authentication 

Edit the authentication file: 

sudo vi /etc/dovecot/conf.d/10-auth.conf 

Modify the following lines. Note that plaintext authentication should only remain enabled once SSL is configured in the SSL section of this guide, since sending plaintext credentials over an unencrypted connection is not secure for anything beyond local testing on the server itself: 

disable_plaintext_auth = no 
auth_mechanisms = plain login 

5.4 Link Dovecot to Postfix 

Configure the authentication socket by editing the master config file: 

sudo vi /etc/dovecot/conf.d/10-master.conf 

Find the unix_listener auth-userdb section and configure it as follows: 

unix_listener auth-userdb { 
  mode = 0600 
  user = postfix 
  group = postfix 
} 

5.5 Start and Enable Dovecot 

sudo systemctl enable dovecot 
sudo systemctl start dovecot 

Step 6: Test Dovecot 

Test if Dovecot is responding correctly on the POP3 port, which confirms you have managed to configure postfix and dovecot to communicate with each other: 

telnet localhost 110 

In the telnet session, run: 

USER admin 
PASS your_password_here 
LIST 
QUIT 

A successful LIST command confirms Dovecot is working and can see the test email you sent earlier. 

Part 2: Install and Configure Roundcube Webmail 

With Postfix and Dovecot configured, you can now install Roundcube, a browser based webmail client, on top of the mail server you just built. 

Step 1: Install the LAMP Stack With a Current PHP Version 

Roundcube requires a web server, a database, and PHP. This is the step where older versions of this guide go wrong: Centos 7’s native PHP package is version 5.4, and the current stable release of Roundcube, version 1.7.x as of 2026, requires PHP 8.1 or newer, so you cannot use the base Centos repositories for PHP. You also do not need the php-mcrypt package referenced in older guides, since the mcrypt extension was removed from PHP entirely starting with PHP 7.2, and Roundcube has not depended on it for years. 

1.1 Install the Remi Repository for a Current PHP Version 

The Remi RPM repository is the standard third party source for current PHP versions on RHEL family distributions including Centos 7, since the base operating system repositories only ship the PHP version that was current when Centos 7 was released. 

sudo yum install -y epel-release 
sudo yum install -y https://rpms.remirepo.net/enterprise/remi-release-7.rpm 
sudo yum install -y yum-utils 
sudo yum-config-manager --enable remi-php81 

1.2 Install Apache, PHP 8.1, and MariaDB 

sudo yum install -y httpd php php-fpm php-cli php-gd php-curl php-xml php-mysqlnd php-mbstring php-pspell php-imagick php-intl mariadb-server 

1.3 Start and Enable Services 

sudo systemctl start httpd mariadb php-fpm 
sudo systemctl enable httpd mariadb php-fpm 

1.4 Configure PHP Settings 

Edit the main PHP configuration file to set your timezone: 

sudo vi /etc/php.ini 

Find the line ;date.timezone = and modify it to your region, removing the semicolon to uncomment it: 

date.timezone = "Asia/Kolkata" 

Save the file and restart Apache and PHP-FPM to apply the changes: 

sudo systemctl restart httpd php-fpm 

Step 2: Configure the MariaDB Database 

2.1 Secure the MariaDB Installation 

Run the security script to set a root password and remove insecure defaults: 

sudo mysql_secure_installation 

Follow the prompts to set a root password, remove anonymous users, disallow remote root login, and remove the test database. 

2.2 Create a Database for Roundcube 

Log into MariaDB and create a dedicated database and user for Roundcube for better security: 

mysql -u root -p 

Enter your root password when prompted, then run the following SQL commands, replacing the password with a strong one of your own: 

CREATE DATABASE roundcubemail; 
CREATE USER 'roundcube'@'localhost' IDENTIFIED BY 'your_strong_password_here'; 
GRANT ALL PRIVILEGES ON roundcubemail.* TO 'roundcube'@'localhost'; 
FLUSH PRIVILEGES; 
EXIT; 

Step 3: Install and Configure Roundcube 

3.1 Download the Current Stable Release of Roundcube 

Roundcube 1.7 is the current stable branch as of 2026 and requires PHP 8.1 or newer, which is why the Remi repository step above matters. Always check the Roundcube releases page for the latest patch version before downloading, since security releases come out regularly, roughly once a month through most of 2026. 

cd /tmp 
sudo wget -c https://github.com/roundcube/roundcubemail/releases/download/1.7.4/roundcubemail-1.7.4-complete.tar.gz 

3.2 Extract and Move Files 

sudo tar xzf roundcubemail-1.7.4-complete.tar.gz 
sudo mv roundcubemail-1.7.4 /var/www/html/roundcubemail 

3.3 Import the Database Schema 

cd /var/www/html/roundcubemail 
sudo mysql -u root -p roundcubemail < SQL/mysql.initial.sql 

3.4 Set Correct Permissions 

Apache needs to own the files to read and write to them: 

sudo chown -R apache:apache /var/www/html/roundcubemail 

3.5 Restart Services 

sudo systemctl restart httpd mariadb php-fpm 

Step 4: Complete Setup via Web Browser 

Roundcube 1.7 made the public_html entry point mandatory as a security improvement over earlier versions, so your Apache document root or VirtualHost for the mail subdomain should point at the public_html folder inside the Roundcube directory, not the roundcubemail folder itself. This is a meaningful change from the 1.3.x series referenced in older guides, and pointing your VirtualHost at the wrong directory is one of the most common reasons Roundcube fails to load correctly after installation. 

The final configuration is done through a web based installer: 

1. Open your browser and navigate to your Roundcube installer at http://mail.yourdomain.com/installer. 
2. General Configuration: set a product_name, for example “YourDomain Webmail”. 
3. Database Setup: Database type MySQL, Database server localhost, Database name roundcubemail, Username roundcube, Password the password you set in Step 2.2. 
4. IMAP and SMTP Settings: IMAP server localhost, SMTP server localhost. Once SSL is configured in the SSL section below, set both to use TLS on their standard ports, 993 for IMAPS and 465 or 587 for SMTP with STARTTLS. 
5. Click Create Config, then Continue on the success message. 
6. Use the Test Config page to verify all settings are correct. 

Step 5: Secure the Installation 

5.1 Remove the Installer Directory 

This is a critical security step. The installer directory contains sensitive data and must be deleted to prevent unauthorized access: 

sudo rm -rf /var/www/html/roundcubemail/installer 

5.2 Disable the Installer in Config as a Backup Measure 

As an additional safeguard, disable the installer in the config file as well: 

sudo vi /var/www/html/roundcubemail/config/config.inc.php 

Find and ensure the following line is set: 

$config['enable_installer'] = false; 

Step 6: Log In to Roundcube 

Your webmail is now ready. Open your browser and navigate to http://mail.yourdomain.com/. Log in using the email credentials you created earlier in this guide when you configure postfix and dovecot (for example, [email protected] and its password). You should see the inbox with the test email you sent earlier. 

Part 3: Secure Everything With SSL From Lets Encrypt 

Sending mail credentials and messages in plaintext, as the earlier steps do for testing purposes, is not secure for a real mail server. Once you have confirmed that you were able to configure postfix and dovecot correctly and that Roundcube logs in successfully, secure the whole stack with a free SSL certificate. 

Step 1: Install Certbot 

sudo yum install -y certbot python2-certbot-apache 

Step 2: Obtain and Configure the Certificate 

sudo certbot --apache -d mail.yourdomain.com 

Certbot will edit your Apache VirtualHost automatically to serve the Roundcube webmail interface over HTTPS and can redirect all HTTP traffic to HTTPS if you choose that option, which is recommended. 

Step 3: Configure Postfix and Dovecot to Use the Certificate 

Edit the Postfix main configuration to reference the new certificate: 

sudo vi /etc/postfix/main.cf 

Add or update the following lines, pointing at the certificate paths Certbot created: 

smtpd_tls_cert_file = /etc/letsencrypt/live/mail.yourdomain.com/fullchain.pem 
smtpd_tls_key_file = /etc/letsencrypt/live/mail.yourdomain.com/privkey.pem 
smtpd_use_tls = yes 
smtpd_tls_auth_only = yes 

Edit the Dovecot SSL configuration: 

sudo vi /etc/dovecot/conf.d/10-ssl.conf 

Update the certificate paths: 

ssl = required 
ssl_cert = </etc/letsencrypt/live/mail.yourdomain.com/fullchain.pem 
ssl_key = </etc/letsencrypt/live/mail.yourdomain.com/privkey.pem 

Restart both services: 

sudo systemctl restart postfix dovecot 

Step 4: Verify Automatic Renewal 

sudo certbot renew --dry-run 

If this runs without errors, the certificate securing your mail server will renew automatically going forward, since Lets Encrypt certificates are valid for 90 days at a time. 

Troubleshooting Common Problems When You Configure Postfix and Dovecot 

A handful of issues account for most of the problems people run into when they try to configure postfix and dovecot together. The list below covers the most frequent ones and how to resolve each. 

• Mail sends locally but never reaches external addresses: this is almost always a DNS or reverse DNS problem rather than a Postfix configuration problem. Confirm your MX record, A record, and PTR record are all correct, and check /var/log/maillog for the specific rejection reason returned by the receiving mail server. 
• Dovecot cannot authenticate a user even though the password is correct: recheck the unix_listener auth-userdb block in 10-master.conf, since a mismatched socket path or ownership is the most common cause of Postfix being unable to hand off authentication to Dovecot. 
• Roundcube shows a blank page or a PHP error after installation: confirm PHP-FPM is actually running with sudo systemctl status php-fpm, and confirm the Apache VirtualHost document root points at the public_html folder rather than the roundcubemail folder itself, which is the Roundcube 1.7 change described earlier in this guide. 
• yum commands return 404 or mirror errors: this is the Centos 7 end of life issue described at the start of this guide. Redirect the repo files to vault.centos.org and clear the yum cache before continuing. 
• Mail delivered from your server lands in spam at the receiving end: beyond correct DNS and PTR records, consider adding SPF, DKIM, and DMARC records for your domain, since major mail providers increasingly treat their absence as a strong spam signal regardless of how correctly you configure postfix and dovecot themselves. 
• Certbot cannot find a VirtualHost for the mail subdomain: confirm the ServerName in your Apache VirtualHost for mail.yourdomain.com exactly matches the domain you are requesting a certificate for, then rerun certbot after correcting it. 

Ongoing Maintenance After You Configure Postfix and Dovecot 

Getting the mail server running is only the first part of the job. A mail server that sits untouched for months tends to accumulate two kinds of problems: growing mailboxes that eventually fill the disk, and outdated software that accumulates unpatched vulnerabilities. A few habits keep a server you configure postfix and dovecot on healthy over the long run, and pairing this setup with CloudMinister Server Management is worth considering if you would rather not handle ongoing patching and monitoring yourself. 

• Monitor disk usage regularly: mailboxes stored under Maildir grow indefinitely unless a retention policy is applied. Check disk usage with df -h and du -sh on the mail spool directories periodically, and consider setting mailbox quotas in Dovecot if multiple users share the server. 
• Review mail logs for delivery problems: /var/log/maillog records every delivery attempt, bounce, and authentication event. Reviewing it periodically catches problems, such as a misconfigured client repeatedly failing to authenticate, before they escalate. 
• Keep Roundcube updated: Roundcube has had a steady stream of security releases through 2026, and running an outdated version of a web application that is directly exposed to the internet and handles login credentials is a meaningful risk. Subscribe to the Roundcube release announcements or check the releases page every few months. 
• Add spam and malware filtering for a production server: this guide covers the core mail stack, but a production deployment should add SpamAssassin for spam scoring and ClamAV for attachment scanning, both of which integrate with Postfix through milter or content filter hooks. CloudMinister’s Cyber Security services cover this kind of hardening if you prefer a managed approach. 
• Back up the mail spool and configuration separately: the Maildir directories under /home contain the actual mail content, while /etc/postfix, /etc/dovecot, and /etc/letsencrypt contain configuration and certificates. Back up both, since losing either one means significant reconstruction work. 
• Keep the SSL certificate protecting your mail traffic current: the same Lets Encrypt certificate securing your webmail also protects the SMTP and IMAP connections described in this guide. Review CloudMinister’s SSL Certificate options if you later want an extended validation certificate for your primary domain alongside the free certificate used here. 
• Protect the server from denial of service attacks: a mail server exposed on SMTP, IMAP, and HTTPS ports is a visible target. CloudMinister DDoS Protection Services add network-level filtering in front of a VPS if you expect the server to face significant hostile traffic. 

Self-Hosted Mail Versus Managed Email: A Quick Comparison 

Everything in this guide shows you how to configure postfix and dovecot from the ground up, which is valuable for learning and gives you full control, but it is worth being honest about the tradeoffs before committing a production domain to a self-hosted mail server. Self-hosting means you are responsible for every patch, every spam filtering rule, every backup, and every hour of uptime, with no vendor to escalate to when something breaks at 2 AM. 

For businesses that want the reliability of a managed inbox without the operational overhead, hosted alternatives such as Microsoft 365, Google Workspace, and Zoho Email Solutions handle spam filtering, uptime, and security patching on your behalf, at the cost of less low-level control than a self-managed Postfix and Dovecot stack gives you. Many teams end up running both: a self-hosted setup like the one in this guide for testing, development, or a specific technical requirement, and a managed provider for the primary business inbox that non-technical staff depend on daily. 

Testing Mail Flow With External Providers 

Once you configure postfix and dovecot and confirm local delivery works, the next meaningful test is sending and receiving mail with an external provider such as Gmail or Outlook, since local delivery tests only confirm that Postfix and Dovecot can talk to each other on the same machine, not that your server can exchange mail with the wider internet. 

• Send a test message to an external address: log into Roundcube and send a message to a Gmail or Outlook address you control. Check whether it arrives in the inbox or the spam folder, since landing in spam usually points to missing SPF, DKIM, or PTR records rather than a Postfix misconfiguration. 
• Send a test message from the external address back: reply from Gmail or Outlook to the address on your new server, then confirm it appears in Roundcube. This confirms inbound delivery, which depends on your MX record being correct and your firewall allowing inbound port 25 traffic. 
• Check the message headers: most webmail providers let you view the full headers of a received message. Look for SPF, DKIM, and DMARC results in the Authentication-Results header, since these tell you exactly which authentication mechanisms passed or failed for messages sent from your server. 
• Use an external mail tester: several free online tools accept a test message sent from your server and return a detailed report on SPF, DKIM, DMARC, blacklist status, and general deliverability, which is a faster way to catch configuration gaps than waiting for real recipients to report problems. 

Conclusion 

You have now successfully managed to configure postfix and dovecot together with Roundcube webmail on a Centos 7 VPS, and secured the entire stack with a free SSL certificate from Lets Encrypt. The finished setup gives you Postfix as the SMTP server for sending mail, Dovecot as the IMAP and POP3 server for retrieving mail, and Roundcube as a modern browser based client for reading and composing email, all running under your own domain rather than a third party mailbox service. Along the way, this guide also walked through the reasoning behind each component, so that when something does eventually need troubleshooting, you know whether to look at Postfix, Dovecot, or the Apache and PHP layer supporting Roundcube, rather than guessing at the entire stack every time. 

Because you were careful to configure postfix and dovecot with a current PHP version through the Remi repository rather than the outdated PHP and mcrypt combination found in older guides, the Roundcube installation on your server is compatible with the actively maintained 1.7.x release line rather than an end of life version with unpatched vulnerabilities. This distinction matters more than it might first appear, since a webmail client is one of the more exposed pieces of software on any server, reachable directly from the public internet and handling login credentials on every single use, so keeping it on a supported version with current security patches is not optional maintenance, it is one of the more important ongoing responsibilities of running your own mail server. 

As with any mail server, the work does not end once Roundcube shows a working inbox. Keep Postfix, Dovecot, and Roundcube updated on a regular schedule, monitor your mail logs periodically for delivery failures or repeated authentication attempts that might indicate abuse, and add SPF, DKIM, and DMARC DNS records if you plan to send meaningful volumes of mail to external providers such as Gmail or Outlook, since the absence of these records is now one of the most common reasons legitimate mail lands in a recipient’s spam folder regardless of how correctly the underlying server has been configured. Finally, remember that Centos 7 itself is past end of life, so plan a migration path to a currently supported distribution such as AlmaLinux 9 or Rocky Linux 9 for any long term production mail server, carrying forward the same Postfix, Dovecot, and Roundcube configuration principles described in this guide, since none of them are specific to Centos and all of them transfer directly to a modern, currently supported RHEL family distribution. 

Frequently Asked Questions

What is the difference between Postfix and Dovecot?

Postfix and Dovecot handle two different jobs in a mail server. When you configure postfix and dovecot together, Postfix acts as the Mail Transfer Agent, responsible for sending outgoing mail and accepting incoming mail from other servers over SMTP. Dovecot, on the other hand, is the Mail Delivery Agent that stores incoming mail in a per-user mailbox and lets email clients like Roundcube retrieve it through IMAP or POP3. Postfix alone cannot let a user log in and browse their inbox, and Dovecot alone cannot send mail to other servers, which is why both are required together to configure postfix and dovecot into a complete, working mail server.

Can I configure postfix and dovecot on Centos 7 in 2026?

Yes, but Centos 7 reached its official end of life on June 30, 2024, so the default yum repositories are offline. To configure postfix and dovecot in 2026, you first need to redirect yum to the Centos Vault archive, which hosts the final released packages for Centos 7. Once that redirection is done, installing Postfix and Dovecot works exactly as it always has. For a new production mail server, however, it is worth planning a migration to a currently supported distribution such as AlmaLinux 9 or Rocky Linux 9, since Centos 7 no longer receives security patches.

Why does Roundcube require PHP 8.1 instead of the PHP version that ships with Centos 7?

Centos 7 ships with PHP 5.4 by default, which was current when the distribution was released but is now more than a decade old. Roundcube 1.7.x, the current stable release line as of 2026, requires PHP 8.1 or newer to run. This is why you cannot configure postfix and dovecot with Roundcube using the base Centos repositories alone, and instead need to install PHP 8.1 through the Remi repository, a widely used third party source for current PHP versions on RHEL family distributions.

Do I still need to install php-mcrypt to run Roundcube?

No. The mcrypt extension was removed from PHP entirely starting with PHP 7.2, and Roundcube has not depended on it for years. Older guides that reference php-mcrypt were written for PHP 5.x era installations, and following that step today will simply fail, since no php-mcrypt package exists for any PHP version that current Roundcube releases support. You can safely skip it when you configure postfix and dovecot with Roundcube on a current setup.

Why does the Roundcube installer URL end in /installer instead of just the domain?

Roundcube ships with a web based setup wizard located in the installer subdirectory of its files, which walks you through the database and IMAP or SMTP configuration during first setup. Once you configure postfix and dovecot and confirm Roundcube logs in successfully, this installer directory should be deleted immediately, since leaving it in place exposes sensitive configuration data to anyone who finds the URL. Roundcube 1.7 also made the public_html folder the mandatory web root, so make sure your Apache VirtualHost points there rather than at the top level Roundcube directory.

Why is my mail landing in spam even though I successfully configured postfix and dovecot?

A working Postfix and Dovecot setup only confirms that mail can be sent and received correctly on your own server. Major providers such as Gmail and Outlook additionally check SPF, DKIM, DMARC, and reverse DNS (PTR) records before deciding whether a message is trustworthy. If any of these are missing, even mail sent from a perfectly configured server will often land in spam. After you configure postfix and dovecot and confirm basic delivery works, add these DNS records and ask your VPS provider to set a matching PTR record for your server’s IP address.

Is it safe to leave plaintext authentication enabled in Dovecot?

Plaintext authentication sends login credentials without encryption, which is acceptable only for local testing during initial setup. Once you configure postfix and dovecot and confirm the mail server works, you should secure the connection with an SSL certificate from Lets Encrypt and configure Dovecot and Postfix to require encrypted connections, rather than leaving disable_plaintext_auth set to no indefinitely. Running a mail server that accepts plaintext logins over the open internet exposes usernames and passwords to anyone able to intercept the traffic.

Should I self-host email with Postfix and Dovecot, or use a managed provider instead?

It depends on your goals. Learning to configure postfix and dovecot gives you full control over your mail infrastructure and is a valuable technical skill, and it can be a good fit for testing, development, or specific technical requirements. For a primary business inbox that non-technical staff depend on daily, however, a managed provider such as Microsoft 365, Google Workspace, or Zoho Email Solutions handles spam filtering, uptime, and security patching for you, which reduces the ongoing operational burden compared with maintaining a self-hosted server.