mailcow mailleri neden spam klasörüne düşüyor

Kısa cevap: sorun mailcow'un içinde değil

mailcow mailleri neden spam klasörüne düşüyor? Cevap neredeyse her zaman mailcow'un dışındadır. Alıcı sunucu mesajın gövdesine bakmadan önce üç şey sorar: bu mesaj hangi IP adresinden geldi, o IP kendini hangi adla tanıttı, o adın sahibi bu gönderime izin veriyor mu. Bu soruların cevabı IP adresinizde ve alan adınızın DNS kayıtlarında durur. Kurulum kusursuz olsa bile bu katman eksikken mesaj spam klasörüne düşer, bazen de kuyrukta bekleyip hiç çıkmaz.

Sunucuyu henüz kurmadıysanız önce bir VPS üzerinde mailcow ile kendi e-posta sunucunuzu kurma adımlarını bitirin. Bu yazı kurulumun bittiği, ilk mailin gönderildiği ve spam klasöründe bulunduğu andan başlar.

Kontroller arıza sırasına göre dizildi ve sıra önemli. 25. port kapalıysa SPF kaydını düzeltmenin hiçbir etkisi olmaz, çünkü mesaj alıcıya hiç ulaşmaz. Her adımı kendi sunucunuzda çalıştıracağınız bir komutla kontrol edeceksiniz. Komutların çıktısını burada yazmıyoruz: çıktı sizin IP adresinize ve alan adınıza göre değişir, iş çıktıdaki iki değeri birbiriyle karşılaştırmakta.

sudo apt update && sudo apt install -y bind9-dnsutils netcat-openbsd

Örneklerde alan adı ornek.com.tr, sunucu adı mail.ornek.com.tr ve IP adresi 203.0.113.10 olarak geçiyor. Komutları çalıştırırken kendi değerlerinizi yazın.

25. port bu sunucudan dışarı çıkıyor mu

Giden e-posta 587 veya 465 ile gitmez. İstemciniz mailcow'a 587 ile bağlanır, ama mailcow alıcı sunucuya her zaman 25. port ile bağlanır. Sağlayıcı bu portu giden yönde kapatmışsa Postfix bağlantıyı kuramaz, mesajı kuyrukta tutar ve günlerce yeniden dener. Kullanıcı tarafında bu tablo spam klasörüne düşmekten çok, mesajın hiç gitmemesi gibi görünür.

nc -vz gmail-smtp-in.l.google.com 25
timeout 10 openssl s_client -starttls smtp -connect gmail-smtp-in.l.google.com:25

Kuyruğa ve günlüğe de bakın. mailcow komutları kurulum dizininden çalışır.

cd /opt/mailcow-dockerized
docker compose exec -T postfix-mailcow postqueue -p
docker compose logs --tail=200 postfix-mailcow

Günlükte connect to ...[...]:25: Connection timed out biçiminde satırlar birikiyorsa bağlantı dışarı çıkmıyor demektir. Bu noktada sunucunun içinde yapacak bir şey yoktur, çünkü engel sunucuda değil ağın kenarındadır. Sağlayıcınıza destek talebi açın ve tek bir soru sorun: bu IP adresi için 25. port giden yönde açık mı, değilse açılabilir mi. Politika sağlayıcıdan sağlayıcıya değişir, bu yüzden cevabı tahmin etmeyin, yazılı olarak isteyin. Port kapalı kalacaksa o adresten kendi başınıza gönderim yapamazsınız. Kalan seçenek, çıkışı kimlik doğrulamalı bir relay üzerinden yapmaktır (mailcow tarafında bu smarthost ayarıdır).

PTR kaydı mailcow'un HELO adıyla aynı mı

Alıcı sunucu bağlantıyı kabul ettiği anda IP adresinizin ters DNS kaydına (PTR, pointer record) bakar ve bunu sizin HELO ile bildirdiğiniz adla karşılaştırır. mailcow bu adı MAILCOW_HOSTNAME değerinden alır. PTR hiç yoksa, ya da sağlayıcının otomatik verdiği, içinde IP adresinin rakamları geçen genel bir ad ise, mesaj daha ilk saniyede puan kaybeder. Bazı büyük alıcılar PTR kaydı olmayan adresten gelen bağlantıyı tamamen reddeder.

curl -s https://api.ipify.org; echo
dig -x 203.0.113.10 +short
grep MAILCOW_HOSTNAME /opt/mailcow-dockerized/mailcow.conf
docker compose exec -T postfix-mailcow postconf -h myhostname
dig +short mail.ornek.com.tr A

Bu çıktılar arasında iki eşitlik arıyorsunuz. PTR kaydının döndürdüğü ad, MAILCOW_HOSTNAME ve myhostname değerleriyle aynı olmalı. O adın A kaydı da geri dönüp aynı IP adresine çözülmeli. İkincisi ileri doğrulanmış ters DNS denen kontroldür ve birçok filtre bunu ayrıca bakar.

PTR kaydını siz ekleyemezsiniz. Kayıt alan adınıza değil IP adresine aittir, yani adres bloğunu yöneten sağlayıcıya. Panelinizde reverse DNS ya da rDNS alanı varsa oradan yazın. Yoksa destek talebinde istediğiniz adı açıkça belirtin.

IPv6 aynı kurala tabidir. Sunucunuzun AAAA kaydı varsa mailcow IPv6 üzerinden de gönderebilir ve o adres için de PTR gerekir. IPv6 tarafında PTR ayarlayamıyorsanız IPv6 ile gönderimi kapatmak, eksik PTR ile göndermeye devam etmekten iyidir.

SPF kaydı: sizin adınıza kim gönderebilir

SPF (sender policy framework), alan adınız adına hangi adreslerin gönderim yapabileceğini söyleyen bir TXT kaydıdır. mailcow belgelerinin önerdiği kayıt kısadır.

ornek.com.tr.   TXT   v=spf1 mx a -all

Bu kayıt şunu söyler: alan adının MX ve A kayıtlarındaki adresler gönderebilir, başka adres gönderemez. Sondaki -all sert reddir, ~all ise yumuşak. Kaydı yayınladıktan sonra iki şeyi DNS'ten geri okuyun.

dig +short ornek.com.tr TXT
dig +short ornek.com.tr MX

İki hata burada sık çıkar. Birincisi, alan adında tek bir SPF kaydı olmalı. İki ayrı v=spf1 TXT kaydı varsa kontrol permerror ile sonuçlanır ve SPF hiç geçmez, iki kaydı tek satırda birleştirin. İkincisi, SPF zarf göndericisine (MAIL FROM) bakar, kullanıcının gördüğü From satırına bakmaz. Bu yüzden mesaj bir posta listesinden ya da yönlendirmeden geçtiğinde SPF kırılır, DKIM imzası ise sağ kalır. Aynı alan adından fatura ya da şifre sıfırlama maili atan uygulamalarınız varsa onlar da bu kayda dahil olmalı. Kendi barındırdığınız uygulamalardan mail göndermenin temiz yolu, uygulamayı mailcow üzerinden kimlik doğrulamalı gönderim yapacak şekilde ayarlamaktır, böylece SPF kaydına ikinci bir IP eklemek zorunda kalmazsınız.

DKIM: anahtarı mailcow üretir, TXT kaydını siz yayınlarsınız

DKIM (domainkeys identified mail) mesajı imzalar. mailcow'da imzayı Rspamd atar ve özel anahtar sunucuda durur. Alıcı, imza başlığındaki seçiciyi (selector) okur, o seçiciye ait açık anahtarı DNS'ten çeker ve imzayı doğrular. Anahtar sunucuda üretilir, ama doğrulamayı mümkün kılan şey DNS'te yayınladığınız TXT kaydıdır. Kurulumdan sonra spam klasörüne düşmenin en sık sebebi tam olarak budur: anahtar panelde vardır, kayıt DNS'te yoktur.

Yönetim arayüzünde Configuration bölümündeki ARC/DKIM keys ekranına girin, alan adını seçin, seçici olarak dkim ve anahtar uzunluğu olarak 2048 bit ile devam edin. mailcow anahtar çiftini üretir ve yayınlamanız gereken kaydı ekranda gösterir. Kaydın adı ve biçimi şöyledir.

dkim._domainkey.ornek.com.tr.   TXT   v=DKIM1; k=rsa; t=s; s=email; p=MIIBIjANBgkq...

p= değeri uzundur ve tek bir TXT kaydına tek parça halinde sığmalıdır. Kaydı yayınladıktan sonra DNS'ten geri okuyun.

dig +short dkim._domainkey.ornek.com.tr TXT

Üç hata bu adımda tekrar eder. Panelde kayıt adına alan adını ikinci kez yazmak, kaydı dkim._domainkey.ornek.com.tr.ornek.com.tr adına koyar ve alıcı onu asla bulamaz: çoğu panelde ad alanına yalnızca dkim._domainkey yazılır. Panelin uzun değeri satırlara bölmesi, p= içine boşluk ya da satır sonu sokar, imza doğrulanmaz. Üçüncüsü, anahtarı panelde yeniden üretip DNS'i güncellememektir, çünkü eski açık anahtar yeni imzayı doğrulamaz. Kayıt yayınlandıktan sonra hemen her yerde görünmeyebilir: eski değer TTL süresi boyunca önbelleklerde kalır, bu bekleme normaldir ve bir DNS kaydının nasıl yayıldığını bilmek burada işinizi kolaylaştırır.

DMARC: p=none ile başlayın

DMARC (domain-based message authentication, reporting and conformance) alıcıya iki şey söyler: SPF ve DKIM başarısız olursa ne yapsın, ve sonucu nereye bildirsin. Politikayı en zararsız değerle açın.

_dmarc.ornek.com.tr.   TXT   v=DMARC1; p=none; rua=mailto:dmarc@ornek.com.tr; fo=1

p=none hiçbir mesajı elemez, yalnızca rapor toplar. Bu ayrım önemli, çünkü DMARC hizalama (alignment) ister: SPF ya da DKIM'in geçmesi yetmez, geçen alan adının From satırındaki alan adıyla aynı olması gerekir. İlk gün p=reject yayınlarsanız ve DKIM kaydınızda bir harf eksikse, kendi mesajlarınızı kendi elinizle reddettirirsiniz. Birkaç hafta rapor okuyun, sonra DMARC politikasını p=none'dan quarantine ve reject'e taşıma adımlarını sırayla uygulayın.

dig +short _dmarc.ornek.com.tr TXT

Büyük alıcıların 2024'te yürürlüğe giren toplu gönderim kuralları, en azından SPF veya DKIM'in geçmesini ve hizalı bir DMARC kaydının bulunmasını şart koşuyor. Eylül 2026 itibarıyla küçük hacimli gönderimde de pratik beklenti aynı: kayıtlar eksiksiz olacak.

Sonucu okuyun, sonuca güvenmeyin

Kayıtlar yayında olsa bile işin bittiğini varsaymayın. Her alıcı kendi filtresini kendi verisiyle çalıştırır, bu yüzden tek bir test kutusuna gelen mesaj hiçbir şey kanıtlamaz. Türkiye'deki alıcılar ağırlıkla Gmail, Outlook ve Yandex kullanıyor, o yüzden üçünde birer test kutusu açın ve mailcow üzerindeki gerçek bir posta kutusundan, SOGo web arayüzünden, üçüne de kısa bir mesaj gönderin.

Sonra mesajın ham başlıklarını açın. Gmail'de mesajı açıp sağ üstteki üç nokta menüsünden Orijinali göster seçeneğine girin. Outlook.com'da mesaj menüsünden Görüntüle bölümündeki ileti kaynağını açın. Yandex Mail'de mesaj menüsünden mesaj özelliklerini açın. Aradığınız iki başlık her üçünde de aynıdır.

Authentication-Results satırı ne söyler

Alıcı sunucu kendi doğrulama sonucunu mesajın en üstüne yazar. Satır şu biçimdedir.

Authentication-Results: mx.google.com;
       dkim=pass header.i=@ornek.com.tr header.s=dkim;
       spf=pass (google.com: domain of veli@ornek.com.tr designates 203.0.113.10 as permitted sender) smtp.mailfrom=veli@ornek.com.tr;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ornek.com.tr

Bu satırı kendi mesajınızda bulun ve değerleri tek tek okuyun. dkim=none, mesajda hiç imza olmadığını söyler: sorun DNS'te değil sunucudadır, alan adı mailcow'da tanımlı değil ya da anahtar üretilmemiştir. dkim=fail imzanın var olduğunu ama açık anahtarla doğrulanmadığını söyler, TXT kaydına dönün. spf=softfail ya da spf=fail, gönderen adresin SPF kaydında bulunmadığı anlamına gelir, parantez içindeki IP adresini kendi sunucunuzun adresiyle karşılaştırın. spf=pass ve dkim=pass yanında dmarc=fail görüyorsanız sorun hizalamadır: geçen alan adı From satırındaki alan adı değildir.

Received satırları yolu gösterir

Received başlıkları mesajın yolunu ters sırada tutar, yani en üstteki satır alıcı tarafında en son yazılandır. O satırda iki değere bakın. Parantez içindeki ad, sunucunuzun HELO ile bildirdiği addır ve myhostname değeriyle aynı olmalı. Yanındaki IP, alıcının gördüğü gönderen adresidir. O adres sizin sunucunuzun adresi değilse mesaj bir aracı üzerinden çıkıyor demektir, ve o zaman SPF ile PTR kontrollerini o adres için yapmanız gerekir.

Hepsi geçiyor ama mesaj hâlâ spam klasöründe

İki durum kaldı ve ikisini de DNS düzelterek çözemezsiniz.

Birincisi yeni IP adresi. Kimlik doğrulama, mesajın sizden geldiğini kanıtlar. İtibar ise alıcının sizinle geçmişte ne yaşadığını söyler, ve yeni bir adresin geçmişi yoktur. Alıcı, hiç mesaj görmediği bir adresten gelen ani hacmi şüpheli sayar. Isınma (warm-up) dönemi budur: ilk günlerde az sayıda gerçek yazışma gönderin, cevap alan mesajları tercih edin, hacmi haftalar boyunca kademeli artırın. Satın alınmış listeye ya da tek seferde yüzlerce adrese gönderim bu süreci tersine çevirir. En hızlı yardım, alıcılarınızdan spam klasöründeki mesajı spam olmadığını bildiren düğmeyle işaretlemesini istemektir.

İkincisi, elinize geçtiğinde zaten engel listesinde olan bir IP adresi. Adresi sizden önce başkaları kullandıysa bu mümkündür. Kontrolü web formundan yapın, çünkü DNS tabanlı sorgular açık çözücüler üzerinden geldiğinde çoğu liste yanıt vermez. Kendi sunucunuzdan denemek isterseniz sorguda adresin oktetleri ters yazılır.

dig +short 10.113.0.203.zen.spamhaus.org

Kayıt bulursanız iki seçeneğiniz var: listenin kendi formundan silinme talebi açmak, ya da sağlayıcıdan başka bir IP adresi istemek. Silinme kabul edilse bile makinenizin dışarıya istenmeyen mesaj göndermediğinden emin olun, yoksa liste geri gelir. Kontrol ve geri bildirim için Spamhaus sorgu formu, Google Postmaster Tools, Yandex Postoffice ve Microsoft'un gönderen destek portalı kullanılır.

İçerik de puan alır. Tek bir bağlantıdan oluşan HTML gövde, kısaltılmış bağlantılar ve yeni kaydedilmiş alan adları filtrede aleyhinize çalışır. Test mesajınızı düz metin alternatifi olan, kısa ve gerçek bir mesaj olarak yazın.

.tr ve .com.tr alan adları kuralları değiştirir mi

Hayır. SPF, DKIM, DMARC ve PTR kontrollerinin hiçbiri alan adı uzantısına bakmaz. Aynı kayıtlar, aynı biçimde, aynı sonucu verir. Tek pratik fark panel tarafında çıkabilir: bazı kayıt panelleri uzun TXT değerlerini ya da alt alan adı kayıtlarını rahat kabul etmez. Böyle bir durumda alan adının DNS yönetimini ayrı bir DNS sağlayıcısına taşıyıp kayıtları orada tutmak en kolay yoldur. Değişen şey kural değil, kaydı nereye yazdığınızdır.

Bu bakımın tamamı size ağır geliyorsa geri adım atmak da bir karardır. E-postayı kendiniz barındırmanın hâlâ mantıklı olup olmadığı sorusunun cevabı, gönderdiğiniz mesajın türüne ve hacmine bağlıdır.

FAQ: sık sorulan sorular

mailcow kurdum ama mailler hiç gitmiyor, kuyrukta bekliyor. Neden?

Bu tablo spam filtresinden çok kapalı bir çıkışa benzer. Giden SMTP 25. portu kullanır. Kuyruğu docker compose exec -T postfix-mailcow postqueue -p, günlüğü docker compose logs --tail=200 postfix-mailcow ile okuyun. Bağlantı zaman aşımı satırları birikiyorsa nc -vz gmail-smtp-in.l.google.com 25 ile dışarı çıkışı deneyin ve sağlayıcınıza bu IP adresi için 25. portun giden yönde açık olup olmadığını sorun. Kapalıysa sunucu tarafında çözüm yoktur: ya port açılır, ya gönderim bir relay üzerinden yapılır.

PTR kaydını kendim ekleyebilir miyim?

Hayır. PTR kaydı alan adınızın değil IP adresinin kaydıdır, ve o adres bloğunu yöneten sağlayıcıya aittir. Sağlayıcı panelinde reverse DNS alanı varsa oradan, yoksa destek talebiyle ayarlanır. Talepte mailcow'un HELO adını, yani MAILCOW_HOSTNAME değerini yazın. Aynı adın A kaydı da geri dönüp aynı IP adresine çözülmeli.

DKIM anahtarını yeniden ürettim, imzalar bozuldu. Ne oldu?

Yeni özel anahtarla imzalanan mesajlar, DNS'te duran eski açık anahtarla doğrulanmaz, sonuç dkim=fail olur. Panelin gösterdiği yeni değeri dkim._domainkey kaydına yazın, sonra dig +short dkim._domainkey.ornek.com.tr TXT ile geri okuyup p= değerinin tek parça olduğunu doğrulayın. Eski kayıt önbelleklerden düşene kadar TTL süresi kadar karışık sonuç görebilirsiniz.

Mesajım Gmail'e ulaşıyor ama Outlook tarafında hiç görünmüyor. Sebep ne?

Her alıcı kendi filtresini kendi verisiyle çalıştırır, bu yüzden bir tarafın kabul etmesi diğeri için bilgi taşımaz. Outlook tarafında mesaj hiç görünmüyorsa postfix günlüğünde o teslime ait satırı bulun: mesaj kabul edildiyse sorun filtrelemedir, reddedildiyse ret metni sebebi söyler. Yeni adreslerde ilk bakılacak iki yer ısınma dönemi ve engel listesi kontrolüdür.

.com.tr alan adı spam sayılma ihtimalini artırır mı?

Uzantının kendisi bir puan değildir. Kimlik doğrulama kontrolleri her uzantı için aynı çalışır. Fark yaratan şey alan adının yaşı ve gönderim geçmişidir: yeni kaydedilmiş bir alan adı, uzantısı ne olursa olsun, ilk haftalarda daha temkinli karşılanır.