[ OK ]Kernel başlatılıyor...
~/im/blog
Beni İşe Alın

Konuşalım

Çözülmesi gereken bir altyapı probleminiz mi var veya projeniz için desteğe mi ihtiyacınız var? Yeni projeler için bana ulaşabilirsiniz.

İletişime geç

Bağlantılar

Beni sosyal medyada ve profesyonel ağlarda bulun.

© 2026 Irfan Miral. Tüm hakları saklıdır.Geliştiren:Irfan Miral
Gizlilik PolitikasıŞartlar & Koşullar
Ana SayfaHizmetlerHakkımda/ÖzgeçmişBlogİletişimAraçlar
2026-05-07• 6 dk okuma süresi

Spam Kutusuna Düşmeyen Bir Posta Sunucusu Kurmak

Hosting Email DNS Server Administration

Reklam

"Postfix'i kurduk ama gönderdiğimiz tüm e-postalar doğrudan spam'e gidiyor", sürekli duyduğum bir cümledir. Ve bu sorunun çözümü neredeyse hiçbir zaman Postfix'in kendi yapılandırma (config) dosyalarında gizli değildir.

Posta sunucuları—Postfix, Exim ya da hangisini seçerseniz seçin—işin inanılmaz derecede kolay olan kısmıdır. Bunlar tam anlamıyla on yıllar önce çözülmüş problemlerdir. Bir e-postanın bir gelen kutusuna güvenle inip inmeyeceğini veya agresif bir şekilde spam klasörüne fırlatılıp fırlatılmayacağını asıl belirleyen şey; kendi alan adınızdan (domain) mail gönderme izniniz olduğunu matematiksel olarak kanıtlayan DNS kayıtlarının birleşimi ve zamanla dikkatlice inşa edilen bir gönderici itibarıdır (sending reputation).

SPF: Sizin adınıza kimler mail gönderebilir?

SPF (Sender Policy Framework), tam olarak hangi spesifik IP adreslerinin sizin alan adınızdan geliyormuş gibi görünen postalar gönderebileceğini katı bir şekilde listeleyen bir DNS TXT kaydıdır:

example.com.  TXT  "v=spf1 ip4:203.0.113.10 -all"

Bu aslında doğrudan şunu söyler: example.com'dan gelen postalar kesinlikle sadece 203.0.113.10 adresinden gelmelidir ve -all, alıcı sunuculara geri kalan her şeyin acımasızca reddedilmesi (reject) gerektiğini söyler.

En yaygın SPF hatası aslında bir kaydın eksik olması değildir. Çok fazla izin veren, fazla esnek bir SPF kaydıdır (her yerde ~all kullanmak veya artık kullanmadığınız rastgele üçüncü parti hizmetleri içermesi gibi). Veya en az bunun kadar kötüsü, o kadar inanılmaz derecede katıdır ki, birisinin listeye eklemeyi unuttuğu bir yönlendirme servisinden (forwarding) gelen meşru (legit) e-postaları bile bozar.

DKIM: Mesajın yolda değiştirilmediğini kanıtlamak

DKIM (DomainKeys Identified Mail), giden mesajları gizli bir anahtarla (private key) kriptografik olarak imzalar. Buna uyan açık anahtarı (public key) doğrudan DNS'inizde yayınlar, böylece alıcı sunucular imzanın taşıma sırasında kurcalanmadığını anında doğrulayabilir (verify):

mail._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

Çoğu modern posta sunucusu yazılımı (Postfix'in yanında çalışan OpenDKIM gibi) bu anahtar çiftini sizin için otomatik olarak üretir. Asıl yapmanız gereken iş, açık olan yarısını doğru bir şekilde yayınlamak ve giden postaların gerçekten imzalandığından emin olmaktır. Sadece körü körüne çalıştığını varsaymak yerine kesinlikle doğrudan test etmeye değecek bir adımdır:

echo "test" | mail -s "DKIM test" [email protected]

Ardından, alınan mesajın ham (raw) üstbilgilerinde (headers) açıkça dkim=pass ibaresini arayın.

DMARC: SPF veya DKIM başarısız olursa alıcılara ne yapacaklarını söylemek

DMARC, SPF ve DKIM'i birbirine bağlar. Her iki testten de tamamen başarısız olan e-postalarla ne yapmaları gerektiğini ve bu konuyla ilgili günlük raporları (reports) tam olarak nereye göndermeleri gerektiğini alıcı sunuculara açıkça söyler:

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

İşe p=reject yerine p=quarantine (başarısız olanları doğrudan reddetmek yerine spam klasörüne gönder) ile başlamak çok daha güvenli bir yaygınlaştırma (rollout) stratejisidir, özellikle de ilk birkaç hafta boyunca. Bu, yanlışlıkla yapılandırdığınız herhangi bir şeyin o mailler hiçliğe karışmadan size anında görünür olmasını sağlar. Buradaki rua raporları gerçekten işe yarar; tam olarak hangi kaynakların sizin alan adınız gibi davranıp mail göndermeye çalıştığını ve bu katı kontrolleri başarıyla geçip geçemediklerini gösterirler.

PTR kayıtları: Kontrol etmediğiniz o tek DNS kaydı

Bir PTR kaydı (Ters DNS - Reverse DNS), sunucunuzun IP adresini tam olarak ana bilgisayar adına (hostname) geri eşler. Devasa miktarda alıcı posta sunucusu, bu eşleşmenin sunucunuzun ilk SMTP selamlama mesajında (greeting) sunduğu hostname ile mükemmel bir şekilde uyuşup uyuşmadığını aktif olarak kontrol eder.

Diğer üç kaydın aksine bu kayıt tamamen barındırma sağlayıcınız (hosting provider) tarafından kontrol edilir, kendi DNS bölgenizde (zone) bulunmaz. Çoğu VPS sağlayıcısının, bir IP üzerinde ters DNS (reverse DNS) ayarlamak için basit bir kontrol paneli seçeneği veya bu işe özel bir destek bileti (ticket) kategorisi vardır. Eğer sunucunuz gururla mail.example.com olarak mail gönderiyorsa, ancak IP'sinin PTR kaydı körü körüne vps-1234.providername.com gibi çirkin bir şeye çözümleniyorsa, sadece bu uyumsuzluk bile agresif spam filtreleri tarafından anında fişlenmeniz (flagged) için fazlasıyla yeterlidir.

DNS kayıtlarının asla düzeltemeyeceği kısım: İtibar (Reputation)

SPF, DKIM, DMARC ve PTR tamamen kusursuz olsa bile, yeni oluşturulmuş bir IP adresinin e-posta gönderme geçmişi tam anlamıyla sıfırdır. Çoğu devasa alıcı sunucu (Gmail veya Microsoft gibi), DNS'leri teknik olarak ne kadar mükemmel yapılandırılmış olursa olsun, tanıdık olmayan göndericilere son derece temkinli yaklaşır.

İşte tam da bu noktada IP'nizi "ısıtmak" (warming up) son derece önemlidir. E-posta ile aktif olarak etkileşime gireceğinden (açıp, yanıtlayacağından, sadece görmezden gelmeyeceğinden) kesinlikle emin olduğunuz adreslere çok düşük bir hacimle (volume) gönderim yapmaya başlayın. Dün tam olarak sıfır mesaj göndermiş bir sunucudan bugün aniden binlerce mesaj fırlatmak yerine, bu hacmi yavaş yavaş artırın.

Kusursuz DNS'e ve sıfır gönderim geçmişine sahip yepyeni bir posta sunucusu, yine de çaresizce o yavaş başlangıca ihtiyaç duyar. İtibar, günler ve haftalar boyunca sancılı bir şekilde inşa edilir; öylece bir metin dosyasında yapılandırılmaz.

Bu dört spesifik kaydı tam olarak doğru yapın. Postanın gerçekten imzalandığını ve mail-tester.com gibi bir araç kullanarak mükemmel bir şekilde hizalandığını (align) doğrulayın. Ardından, yepyeni bir gönderici IP'sine, zamana duyarlı (time-sensitive) herhangi bir görev için ona agresif bir şekilde güvenmeden önce o sağlam geçmişi inşa etmesi için gerçekten ihtiyacı olan zamanı verin. Bu kombinasyon, "maillerimiz neden spam'e gidiyor" vakalarının ezici çoğunluğunu güvenilir bir şekilde çözer. Neredeyse hiçbirinin altından posta sunucusu yazılımının kendisi çıkmaz.

Reklam

Yardıma mı ihtiyacınız var?

Eğer Mail Sunucusu Kurulumu ve İletilebilirlik işini sizin yerinize birinin halletmesini tercih ederseniz, benim asıl işim tam olarak bu.

İletişime Geç
ÖncekiAWS'nin Yanında Neden Hala OVH ve Contabo Öneriyorum?Sonraki Ters Vekil (Reverse Proxy) Olarak HAProxy mi Nginx mi? Nasıl Karar Veriyorum