"Postfix'i kurduk ve mail'lerimiz spam'a gidiyor" sık duyduğum bir cümle, ve çözüm neredeyse hiçbir zaman Postfix'in configuration'ında değil. Mail server'lar, Postfix, Exim, ne seçerseniz seçin, kolay kısım, onlarca yıldır çözülmüş problemler. Bir e-postanın inbox'a mı yoksa spam klasörüne mi gideceğini gerçekte belirleyen, domain'iniz için mail göndermeye yetkili olduğunuzu kanıtlayan DNS kayıtlarının kombinasyonu, ve zamanla (ya da hiç) inşa edilen bir sending reputation.
SPF: domain'iniz adına kim gönderebilir
SPF (Sender Policy Framework), domain'iniz adına mail göndermeye yetkili server'ları listeleyen bir DNS TXT kaydı:
example.com. TXT "v=spf1 ip4:203.0.113.10 -all"
Bu şu anlama geliyor: example.com'dan gelen mail'ler sadece 203.0.113.10'dan gelmeli, ve -all, bunun dışındaki her şeyin receiving server'lar tarafından doğrudan reject edilmesi gerektiği anlamına geliyor. En yaygın SPF hatası eksik bir kayıt değil, fazla permissive bir SPF kaydı (her yerde ~all, ya da artık kullanılmayan service'leri içeren entry'ler) ya da, aynı derecede kötüsü, kimsenin hatırlamadığı bir forwarding service'ten gelen legitimate mail'i bozacak kadar strict bir kayıt.
DKIM: mesajın değiştirilmediğini kanıtlamak
DKIM (DomainKeys Identified Mail), outgoing mesajları bir private key'le imzalıyor, ve eşleşen public key'i DNS'te yayınlıyor, böylece receiving server'lar signature'ın transit'te tamper edilmediğini doğrulayabiliyor:
mail._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."
Çoğu mail server yazılımı (örneğin Postfix'in yanında OpenDKIM) bu key pair'i sizin için generate ediyor, asıl iş public yarıyı doğru şekilde yayınlamak ve outgoing mail'in gerçekten sign edildiğinden emin olmak, ki bunu varsaymak yerine direkt kontrol etmeye değer:
echo "test" | mail -s "DKIM test" [email protected]
sonra alınan mesajın header'larında dkim=pass'a bakın.
DMARC: SPF ya da DKIM fail ederse receiver'lara ne yapacaklarını söylemek
DMARC, SPF ve DKIM'i birbirine bağlıyor ve receiving server'lara ikisini de fail eden mail'lerle ne yapacaklarını, ve bununla ilgili report'ların nereye gideceğini söylüyor:
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
p=reject ile değil p=quarantine ile başlamak (fail'leri doğrudan reject etmek yerine spam'a göndermek), özellikle ilk haftalarda daha güvenli bir rollout, çünkü bu, herhangi bir misconfiguration'a, mail'in basitçe ortadan kaybolmadan görünürlük kazandırıyor. rua report'ları burada gerçekten kullanışlı, hangi source'ların domain'iniz adına mail gönderdiğini ve pass edip etmediklerini tam olarak gösteriyor.
PTR kayıtları: sizin kontrol etmediğiniz tek DNS kaydı... ama host'unuz ediyor
Bir PTR kaydı (reverse DNS), server'ınızın IP adresini hostname'ine geri map'liyor, ve birçok receiving mail server, bunun server'ınızın SMTP greeting'inde sunduğu hostname'le eşleşip eşleşmediğini kontrol ediyor. Diğer kayıtların aksine, bu kendi DNS zone'unuzda değil, hosting provider'ınız tarafından set ediliyor, çoğu VPS provider'ında bir IP üzerinde reverse DNS set etmek için control panel'de bir opsiyon ya da bir support ticket'ı var. Bir server mail.example.com olarak mail gönderiyor ama IP'sinin PTR kaydı vps-1234.providername.com gibi bir şeye resolve ediyorsa, bu tek başına bazı filtreler tarafından flag'lenmeye yetiyor.
DNS kayıtlarının düzeltemeyeceği kısım: reputation
SPF, DKIM, DMARC, ve PTR'ın hepsi doğru olsa bile, mail gönderen yepyeni bir IP adresinin hiçbir history'si yok, ve bazı receiving server'lar, ne kadar doğru configure edilmiş olursa olsun, tanımadığı sender'lara karşı daha temkinli davranıyor. "Warm-up" işte burada önem kazanıyor: e-postayla gerçekten etkileşime gireceğinden (açacağından, spam olarak işaretlemeyeceğinden) emin olduğunuz adreslere düşük volume'le başlamak, ve dün sıfır mail gönderen bir server'dan birden binlerce mesaj göndermek yerine volume'ü kademeli olarak artırmak. Mükemmel DNS'i ve sıfır sending history'si olan yeni bir mail server bile yavaş bir başlangıçtan faydalanıyor, reputation bir dosyada configure edilmiyor, günler ve haftalar içinde inşa ediliyor.
Dört kaydı doğru yapın, mail-tester.com gibi bir tool'la mail'lerin gerçekten sign edildiğini ve doğru align edildiğini kontrol edin, ve yeni bir sending IP'ye herhangi bir time-sensitive işe güvenmeden önce bir track record inşa etmesi için zaman verin. Bu kombinasyon, "neden mail'imiz spam'a gidiyor" durumlarının büyük çoğunluğunu hallediyor, ve bunların neredeyse hiçbiri mail server yazılımının kendisinden kaynaklanmıyor.