{"id":4575,"date":"2026-02-05T22:17:15","date_gmt":"2026-02-05T19:17:15","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/optimizing-postfix-and-dovecot-on-a-vps-for-high-volume-transactional-email\/"},"modified":"2026-02-05T22:17:15","modified_gmt":"2026-02-05T19:17:15","slug":"optimizing-postfix-and-dovecot-on-a-vps-for-high-volume-transactional-email","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/optimizing-postfix-and-dovecot-on-a-vps-for-high-volume-transactional-email\/","title":{"rendered":"Optimizing Postfix and Dovecot on a VPS for High\u2011Volume Transactional Email"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>When you move from a few hundred emails per day to tens or hundreds of thousands of transactional messages, your mail server stops being a side feature and becomes production\u2011critical infrastructure. Password resets, order confirmations, invoices, OTP codes and system alerts all depend on your SMTP stack responding quickly and consistently. On a <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a>, that usually means getting the details of Postfix (as MTA) and Dovecot (as IMAP\/POP and local delivery) right from day one.<\/p>\n<p>In this article, we will walk through how we at dchost.com approach tuning Postfix and Dovecot on a VPS specifically for high\u2011volume transactional email. We will focus on real\u2011world settings: queue management, concurrency limits, TLS, authentication, rate limiting, and how to keep deliverability and abuse risk under control. The goal is not an academic checklist, but a practical configuration that can push serious volume without burning your IP reputation or overloading your server.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#1_What_HighVolume_Transactional_Email_Really_Means_on_a_VPS\"><span class=\"toc_number toc_depth_1\">1<\/span> 1. What \u201cHigh\u2011Volume Transactional Email\u201d Really Means on a VPS<\/a><ul><li><a href=\"#Transactional_vs_marketing_traffic\"><span class=\"toc_number toc_depth_2\">1.1<\/span> Transactional vs marketing traffic<\/a><\/li><li><a href=\"#Capacity_planning_how_much_can_one_VPS_really_handle\"><span class=\"toc_number toc_depth_2\">1.2<\/span> Capacity planning: how much can one VPS really handle?<\/a><\/li><\/ul><\/li><li><a href=\"#2_Laying_the_Groundwork_DNS_IPs_and_Basic_Mail_Architecture\"><span class=\"toc_number toc_depth_1\">2<\/span> 2. Laying the Groundwork: DNS, IPs and Basic Mail Architecture<\/a><ul><li><a href=\"#DNS_and_IP_hygiene\"><span class=\"toc_number toc_depth_2\">2.1<\/span> DNS and IP hygiene<\/a><\/li><li><a href=\"#Port_separation_and_service_layout\"><span class=\"toc_number toc_depth_2\">2.2<\/span> Port separation and service layout<\/a><\/li><\/ul><\/li><li><a href=\"#3_Core_Postfix_Tuning_for_HighVolume_LowDrama_Sending\"><span class=\"toc_number toc_depth_1\">3<\/span> 3. Core Postfix Tuning for High\u2011Volume, Low\u2011Drama Sending<\/a><ul><li><a href=\"#Key_goals_for_Postfix_configuration\"><span class=\"toc_number toc_depth_2\">3.1<\/span> Key goals for Postfix configuration<\/a><\/li><li><a href=\"#Separate_mastercf_services_for_smtp_and_submission\"><span class=\"toc_number toc_depth_2\">3.2<\/span> Separate master.cf services for smtp and submission<\/a><\/li><li><a href=\"#Concurrency_and_rate_limits\"><span class=\"toc_number toc_depth_2\">3.3<\/span> Concurrency and rate limits<\/a><\/li><li><a href=\"#Queue_lifetimes_retry_strategy_and_backoff\"><span class=\"toc_number toc_depth_2\">3.4<\/span> Queue lifetimes, retry strategy and backoff<\/a><\/li><li><a href=\"#DNS_behaviour_and_connection_reuse\"><span class=\"toc_number toc_depth_2\">3.5<\/span> DNS behaviour and connection reuse<\/a><\/li><li><a href=\"#TLS_settings_uptodate_but_not_overcomplicated\"><span class=\"toc_number toc_depth_2\">3.6<\/span> TLS settings: up\u2011to\u2011date but not over\u2011complicated<\/a><\/li><\/ul><\/li><li><a href=\"#4_Integrating_and_Optimizing_Dovecot_for_Transactional_Workloads\"><span class=\"toc_number toc_depth_1\">4<\/span> 4. Integrating and Optimizing Dovecot for Transactional Workloads<\/a><ul><li><a href=\"#Why_Dovecot_still_matters_for_SMTPonly_stacks\"><span class=\"toc_number toc_depth_2\">4.1<\/span> Why Dovecot still matters for \u201cSMTP\u2011only\u201d stacks<\/a><\/li><li><a href=\"#Mail_storage_format_Maildir_vs_mdbox\"><span class=\"toc_number toc_depth_2\">4.2<\/span> Mail storage format: Maildir vs mdbox<\/a><\/li><li><a href=\"#LMTP_delivery_from_Postfix_to_Dovecot\"><span class=\"toc_number toc_depth_2\">4.3<\/span> LMTP delivery from Postfix to Dovecot<\/a><\/li><li><a href=\"#Dovecot_process_limits_and_memory_usage\"><span class=\"toc_number toc_depth_2\">4.4<\/span> Dovecot process limits and memory usage<\/a><\/li><li><a href=\"#SSLTLS_for_Dovecot\"><span class=\"toc_number toc_depth_2\">4.5<\/span> SSL\/TLS for Dovecot<\/a><\/li><\/ul><\/li><li><a href=\"#5_Deliverability_and_Reputation_Configuration_Is_Only_Half_the_Story\"><span class=\"toc_number toc_depth_1\">5<\/span> 5. Deliverability and Reputation: Configuration Is Only Half the Story<\/a><ul><li><a href=\"#Authentication_and_policies_SPF_DKIM_DMARC\"><span class=\"toc_number toc_depth_2\">5.1<\/span> Authentication and policies: SPF, DKIM, DMARC<\/a><\/li><li><a href=\"#Dedicated_IPs_and_warming_strategy\"><span class=\"toc_number toc_depth_2\">5.2<\/span> Dedicated IPs and warming strategy<\/a><\/li><li><a href=\"#Abuse_prevention_compromised_accounts_and_rate_limits\"><span class=\"toc_number toc_depth_2\">5.3<\/span> Abuse prevention, compromised accounts and rate limits<\/a><\/li><li><a href=\"#Realworld_stack_Postfix_Dovecot_and_rspamd_together\"><span class=\"toc_number toc_depth_2\">5.4<\/span> Real\u2011world stack: Postfix, Dovecot and rspamd together<\/a><\/li><\/ul><\/li><li><a href=\"#6_Monitoring_Logs_and_a_Simple_Operations_Playbook\"><span class=\"toc_number toc_depth_1\">6<\/span> 6. Monitoring, Logs and a Simple Operations Playbook<\/a><ul><li><a href=\"#What_to_watch_daily_and_weekly\"><span class=\"toc_number toc_depth_2\">6.1<\/span> What to watch daily and weekly<\/a><\/li><li><a href=\"#Log_rotation_and_retention\"><span class=\"toc_number toc_depth_2\">6.2<\/span> Log rotation and retention<\/a><\/li><li><a href=\"#Simple_runbooks_for_operational_events\"><span class=\"toc_number toc_depth_2\">6.3<\/span> Simple runbooks for operational events<\/a><\/li><\/ul><\/li><li><a href=\"#7_Putting_It_All_Together_on_dchostcom_Infrastructure\"><span class=\"toc_number toc_depth_1\">7<\/span> 7. Putting It All Together on dchost.com Infrastructure<\/a><\/li><\/ul><\/div>\n<h2><span id=\"1_What_HighVolume_Transactional_Email_Really_Means_on_a_VPS\">1. What \u201cHigh\u2011Volume Transactional Email\u201d Really Means on a VPS<\/span><\/h2>\n<h3><span id=\"Transactional_vs_marketing_traffic\">Transactional vs marketing traffic<\/span><\/h3>\n<p>Before touching configuration files, be clear on the nature of your traffic. Transactional email:<\/p>\n<ul>\n<li>Is triggered by user actions or system events (order placed, password reset, invoice ready).<\/li>\n<li>Must arrive quickly and reliably; a 20\u2011minute delay can break user flows.<\/li>\n<li>Is usually smaller in size (plain text or simple HTML, few images).<\/li>\n<li>Has tighter expectations from mailbox providers: authentication, consistent IPs, low complaint rates.<\/li>\n<\/ul>\n<p>Marketing \/ newsletter traffic, on the other hand, is bursty and volume\u2011heavy, and is usually better served from a separate infrastructure. We strongly recommend using <strong>different sending domains and IPs<\/strong> for these two types of traffic. We have a full strategy for this in our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/e-posta-icin-ayri-gonderim-alan-adi-kullanmak-transactional-ve-pazarlama-e-postalari-icin-dogru-domain-ve-dns-stratejisi\/\">using separate sending domains for transactional vs marketing emails<\/a>.<\/p>\n<h3><span id=\"Capacity_planning_how_much_can_one_VPS_really_handle\">Capacity planning: how much can one VPS really handle?<\/span><\/h3>\n<p>A well\u2011tuned Postfix on a modern VPS can comfortably handle thousands of transactional messages per hour, as long as:<\/p>\n<ul>\n<li><strong>CPU<\/strong> is not saturated by TLS handshakes, spam filters and logging.<\/li>\n<li><strong>Disk I\/O<\/strong> (queue, logs, mailboxes) is fast enough, ideally NVMe SSD.<\/li>\n<li><strong>Memory<\/strong> covers Postfix, Dovecot, spam filters, system services and OS cache.<\/li>\n<li><strong>Network<\/strong> bandwidth and latency are stable toward major mailbox providers.<\/li>\n<\/ul>\n<p>As a baseline, for 20\u201350k transactional emails\/day with light IMAP usage, we usually suggest:<\/p>\n<ul>\n<li>2\u20134 vCPUs<\/li>\n<li>4\u20138 GB RAM<\/li>\n<li>Fast SSD\/NVMe storage (at least 50\u2013100 GB to leave room for logs and mailboxes)<\/li>\n<li>1 dedicated IPv4 address (plus IPv6 if you plan to send over IPv6 as well)<\/li>\n<\/ul>\n<p>If you are moving toward 100k+ messages\/day or have heavy IMAP\/POP usage, consider scaling up the VPS or moving to a <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a> or colocation node within our infrastructure so disk and network contention are less of a concern.<\/p>\n<h2><span id=\"2_Laying_the_Groundwork_DNS_IPs_and_Basic_Mail_Architecture\">2. Laying the Groundwork: DNS, IPs and Basic Mail Architecture<\/span><\/h2>\n<h3><span id=\"DNS_and_IP_hygiene\">DNS and IP hygiene<\/span><\/h3>\n<p>High\u2011volume transactional mail will be judged primarily on its <strong>reputation<\/strong>. Reputation starts with clean DNS and IP settings:<\/p>\n<ul>\n<li><strong>Forward DNS (A\/AAAA)<\/strong>: point your mail hostname (e.g. <code>mail.example.com<\/code>) to your VPS IPs.<\/li>\n<li><strong>Reverse DNS (PTR)<\/strong>: set a PTR that exactly matches your hostname, e.g. <code>1.2.3.4 =&gt; mail.example.com<\/code>. This is a must for deliverability.<\/li>\n<li><strong>HELO\/EHLO<\/strong>: configure Postfix to use the same name (<code>smtp_helo_name = mail.example.com<\/code>).<\/li>\n<li><strong>SPF, DKIM, DMARC<\/strong>: publish correct DNS records and keep them consistent with what your MTA does.<\/li>\n<\/ul>\n<p>If these concepts are fuzzy, take a look at our step\u2011by\u2011step deliverability guide <a href=\"https:\/\/www.dchost.com\/blog\/en\/spf-dkim-dmarc-ve-rdns-ile-e-posta-teslim-edilebilirligini-nasil-adim-adim-yukseltirsin\/\">\u201cInbox or Spam? SPF, DKIM, DMARC and rDNS explained step\u2011by\u2011step\u201d<\/a>. The DNS layer is non\u2011negotiable for high\u2011volume sending.<\/p>\n<h3><span id=\"Port_separation_and_service_layout\">Port separation and service layout<\/span><\/h3>\n<p>On a VPS that handles both outbound application mail and user mailboxes, we recommend:<\/p>\n<ul>\n<li><strong>Port 25<\/strong>: Postfix <em>smtp<\/em> for server\u2011to\u2011server delivery (inbound and outbound).<\/li>\n<li><strong>Port 587<\/strong>: Postfix <em>submission<\/em> for authenticated clients (apps, cron jobs, external tools).<\/li>\n<li><strong>Port 993<\/strong>: Dovecot IMAP over SSL.<\/li>\n<li><strong>Port 995<\/strong>: Dovecot POP3 over SSL (only if you really need POP3).<\/li>\n<\/ul>\n<p>Using a dedicated submission service on port 587 lets you apply different rate limits, authentication rules and spam checks for your own applications versus random inbound connections from the internet.<\/p>\n<h2><span id=\"3_Core_Postfix_Tuning_for_HighVolume_LowDrama_Sending\">3. Core Postfix Tuning for High\u2011Volume, Low\u2011Drama Sending<\/span><\/h2>\n<h3><span id=\"Key_goals_for_Postfix_configuration\">Key goals for Postfix configuration<\/span><\/h3>\n<p>For transactional traffic, we optimise Postfix around three high\u2011level goals:<\/p>\n<ol>\n<li><strong>Throughput without overload<\/strong>: enough concurrency to push mail out quickly, but not so much that the VPS hits CPU or I\/O limits.<\/li>\n<li><strong>Predictable queue behaviour<\/strong>: retries, backoff and queue lifetimes tuned for user expectations.<\/li>\n<li><strong>Good network citizenship<\/strong>: connection reuse, sane timeouts, and basic throttling to avoid looking abusive.<\/li>\n<\/ol>\n<h3><span id=\"Separate_mastercf_services_for_smtp_and_submission\">Separate master.cf services for smtp and submission<\/span><\/h3>\n<p>In <code>\/etc\/postfix\/master.cf<\/code>, ensure you have distinct services for public SMTP and authenticated submission. A simplified example:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">smtp      inet  n       -       n       -       20      smtpd\n  -o smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination\n\nsubmission inet n       -       n       -       20      smtpd\n  -o syslog_name=postfix\/submission\n  -o smtpd_tls_security_level=encrypt\n  -o smtpd_sasl_auth_enable=yes\n  -o smtpd_client_restrictions=permit_sasl_authenticated,reject\n  -o milter_macro_daemon_name=ORIGINATING\n<\/code><\/pre>\n<p>This lets you:<\/p>\n<ul>\n<li>Force TLS for submission (protecting credentials).<\/li>\n<li>Require authentication on 587 while allowing anonymous inbound on 25.<\/li>\n<li>Attach different policy services or filters for originating traffic.<\/li>\n<\/ul>\n<h3><span id=\"Concurrency_and_rate_limits\">Concurrency and rate limits<\/span><\/h3>\n<p>Postfix has several knobs that control how aggressively it connects to remote servers. For a VPS, values that are too high will quickly hit CPU, RAM and outbound connection limits; values that are too low will delay mail.<\/p>\n<p>Common parameters in <code>\/etc\/postfix\/main.cf<\/code> to review:<\/p>\n<ul>\n<li><strong><code>default_process_limit<\/code><\/strong>: caps total Postfix processes. For a medium VPS, 50\u2013100 is a good starting point.<\/li>\n<li><strong><code>smtp_destination_concurrency_limit<\/code><\/strong>: how many concurrent deliveries to a single domain (e.g. gmail.com). Start at 5\u201310 and increase only with care.<\/li>\n<li><strong><code>local_destination_concurrency_limit<\/code><\/strong>: for local deliveries via Dovecot LMTP; usually lower is fine (2\u20135).<\/li>\n<li><strong><code>smtpd_client_connection_count_limit<\/code><\/strong>: limit how many parallel connections one client can open.<\/li>\n<li><strong><code>smtpd_client_message_rate_limit<\/code><\/strong>: basic protection against a single compromised account flooding mail.<\/li>\n<\/ul>\n<p>On a busy day, it is better to have a small queue delay than to hammer Gmail or Outlook with hundreds of parallel connections from a single IP, which can hurt your reputation.<\/p>\n<h3><span id=\"Queue_lifetimes_retry_strategy_and_backoff\">Queue lifetimes, retry strategy and backoff<\/span><\/h3>\n<p>Transactional mail should be retried long enough to survive short provider outages, but not sit in the queue forever. Key settings:<\/p>\n<ul>\n<li><strong><code>maximal_queue_lifetime<\/code><\/strong>: total time to keep trying (e.g. 2d or 3d for transactional).<\/li>\n<li><strong><code>bounce_queue_lifetime<\/code><\/strong>: usually similar to <code>maximal_queue_lifetime<\/code>.<\/li>\n<li><strong><code>minimal_backoff_time<\/code><\/strong> and <strong><code>maximal_backoff_time<\/code><\/strong>: how quickly Postfix backs off after temp failures.<\/li>\n<\/ul>\n<p>For most transactional setups, something like this is reasonable:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">maximal_queue_lifetime = 2d\nbounce_queue_lifetime  = 2d\nminimal_backoff_time   = 300s\nmaximal_backoff_time   = 4h\n<\/code><\/pre>\n<p>This gives remote servers time to recover while ensuring users still get a bounce within a sensible window if delivery is impossible.<\/p>\n<h3><span id=\"DNS_behaviour_and_connection_reuse\">DNS behaviour and connection reuse<\/span><\/h3>\n<p>DNS lookups are a hidden bottleneck when you send at scale. Tune these:<\/p>\n<ul>\n<li><strong><code>smtp_host_lookup = dns, native<\/code><\/strong> to use DNS and the OS resolver.<\/li>\n<li><strong><code>smtp_connection_cache_on_demand = yes<\/code><\/strong> so Postfix can reuse SMTP connections for multiple messages.<\/li>\n<li><strong><code>smtp_dns_support_level = dnssec<\/code><\/strong> if your resolver and environment are DNSSEC\u2011ready (optional, but nice).<\/li>\n<\/ul>\n<p>Connection caching reduces TLS handshakes and speeds up delivery, especially toward big providers where you send many messages to the same MX.<\/p>\n<h3><span id=\"TLS_settings_uptodate_but_not_overcomplicated\">TLS settings: up\u2011to\u2011date but not over\u2011complicated<\/span><\/h3>\n<p>Modern transactional email should be encrypted in transit whenever the remote side supports it. At minimum:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">smtpd_tls_cert_file       = \/etc\/ssl\/certs\/mail.example.com.pem\nsmtpd_tls_key_file        = \/etc\/ssl\/private\/mail.example.com.key\nsmtpd_tls_security_level  = may\nsmtp_tls_security_level   = may\nsmtpd_tls_protocols       = !SSLv2 !SSLv3 !TLSv1 !TLSv1.1\nsmtp_tls_protocols        = !SSLv2 !SSLv3 !TLSv1 !TLSv1.1\nsmtpd_tls_mandatory_protocols = !SSLv2 !SSLv3 !TLSv1 !TLSv1.1\n<\/code><\/pre>\n<p>This keeps you on reasonably modern TLS versions while still being compatible with almost all receivers. If compliance or security policies require it, you can harden ciphers further following our various SSL\/TLS update guides, but for deliverability the key is: have a valid certificate and do not advertise ancient protocols.<\/p>\n<h2><span id=\"4_Integrating_and_Optimizing_Dovecot_for_Transactional_Workloads\">4. Integrating and Optimizing Dovecot for Transactional Workloads<\/span><\/h2>\n<h3><span id=\"Why_Dovecot_still_matters_for_SMTPonly_stacks\">Why Dovecot still matters for \u201cSMTP\u2011only\u201d stacks<\/span><\/h3>\n<p>Even if your primary goal is outbound transactional mail, Dovecot plays a crucial role:<\/p>\n<ul>\n<li>It provides <strong>IMAP\/POP access<\/strong> for support and admin mailboxes (e.g. <code>billing@<\/code>, <code>support@<\/code>).<\/li>\n<li>It can act as the <strong>local delivery agent<\/strong> using LMTP, which is cleaner than Postfix delivering directly to Maildir.<\/li>\n<li>It centralises <strong>authentication<\/strong> (system users, SQL, LDAP, etc.) for both IMAP and SMTP (via SASL).<\/li>\n<\/ul>\n<p>On a VPS, a badly tuned Dovecot can consume more RAM than you expect, especially with many concurrent IMAP clients. The goal is to keep it efficient without making users feel sluggish.<\/p>\n<h3><span id=\"Mail_storage_format_Maildir_vs_mdbox\">Mail storage format: Maildir vs mdbox<\/span><\/h3>\n<p>For most transactional environments with many small messages, <strong>Maildir<\/strong> is still a solid default:<\/p>\n<ul>\n<li>Each email is a separate file (simple to back up, easy to inspect).<\/li>\n<li>Works well with common backup tools and rsync.<\/li>\n<\/ul>\n<p>If you expect very large mailboxes (tens of gigabytes) and heavy IMAP usage, Dovecot\u2019s <strong>mdbox<\/strong> can be more efficient in disk usage and index performance, but it is more complex to handle manually.<\/p>\n<h3><span id=\"LMTP_delivery_from_Postfix_to_Dovecot\">LMTP delivery from Postfix to Dovecot<\/span><\/h3>\n<p>We strongly recommend using <strong>LMTP<\/strong> between Postfix and Dovecot instead of Postfix writing directly into Maildir. It gives cleaner separation of responsibilities and better error handling. A basic setup:<\/p>\n<ol>\n<li>In <code>\/etc\/dovecot\/dovecot.conf<\/code>, enable LMTP:<\/li>\n<\/ol>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">protocols = imap lmtp\n\nservice lmtp {\n  unix_listener \/var\/spool\/postfix\/private\/dovecot-lmtp {\n    mode = 0600\n    user = postfix\n    group = postfix\n  }\n}\n<\/code><\/pre>\n<ol start=\"2\">\n<li>In <code>\/etc\/postfix\/main.cf<\/code>, tell Postfix to use LMTP for local delivery:<\/li>\n<\/ol>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">virtual_transport = lmtp:unix:private\/dovecot-lmtp\n<\/code><\/pre>\n<p>This way, Dovecot owns the logic of placing mail into the right folders and updating indexes, which tends to be more robust at scale.<\/p>\n<h3><span id=\"Dovecot_process_limits_and_memory_usage\">Dovecot process limits and memory usage<\/span><\/h3>\n<p>In Dovecot, the main levers for VPS friendliness are:<\/p>\n<ul>\n<li><strong><code>default_process_limit<\/code><\/strong> in the <code>service imap<\/code> and <code>service lmtp<\/code> blocks.<\/li>\n<li><strong><code>service imap-login<\/code><\/strong> and <code>service pop3-login<\/code> <code>service_count<\/code> values.<\/li>\n<li><strong><code>auth_worker_max_count<\/code><\/strong> for heavy authentication loads.<\/li>\n<\/ul>\n<p>On a transactional\u2011focused VPS with limited IMAP usage, something like:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">service imap-login {\n  service_count = 1\n  process_min_avail = 2\n  process_limit = 50\n}\n\nservice imap {\n  process_limit = 256\n}\n\nservice auth-worker {\n  auth_worker_max_count = 20\n}\n<\/code><\/pre>\n<p>is usually adequate. Monitor memory usage over a few days and adjust upward only if you see a lot of \u201cprocess limit reached\u201d messages in the logs.<\/p>\n<h3><span id=\"SSLTLS_for_Dovecot\">SSL\/TLS for Dovecot<\/span><\/h3>\n<p>Like Postfix, Dovecot should not be exposing legacy SSL protocols. A minimal modern config:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">ssl = required\nssl_cert = &lt;\/etc\/ssl\/certs\/mail.example.com.pem\nssl_key  = &lt;\/etc\/ssl\/private\/mail.example.com.key\nssl_min_protocol = TLSv1.2\n<\/code><\/pre>\n<p>Reusing the same certificate and key as Postfix keeps management simple. Just ensure proper file permissions so only the Dovecot\/Postfix users and root can read the private key.<\/p>\n<h2><span id=\"5_Deliverability_and_Reputation_Configuration_Is_Only_Half_the_Story\">5. Deliverability and Reputation: Configuration Is Only Half the Story<\/span><\/h2>\n<h3><span id=\"Authentication_and_policies_SPF_DKIM_DMARC\">Authentication and policies: SPF, DKIM, DMARC<\/span><\/h3>\n<p>No matter how well\u2011tuned your Postfix queues are, unauthenticated or poorly authenticated mail will struggle to land in the inbox. At minimum you should:<\/p>\n<ul>\n<li>Publish a <strong>SPF<\/strong> record that includes only your actual sending IPs.<\/li>\n<li>Sign all outbound mail with <strong>DKIM<\/strong> using a stable selector.<\/li>\n<li>Publish a <strong>DMARC<\/strong> policy and monitor aggregate reports before moving to stricter enforcement.<\/li>\n<\/ul>\n<p>We cover the practical side of this (including specific DNS examples) in detail in our deliverability article <a href=\"https:\/\/www.dchost.com\/blog\/en\/spf-dkim-dmarc-ve-rdns-ile-e-posta-teslim-edilebilirligini-nasil-adim-adim-yukseltirsin\/\">\u201cInbox or Spam? A friendly, step\u2011by\u2011step guide to SPF, DKIM, DMARC and rDNS\u201d<\/a>. For high\u2011volume transactional sending, do not treat these as optional; they are essential.<\/p>\n<h3><span id=\"Dedicated_IPs_and_warming_strategy\">Dedicated IPs and warming strategy<\/span><\/h3>\n<p>For genuine high\u2011volume transactional workloads, we almost always recommend a <strong>dedicated sending IP<\/strong> rather than sharing with unrelated traffic. This lets your reputation reflect only your own practices.<\/p>\n<p>However, a new dedicated IP is a blank slate and must be <strong>warmed up<\/strong> gradually. That means:<\/p>\n<ul>\n<li>Start with low daily volume per provider (e.g. a few hundred emails to Gmail, Microsoft, Yahoo, etc.).<\/li>\n<li>Send only your <em>cleanest<\/em> traffic at first (password resets, order confirmations with low complaint probability).<\/li>\n<li>Increase volume slowly over 2\u20134 weeks while watching bounce and complaint rates.<\/li>\n<\/ul>\n<p>We documented a full warmup and reputation playbook in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/dedicated-ip-isitma-ve-e-posta-itibari-yonetimi\/\">dedicated IP warmup and email reputation management for transactional emails<\/a>. The tuning you do in Postfix is partly about <em>enabling<\/em> that controlled ramp\u2011up: you need working rate limits and queues so you do not accidentally send 50k messages to one provider on day one.<\/p>\n<h3><span id=\"Abuse_prevention_compromised_accounts_and_rate_limits\">Abuse prevention, compromised accounts and rate limits<\/span><\/h3>\n<p>On a VPS, one compromised SMTP password can destroy months of careful warmup in a single night. Combine Postfix and Dovecot controls to minimise this risk:<\/p>\n<ul>\n<li>Enforce <strong>strong passwords<\/strong> and, where applicable, per\u2011user throttling.<\/li>\n<li>Use Postfix\u2019s <strong><code>smtpd_client_message_rate_limit<\/code><\/strong> and <strong><code>smtpd_client_recipient_rate_limit<\/code><\/strong> to cap per\u2011client throughput.<\/li>\n<li>Enable <strong>submission\u2011only<\/strong> authentication on 587; do not allow roaming users to send through port 25.<\/li>\n<li>Track which SASL username is used for which volume and patterns; excessive bursts from one account should trigger alerts.<\/li>\n<\/ul>\n<p>If you want a deeper dive into outbound abuse control and shared vs VPS scenarios, we recommend our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/paylasimli-hosting-ve-vpste-outbound-e-posta-guvenligi-ve-smtp-rate-limit-yonetimi\/\">outbound email security and SMTP rate limit management on shared hosting and VPS<\/a>. The principles there map directly to a Postfix+Dovecot stack.<\/p>\n<h3><span id=\"Realworld_stack_Postfix_Dovecot_and_rspamd_together\">Real\u2011world stack: Postfix, Dovecot and rspamd together<\/span><\/h3>\n<p>In most high\u2011volume projects we end up with the same trio:<\/p>\n<ul>\n<li><strong>Postfix<\/strong> as the SMTP server and queue manager.<\/li>\n<li><strong>Dovecot<\/strong> for IMAP\/POP and LMTP delivery.<\/li>\n<li><strong>rspamd<\/strong> (or similar) for spam and content filtering, including outbound monitoring.<\/li>\n<\/ul>\n<p>If you want to see how this comes together end\u2011to\u2011end on a VPS, including config snippets and IP warmup, we have a dedicated walkthrough: <a href=\"https:\/\/www.dchost.com\/blog\/en\/vpste-e%e2%80%91posta-sunucusu-kurulumu-postfix-dovecot-rspamd-ile-teslim-edilebilirlik-ve-ip-isitma-adim-adim\/\">\u201cI Built My Own Mail Server: Postfix, Dovecot, rspamd, and the calm path to deliverability\u201d<\/a>. The article you are reading now is more focused on optimisation, but the build guide shows the full picture.<\/p>\n<h2><span id=\"6_Monitoring_Logs_and_a_Simple_Operations_Playbook\">6. Monitoring, Logs and a Simple Operations Playbook<\/span><\/h2>\n<h3><span id=\"What_to_watch_daily_and_weekly\">What to watch daily and weekly<\/span><\/h3>\n<p>A high\u2011volume transactional mail VPS should be observed like any other production system. At minimum, track:<\/p>\n<ul>\n<li><strong>Postfix queues<\/strong>: <code>mailq<\/code> output, especially the deferred queue; sudden growth signals remote issues or local resource limits.<\/li>\n<li><strong>Key log patterns<\/strong>: connection timeouts, DNS lookup failures, \u201ctoo many connections\u201d errors from big providers.<\/li>\n<li><strong>Resource usage<\/strong>: CPU, RAM, disk I\/O and free disk space (mail queues and logs can grow quickly under errors).<\/li>\n<li><strong>Delivery metrics<\/strong>: bounce codes by provider (4xx vs 5xx), complaint rates in postmaster tools.<\/li>\n<\/ul>\n<p>For CPU, RAM and disk I\/O tracking on a VPS, we often start with lightweight monitoring and gradually move to more advanced stacks as volume grows. Our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-kaynak-kullanimi-izleme-rehberi-htop-iotop-netdata-ve-prometheus\/\">monitoring VPS resource usage with htop, iotop, Netdata and Prometheus<\/a> covers practical setups you can reuse for mail servers.<\/p>\n<h3><span id=\"Log_rotation_and_retention\">Log rotation and retention<\/span><\/h3>\n<p>Postfix and Dovecot are both chatty, which is good for troubleshooting but dangerous for disk usage. Make sure:<\/p>\n<ul>\n<li><code>logrotate<\/code> is configured for your mail logs with daily rotation and compression.<\/li>\n<li>You keep at least a few weeks of logs during initial warmup, to investigate deliverability issues.<\/li>\n<li>Old logs are shipped off\u2011server if you need longer retention for compliance, rather than filling the VPS disk.<\/li>\n<\/ul>\n<p>Running out of disk space will cause sudden and hard\u2011to\u2011debug failures, including bounced messages and corrupt queues, so give logs and queues generous headroom.<\/p>\n<h3><span id=\"Simple_runbooks_for_operational_events\">Simple runbooks for operational events<\/span><\/h3>\n<p>Your mail stack becomes easier to operate when you have written answers for common scenarios, such as:<\/p>\n<ul>\n<li><strong>Queue suddenly large<\/strong>: check network connectivity, DNS resolution, remote 4xx bounce patterns; reduce concurrency temporarily if your VPS is overloaded.<\/li>\n<li><strong>Specific provider rejecting mail<\/strong>: capture exact bounce codes, check their postmaster portal, adjust warmup or content patterns.<\/li>\n<li><strong>One account sending abnormal volume<\/strong>: disable the account in Dovecot\/Postfix, investigate logs, reset credentials.<\/li>\n<\/ul>\n<p>Even a one\u2011page internal document with these steps can save hours when something unusual happens.<\/p>\n<h2><span id=\"7_Putting_It_All_Together_on_dchostcom_Infrastructure\">7. Putting It All Together on dchost.com Infrastructure<\/span><\/h2>\n<p>Transactional email is one of those workloads where a tuned VPS can give you both control and cost\u2011efficiency, as long as you respect the limits of the underlying hardware. On our side, we usually size Postfix+Dovecot deployments based on:<\/p>\n<ul>\n<li>Expected daily and peak\u2011hour message counts.<\/li>\n<li>Attachment patterns and typical message sizes.<\/li>\n<li>Number of active IMAP users and mailbox size expectations.<\/li>\n<li>Compliance or logging requirements (how long you must keep logs and message copies).<\/li>\n<\/ul>\n<p>Once the VPS or dedicated server resources are clear, we apply the patterns covered in this article: sensible Postfix concurrency and queue settings, LMTP delivery into Dovecot, modern TLS, strong authentication and rate limits, plus a cautious IP warmup and reputation plan. If you already have a Postfix+Dovecot setup and want to refactor it for higher volume, it is often possible to grow step\u2011by\u2011step instead of rebuilding from scratch.<\/p>\n<p>If you are planning a new transactional email stack or migrating away from a SaaS provider, our team at dchost.com can help you choose between a tuned VPS, a dedicated server or colocation for your own hardware, and design a Postfix+Dovecot architecture that fits your real\u2011world traffic and compliance needs. The key is to treat email as a first\u2011class production service: once your configuration, DNS, reputation and monitoring are aligned, a well\u2011designed VPS mail server can quietly power your business\u2011critical messages for years.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>When you move from a few hundred emails per day to tens or hundreds of thousands of transactional messages, your mail server stops being a side feature and becomes production\u2011critical infrastructure. Password resets, order confirmations, invoices, OTP codes and system alerts all depend on your SMTP stack responding quickly and consistently. On a VPS, that [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":4576,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-4575","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4575","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=4575"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4575\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/4576"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=4575"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=4575"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=4575"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}