Postfix'e Let's Encrypt TLS Sertifikası Kurma

Kendi mail sunucunu kurduğunda Postfix seni kendi ürettiği bir sertifikayla karşılar. O sertifika teknik olarak şifrelemeyi sağlar ama hiçbir istemci ona güvenmez: Outlook uyarı verir, telefon "sunucu kimliği doğrulanamıyor" der, kullanıcıların yarısı "yine de devam et" düğmesine basmayı öğrenir ve bu alışkanlık gerçek bir saldırıyı fark edilemez hâle getirir. Postfix TLS sertifikası kurulumu bu yüzden estetik bir iyileştirme değil, temel bir güvenlik adımıdır — üstelik Let's Encrypt sayesinde bedavadır.

Bu rehberde bir mail sunucusuna uçtan uca ücretsiz sertifika kurmayı anlatıyorum: sertifikayı almadan önce hangi ön koşulların sağlanması gerektiği, certbot ile hangi doğrulama yöntemini seçeceğin, Postfix'in main.cf ve master.cf dosyalarında hangi satırların ne işe yaradığı, aynı sertifikayı Dovecot'ta nasıl kullanacağın ve en önemlisi yenileme sonrası servislerin sertifikayı gerçekten okuması için gereken kancayı nasıl kuracağın. Sonunda kurulumu doğrulayacak komutlar ve en sık düşülen tuzaklar var.

Mail Sunucusunda TLS Neden Şart#

Web sunucusundaki TLS ile mail sunucusundaki TLS aynı şey değildir ve bu fark önemlidir. HTTPS'te şifreleme zorunludur; tarayıcı düz HTTP bağlantısını açıkça uyarır. SMTP'de ise sunucudan sunucuya teslimat tarihsel olarak açık metin üzerine kurulmuştur ve TLS, STARTTLS komutuyla fırsatçı biçimde devreye girer: iki taraf da destekliyorsa şifrelenir, desteklemiyorsa mesaj yine de gider.

Bu fırsatçı yapı bir sonuç doğurur: 25. portta TLS'i zorunlu kılarsan, TLS desteklemeyen sunuculardan gelen mailleri reddetmiş olursun ve bu, sana mail göndermeye çalışan kimi eski sistemleri tamamen keser. Buna karşılık kullanıcıların bağlandığı 587 ve 465 portlarında TLS kesinlikle zorunlu olmalıdır, çünkü orada bir kullanıcı adı ve parola ağ üzerinden geçer.

Geçerli bir sertifikanın ikinci faydası teslimat tarafındadır. Büyük sağlayıcıların bir kısmı geçerli sertifika sunan sunuculara daha olumlu davranır ve MTA-STS gibi politikalar geçerli sertifika olmadan çalışmaz. Yani sertifika, güvenliğin yanında gönderici itibarına da dolaylı katkı sağlar.

Sertifika Almadan Önce: Üç Ön Koşul#

Certbot'u çalıştırmadan önce üç şeyin doğru olduğundan emin ol; aksi hâlde doğrulama başarısız olur ve hata mesajı seni yanlış yöne götürebilir.

Birincisi, sertifika alacağın isim DNS'te gerçekten sunucunun IP'sine bakmalı. Let's Encrypt bu ismi doğrulamak için sunucuna bağlanır; A kaydı başka bir yeri gösteriyorsa doğrulama başarısız olur.

İkincisi, 80 ya da 443 portu doğrulama için erişilebilir olmalı (DNS doğrulaması kullanmıyorsan). Sunucuda web sunucusu yoksa --standalone modu geçici olarak 80. portu kendisi dinler; web sunucusu varsa --webroot modunu kullanırsın.

Üçüncüsü, sunucunun hostname'i ile sertifika alacağın isim aynı olmalı. Sunucu kendini mail.firmaniz.com olarak tanıtıyorsa sertifikayı da o isim için almalısın; farklı olursa istemciler isim uyuşmazlığı uyarısı verir.

# 1) DNS kontrolü — sunucunun gerçek IP'sini dönmeli
dig +short mail.firmaniz.com A
# 185.12.34.56

# 2) Hostname kontrolü
hostname -f
# mail.firmaniz.com

# 3) 80. portu kim tutuyor?
ss -tlnp | grep ':80 '

# 4) Certbot kurulu değilse
apt update && apt install certbot

Bu üçünün yanına dördüncü bir kontrol daha ekle: PTR kaydın da aynı ismi göstermeli. Sertifika bunu gerektirmez ama mail teslimatın gerektirir; ayrıntısı için mail sunucusu için rDNS/PTR kaydı yazısına bakabilirsin.

Certbot ile Sertifika Alma#

Üç doğrulama yöntemi var ve hangisini seçeceğin sunucunda web sunucusu olup olmadığına bağlı.

# YÖNTEM A — standalone: sunucuda web sunucusu YOKSA
# Certbot geçici olarak 80. portu kendisi dinler
certbot certonly --standalone \
  -d mail.firmaniz.com \
  --agree-tos -m [email protected] --no-eff-email

# YÖNTEM B — webroot: sunucuda çalışan bir web sunucusu VARSA
certbot certonly --webroot \
  -w /var/www/html \
  -d mail.firmaniz.com \
  --agree-tos -m [email protected] --no-eff-email

# YÖNTEM C — DNS doğrulaması: 80/443 dışarıya kapalıysa
# (DNS sağlayıcının certbot eklentisi gerekir; manuel de yapılabilir)
certbot certonly --manual --preferred-challenges dns \
  -d mail.firmaniz.com

Başarılı olduğunda sertifikalar şu dizine yazılır:

ls -l /etc/letsencrypt/live/mail.firmaniz.com/
# cert.pem       -> yalnızca sunucu sertifikası
# chain.pem      -> ara sertifika zinciri
# fullchain.pem  -> cert + chain (SUNUCULARDA BUNU KULLAN)
# privkey.pem    -> özel anahtar (gizli)

Buradaki en kritik ayrım cert.pem ile fullchain.pem arasındadır. Postfix ve Dovecot'ta fullchain.pem kullanmalısın; cert.pem kullanırsan ara sertifika sunulmaz ve bazı istemciler zinciri doğrulayamayıp bağlantıyı reddeder. Bu, kurulum sonrası "bende çalışıyor ama Outlook'ta çalışmıyor" tipi kafa karıştırıcı sorunların en yaygın sebebidir.

Standalone yöntemi kullanıyorsan ve sunucuda 80. portu tutan bir servis varsa, certbot çalışırken onu geçici durdurman gerekir. Bunu yenileme sırasında da yapması için --pre-hook ve --post-hook kullanabilirsin — ama daha temiz çözüm webroot yöntemine geçmektir.

Postfix Yapılandırması: main.cf ve master.cf#

Sertifika elindeyse asıl iş Postfix tarafında. main.cf dosyasına eklenecek satırlar ve her birinin ne yaptığı şöyle:

# /etc/postfix/main.cf

# --- Sunucu kimliği ---
myhostname = mail.firmaniz.com
smtpd_banner = $myhostname ESMTP

# --- Sertifika dosyaları (fullchain, cert DEĞİL) ---
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.firmaniz.com/fullchain.pem
smtpd_tls_key_file  = /etc/letsencrypt/live/mail.firmaniz.com/privkey.pem

# --- Gelen bağlantılar (25. port): fırsatçı TLS ---
# 'encrypt' YAZMA: TLS desteklemeyen sunuculardan gelen maili keser
smtpd_tls_security_level = may
smtpd_tls_loglevel = 1

# --- Giden bağlantılar: mümkünse şifrele ---
smtp_tls_security_level = may
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_tls_loglevel = 1

# --- Eski ve kırık protokolleri kapat ---
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

# --- Oturum önbelleği: el sıkışma maliyetini düşürür ---
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database  = btree:${data_directory}/smtp_scache

Kullanıcıların bağlandığı portlar master.cf dosyasında ayrı ayrı tanımlanır ve orada TLS zorunlu kılınır. Satır başındaki -o işaretleri, o servise özel geçersiz kılmalardır:

# /etc/postfix/master.cf

# 587 — submission, STARTTLS zorunlu
submission inet n  -  y  -  -  smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_tls_auth_only=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject

# 465 — smtps, örtük TLS (bağlantı en baştan şifreli)
smtps     inet  n  -  y  -  -  smtpd
  -o syslog_name=postfix/smtps
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject

smtpd_tls_auth_only=yes satırını atlama: bu satır olmadan istemci, TLS açmadan da kullanıcı adı ve parola göndermeye kalkabilir. Yapılandırmayı yükle ve söz dizimini doğrula:

# Söz dizimi kontrolü — hata varsa satırı söyler
postfix check

# Yapılandırmayı yeniden yükle (bağlantıları kesmez)
systemctl reload postfix

# Aktif TLS ayarlarını göster
postconf | grep -E "^smtpd_tls_(cert|key|security)"

Dovecot'u Aynı Sertifikayla Yapılandırma#

Kullanıcılar IMAP ile de bağlanacağı için Dovecot'un da aynı sertifikayı kullanması gerekir. Ayrı bir sertifika almana gerek yok; aynı dosyaları göstermen yeterli. Dovecot'ta yol tanımının başındaki < karakteri "bu dosyanın içeriğini oku" anlamına gelir ve unutulması klasik bir hatadır:

# /etc/dovecot/conf.d/10-ssl.conf

# TLS zorunlu — düz metin IMAP/POP3 kapalı
ssl = required

# Başlarındaki < karakteri ZORUNLU
ssl_cert = </etc/letsencrypt/live/mail.firmaniz.com/fullchain.pem
ssl_key  = </etc/letsencrypt/live/mail.firmaniz.com/privkey.pem

# Eski protokolleri kapat
ssl_min_protocol = TLSv1.2
ssl_prefer_server_ciphers = yes

Dovecot özel anahtarı okuyabilmelidir. Let's Encrypt dizinleri varsayılan olarak yalnızca root'a açıktır; Dovecot ana süreci root olarak başladığı için genelde sorun çıkmaz, ama bazı kurulumlarda izin ayarlaman gerekir:

# İzinleri kontrol et
ls -ld /etc/letsencrypt/live /etc/letsencrypt/archive
ls -l /etc/letsencrypt/archive/mail.firmaniz.com/privkey*.pem

# Gerekirse bir grup üzerinden erişim ver (özel anahtarı 'other'a AÇMA)
groupadd -f ssl-cert
chgrp -R ssl-cert /etc/letsencrypt/live /etc/letsencrypt/archive
chmod 0750 /etc/letsencrypt/live /etc/letsencrypt/archive
chmod 0640 /etc/letsencrypt/archive/mail.firmaniz.com/privkey*.pem

systemctl restart dovecot

Özel anahtara asla chmod 644 verme. Sunucudaki her kullanıcı okuyabilir hâle gelir ve sertifikanın koruduğu her şey anlamsızlaşır.

Otomatik Yenileme ve Deploy Hook#

Let's Encrypt sertifikaları 90 gün geçerlidir ve certbot yenilemeyi otomatik yapar. Ama burada, kurulumların yarısında atlanan kritik bir ayrıntı var: certbot sertifikayı yeniler, servisleri yeniden yüklemez. Postfix ve Dovecot sertifikayı başlangıçta belleğe okur; yenilenen dosyayı kendiliğinden fark etmezler. Sonuç, üç ay sonra bir sabah "sertifika süresi doldu" uyarılarıyla uyanmaktır.

Çözüm, yenileme sonrası çalışan bir deploy kancası yazmaktır:

# /etc/letsencrypt/renewal-hooks/deploy/reload-mail.sh
cat > /etc/letsencrypt/renewal-hooks/deploy/reload-mail.sh <<'EOF'
#!/bin/bash
# Sertifika yenilendikten SONRA çalışır; mail servislerine yeni dosyayı okutur
systemctl reload postfix
systemctl reload dovecot
EOF

chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-mail.sh

renewal-hooks/deploy/ dizinindeki betikler yalnızca sertifika gerçekten yenilendiğinde çalışır; her certbot renew denemesinde değil. Bu, gereksiz servis yeniden yüklemelerini önler. Kurulumu prova ederek test et:

# Gerçek yenileme yapmadan tüm süreci dene
certbot renew --dry-run

# Zamanlayıcının çalıştığını doğrula
systemctl list-timers | grep certbot

# Sertifikanın kaç gün ömrü kaldı
openssl x509 -enddate -noout -in /etc/letsencrypt/live/mail.firmaniz.com/cert.pem
# notAfter=Nov 23 09:14:07 2026 GMT

Doğrulama, Test ve Sık Yapılan Hatalar#

Kurulumu bitirdikten sonra dışarıdan test et. En doğrudan yöntem openssl ile bağlanıp zinciri incelemektir:

# 25. port — STARTTLS
openssl s_client -connect mail.firmaniz.com:25 -starttls smtp -servername mail.firmaniz.com

# 587 — submission
openssl s_client -connect mail.firmaniz.com:587 -starttls smtp

# 465 — örtük TLS
openssl s_client -connect mail.firmaniz.com:465

# 993 — IMAPS
openssl s_client -connect mail.firmaniz.com:993

# Postfix'in kendi test aracı: giden TLS davranışını gösterir
posttls-finger -c mail.firmaniz.com

Çıktıda aranacak üç şey var: Verify return code: 0 (ok) satırı zincirin doğrulandığını gösterir, subject=CN = mail.firmaniz.com ismin eşleştiğini gösterir, Protocol : TLSv1.3 (ya da 1.2) da modern bir sürümde anlaştığınızı gösterir. unable to get local issuer certificate görüyorsan neredeyse kesinlikle cert.pem kullanmışsındır; fullchain.pem ile değiştir.

Hangi komutu çalıştıracağından emin değilsen ya da port/TLS modu uyumunu hızlıca kontrol etmek istersen SMTP test aracı doğru komutları senin için üretir.

Şimdi en sık gördüğüm hatalar. Birincisi, cert.pem ile fullchain.pem karışıklığı — yukarıda anlattım, sunucuda daima fullchain.pem kullan. İkincisi, 25. portta smtpd_tls_security_level = encrypt yazmak; bu, TLS desteklemeyen gönderenlerden gelen mailleri tamamen reddeder ve sana mail gönderemeyen müşterilerin sebebini haftalarca bulamazsın. 25'te may, 587'de encrypt doğru ayrımdır. Üçüncüsü, deploy kancasını kurmamak; sertifika yenilenir ama servisler eskisini kullanmaya devam eder. Dördüncüsü, Dovecot'ta yol başındaki < karakterini unutmak; Dovecot yolu sertifikanın kendisi sanır ve açılışta hata verir. Beşincisi, özel anahtara geniş izin vermek. Altıncısı, sertifikayı yalnızca mail.firmaniz.com için alıp istemcilere firmaniz.com sunucu adını vermek; isim uyuşmazlığı uyarısı çıkar. İstemci ayarlarında hangi ismi söylüyorsan sertifikayı o isim için al, ya da her iki ismi tek sertifikaya ekle (-d mail.firmaniz.com -d firmaniz.com). Yedincisi, standalone modu kullanıp yenileme anında 80. portu tutan bir servisi durdurmayı unutmak; yenileme sessizce başarısız olur.

Kurulum sonrası mail akışını da bir kez baştan sona test et: kendine bir mail gönder, /var/log/mail.log içinde TLS connection established satırını gör ve alıcı tarafındaki mail başlığında (version=TLSv1.3 cipher=...) ifadesinin göründüğünü doğrula. Bu satır, şifrelemenin gerçekten devrede olduğunun kanıtıdır.

Sıkça Sorulan Sorular#

Let's Encrypt sertifikası mail sunucusunda ücretsiz mi#

Evet, tamamen ücretsizdir ve ticari kullanımda da kısıtı yoktur. Sertifika 90 gün geçerlidir ve certbot yenilemeyi otomatik yapar. Tek maliyetin, yenileme sonrası servisleri yeniden yükleyen bir deploy kancası kurmak için harcayacağın beş dakikadır. Ücretli sertifikaların mail sunucusu tarafında sağladığı ek bir teknik avantaj yoktur.

25. portta TLS'i zorunlu kılmalı mıyım#

Hayır, kılmamalısın. 25. port sunucudan sunucuya teslimat içindir ve TLS orada fırsatçı çalışır. Zorunlu kılarsan TLS desteklemeyen gönderenlerden gelen mailleri tamamen reddedersin; bu, sana mail göndermeye çalışan müşterilerin sessizce engellenmesi demektir. Doğru ayrım şudur: 25'te may, kullanıcıların bağlandığı 587 ve 465'te zorunlu TLS.

Sertifika yenilendi ama hâlâ eski görünüyor, neden#

Neredeyse her zaman aynı sebep: certbot dosyayı yeniledi ama Postfix ve Dovecot sertifikayı başlangıçta belleğe okuduğu için yeni dosyayı fark etmedi. Çözüm, /etc/letsencrypt/renewal-hooks/deploy/ altına systemctl reload postfix ve systemctl reload dovecot çalıştıran çalıştırılabilir bir betik koymaktır. Bu betikler yalnızca gerçek bir yenileme olduğunda tetiklenir.

Tek sertifikayla hem Postfix hem Dovecot çalışır mı#

Evet, çalışır ve önerilen yöntem de budur. Aynı fullchain.pem ve privkey.pem dosyalarını her iki servise de gösterirsin; ayrı sertifika almana gerek yoktur. Tek dikkat edilmesi gereken, Dovecot yapılandırmasında yol tanımının başına < karakterini koymayı unutmamak ve özel anahtarın dosya izinlerini gereğinden fazla açmamaktır.

Sertifikamın doğru kurulduğunu nasıl kontrol ederim#

openssl s_client -connect mail.firmaniz.com:587 -starttls smtp komutunu çalıştır ve çıktıdaki üç satıra bak: Verify return code: 0 (ok) zincirin doğrulandığını, subject=CN alanı ismin eşleştiğini, Protocol satırı da anlaşılan TLS sürümünü gösterir. unable to get local issuer certificate hatası alıyorsan cert.pem yerine fullchain.pem kullanman gerekiyor demektir.

Kendi imzalı sertifika kullanmanın zararı ne#

Şifreleme sağlar ama kimlik doğrulaması sağlamaz; istemci karşı tarafın gerçekten senin sunucun olduğunu doğrulayamaz. Pratik sonucu, her istemcide güvenlik uyarısı çıkması ve kullanıcıların bu uyarıyı görmezden gelmeyi öğrenmesidir — ki bu, gerçek bir araya girme saldırısını fark edilemez hâle getirir. Ücretsiz ve otomatik yenilenen bir alternatif varken kendi imzalı sertifikada kalmanın makul bir gerekçesi yoktur.

Kapanış#

Postfix'e TLS sertifikası kurmak yarım saatlik bir iştir ama yanlış yapılan üç ayrıntı aylar sonra sorun olarak geri döner. Aklında tutman gereken dört alışkanlık şunlar: sunucularda daima fullchain.pem kullan, 25. portta TLS'i fırsatçı bırakıp 587 ve 465'te zorunlu kıl, yenileme sonrası servisleri yeniden yükleyen deploy kancasını mutlaka kur ve özel anahtarın dosya izinlerini dar tut. Kurulumdan sonra openssl s_client ile dışarıdan bir doğrulama yapmayı da rutinine ekle; "kurdum, çalışıyordur" varsayımı bu konuda en pahalı varsayımdır.

Kendi mail sunucunu barındıracak bir makineye ihtiyacın varsa tam root erişimli VDS ve sanal sunucu paketlerimiz uygun bir zemin sunar. Postfix, Dovecot, DKIM ve otomatik yenilenen bir Let's Encrypt sertifikası kurulu hâlde teslim edilen bir sistem istiyorsan SMTP sunucu paketimiz bu adımların tamamını hazır getirir; kurulum ve bakım yükünü tamamen devretmek istersen sunucu yönetimi hizmetimiz sertifika yenilemesi dahil tüm zinciri üstlenir. Web tarafındaki sertifika ihtiyaçların için SSL sayfamıza da göz atabilirsin.