E-posta Kara Liste Kontrolü: Araçların Size Anlatmadıkları

Gönderen IP adresinizi çoklu bir listede sorguladığınızda yeşil ve kırmızı satırlardan oluşan bir tablo görürsünüz. Bu tablo dar bir soruyu yanıtlar: bu adres şu anda bir dizi genel DNS kara listesinde var mı? Bir e-posta kara liste kontrolü, Gmail, Outlook ya da kurumsal bir ağ geçidinin bir sonraki mesajınızı kabul edip etmeyeceğini söylemez. İki soruyu aynı saymak, olay zaman çizelgelerinin çoğunun yanlış yöne gittiği noktadır.

Bu rehber, bir kontrolün gerçekte neyi sorguladığını, dig ile kendi kontrolünüzü nasıl yapacağınızı, hangi sonuç kodlarının “temiz”, hangilerinin “sorgunuz reddedildi” anlamına geldiğini ve tüm süreci izlemeye nasıl bağlayacağınızı anlatıyor. Böylece bunu sabaha karşı ikide elle yapmak zorunda kalmazsınız.

Bir kara liste kontrolü yalnızca bir DNS sorgusudur

Her DNS kara listesi (DNSBL) aynı şekilde çalışır. IPv4 adresinin oktetlerini ters çevirir, listenin bölge adını ekler ve bir A kaydı istersiniz. RFC 5782 bu kuralı tanımlar: 192.0.2.99 adresi bad.example.com ile kontrol edilirse sorgu 99.2.0.192.bad.example.com olur. Adres listedeyse 127.0.0.0/8 aralığında bir yanıt alırsınız. Listede değilse hiç kayıt dönmez.

Mekanizma bu kadar. IP yapıştırdığınız web araçları, arka planda bunlardan onlarcasını paralel çalıştırıp yanıtları biçimlendirir.

# 203.0.113.25 adresi Spamhaus ZEN listesinde mi?
dig +short 25.113.0.203.zen.spamhaus.org A

# Alan adı tabanlı bir liste aynı mantıkla çalışır, ters çevirme yoktur:
dig +short example.com.dbl.spamhaus.org A

Boş çıktı listede olmadığı anlamına gelir. 127.x.x.x yanıtı listede olduğunuzu gösterir ve son oktetler hangi alt listenin eşleştiğini söyler. Bunu kendi kontrol ettiğiniz bir makineden, kendi çözümleyicinizle çalıştırırsanız betiğe dökebilir, kaydedebilir ve uyarı kurabilirsiniz.

Kontrolü web sitenizin değil, postanızın çıktığı adreste yapın

İlk hata yanlış IP'ye bakmaktır. Pazarlama siteniz, API'niz ve giden posta sunucunuz genellikle üç farklı adres kullanır. Önemli olan, bir posta kutusuna gerçekten ulaşmış bir mesajın Received başlığındaki IP'dir.

Paylaşımlı altyapıdaki bir ESP üzerinden gönderiyorsanız o IP size ait değildir ve listeleme de size ait olmaz. Özel bir IP kullanıyorsanız, o aralığın önceki kiracısının yaptıkları dahil her şey size aittir.

IP'yi panelde yazan bir ayardan değil, gerçekten iletilmiş bir mesajdan alın. Sonra üç ayrı şeyi kontrol edin: gönderen IP'yi, zarf ve From alan adlarını ve bağlantılarınızda geçen tüm alan adlarını, izleme ve abonelikten çıkma sunucuları dahil. URIBL ve SURBL gibi URI tabanlı listeler mesaj gövdesindeki bağlantıları puanlar. Yani IP'niz temiz olsa bile listelenmiş bir alan adına işaret eden bir mesaj korunmaz.

Genel bir çözümleyiciden gelen temiz sonuç, gizli bir reddetme olabilir

Genel web kontrol sayfalarının hiç anlatmadığı hata budur. Spamhaus, genel ya da açık çözümleyiciler üzerinden gelen sorguları yanıtlamaz; bunu bir listeleme yerine bir dönüş koduyla bildirir. Spamhaus, 127.255.255.254 kodunu bir itibar sonucu değil, bir hata kodu olarak belgeler ve bu kodla postayı asla reddetmemeniz gerektiğini söyler.

Bunun iki sonucu var. Betiğiniz 127.x yanıtını “listede” diye okursa, bulut çözümleyicisinden reddedilen bir sorgu var olmayan bir listeleme için sizi uyandırır. Betiğiniz “kullanılabilir yanıt yok”u “temiz” diye okursa gerçek listelemeleri sessizce kaçırırsınız, çünkü reddetme boş yanıt ya da NXDOMAIN olarak da görünebilir.

Çözüm, kendi özyinelemeli çözümleyicisi ve doğru ters DNS'i olan bir sunucudan sorgu yapmak ya da Spamhaus'un genel ayna kullanıcılarını yönlendirdiği ücretsiz sorgu servisini kullanmaktır. Sonucuna güvenmeden önce bölgeyi doğrulayın. RFC 5782, IPv4 listelerinin 127.0.0.2 girişini taşımasını ve 127.0.0.1 için giriş olmamasını şart koşar. Kurulumunuzu şöyle test edebilirsiniz:

dig +short 2.0.0.127.zen.spamhaus.org A   # 127.x bir yanıt dönmeli
dig +short 1.0.0.127.zen.spamhaus.org A   # hiçbir şey dönmemeli

İkisi de boş dönerse çözümleyici yolunuz bozuk ya da reddediliyordur. Oradan gelen herhangi bir sonucu okumadan önce bunu düzeltin.

Teslimat sorunlarının çoğu kara liste sorunu değildir

Bir bounce incelemesinde, herhangi bir sorgudan önce sorulacak ilk soru alıcı sunucunun tam olarak ne dediğidir. Bir listeleme belirli bir türde red üretir. Alıcı sağlayıcıdaki itibar sorunları ise farklı bir red üretir ve hiçbir genel liste bunları göstermez.

Google'ın gönderici belgeleri bu konuda açık. 550 5.7.1 yanıtı gönderen IP'nin askıya alınmış bir listede olduğu anlamına gelebilir; çoğu zaman bu, paylaşımlı IP itibarının zayıf olmasından kaynaklanır. 5.7.26 ise kimlik doğrulamanın başarısız olduğunu gösterir. Toplu gönderenler için Google; SPF, DKIM ve DMARC, gönderen IP'de geçerli ileri ve ters DNS, TLS ve Postmaster Tools'ta yüzde 0,30'un altında bir spam oranı ister. Gmail gönderici gereksinimleri önerilen hedef olarak yüzde 0,10'u gösterir.

Bunu bir işlem sırası gibi okuyun:

• Bounce metni bir DNSBL bölgesi ya da URL'si adlandırıyorsa, o belirli listede listelisiniz. Sorguyu çalıştırın, sonra listenin kendi kaldırma sayfasını kullanın.

• “IP itibarı” ifadesi içeren 550 5.7.1: alıcı sağlayıcı tarafında bir itibar sorunu, çoğunlukla paylaşımlı bir IP'de. Postmaster Tools'a ve hacim ile şikayet eğilimine bakın.

• 5.7.26: kimlik doğrulama başarısız. SPF, DKIM ve DMARC hizalamasını kontrol edin.

• 4.7.28 ya da hız sınırı ifadesi: mevcut itibarınız için çok hızlı gönderiyorsunuz. Hızı düşürün, sonra kademeli olarak artırın.

Bir liste sorgusu bu durumların hiçbirini açıklamaz. Bounce metnini okumadan kara liste kontrolüne başlamak, sonucu zaten bildiğiniz bir şeyi doğrulamak için bir saat harcamak demektir.

Tek seferlik web kontrolünü izleme yerine koymayın

Tek bir sorgu, enter tuşuna bastığınız andaki durumu söyler. Listelemeler çoğu zaman geçicidir ve birçoğu, zaten kendi neden olduğunuz bir artıştan sonra ortaya çıkar: soğuk bir içe aktarım, yeniden izin toplama gönderimi ya da spam iletmek için kötüye kullanılan bir form.

“Sizi 100 kara listeden çıkarırız” diye ücret alan hizmetler, çoğu listenin sahip olmadığı bir sorunu satıyor. Tipik bir çoklu kontrolde yer alan listelerin birçoğu ana akım posta sağlayıcıları üzerinde ihmal edilebilir bir etki yapar ve kaldırma çoğunlukla operatörün kendi sayfasından ücretsiz ve self-servis olarak yapılır. Her kırmızı satırın peşine düşmek, alıcılarınızın gerçekten baktığı iki üç listeye ait olması gereken zamanı harcar.

Listeleri gönderdiğiniz trafiğe göre sıralayın. Bounce'larınızda hangi alıcıların göründüğüne bakın, bu alıcıların kamuya açık olarak kullandığı listeleri bulun ve onları izleyin. Diğerleri, ayda bir gözden geçirebileceğiniz gürültüdür.

Kontrolü eşik uyarılı planlı bir işe dönüştürün

Ayakta kalan en küçük sürüm şöyle: gerçek bir çözümleyicisi olan bir sunucudan çalışır, önce bölgeyi doğrular ve üç sonucu ayırır: listede, listede değil, sorgu reddedildi.

import socket

def dnsbl(ip: str, zone: str) -> str:
    rev = ".".join(reversed(ip.split(".")))
    try:
        answer = socket.gethostbyname(f"{rev}.{zone}")
    except socket.gaierror:
        return "not_listed"
    if answer.startswith("127.255.255."):
        return "refused"   # hata kodu, itibar sonucu değil
    return f"listed:{answer}"

# Sonuca güvenmeden önce bölgeyi doğrulayın (RFC 5782 test girişleri)
assert dnsbl("127.0.0.2", "zen.spamhaus.org").startswith("listed")
assert dnsbl("127.0.0.1", "zen.spamhaus.org") == "not_listed"

Her gönderen IP ve gönderen alan adı için 15 ila 60 dakikada bir çalıştırın, her sonucu zaman damgasıyla kaydedin ve yalnızca not_listed durumundan listed durumuna geçişte uyarın. refused durumunu ayrıca uyarın; çünkü bu, itibarınızın değiştiği anlamına gelmez, izlemenizin kör olduğu anlamına gelir.

Bunu kara listelerin geride kaldığı sinyallerle eşleştirin. Postmaster panolarındaki şikayet oranı, alıcı alan adına göre bounce oranı ve saatlik ertelenme oranı, bir listeleme görünmeden önce hareket eder. Göndermeyi duraklatıp duraklatmayacağınıza bu sayılar karar verir. Loglarınızı ve metriklerinizi zaten bir izleme yığınına gönderiyorsanız, liste sonucu yalnızca başka bir zaman serisidir.

Bu iş akışına, sorunun nerede olduğuna bağlı olarak dört araç uyar.

Postmark yalnızca işlemsel bir hizmettir; şifre sıfırlamalarınız başkasının bülten gönderimiyle aynı gönderim yolunu paylaşmaz. Listelemeleriniz paylaşımlı altyapıdaki bir komşuya kadar izleniyorsa, işlemsel ve pazarlama gönderimini ayırmak yapısal çözümdür.

SendGrid, büyük hacimde en uzun geçmişe sahip hizmetlerden biridir ve özel IP sunar. Bu da itibarın ve kara liste riskinin yalnızca sizin olduğu anlamına gelir. Özel IP'lerin gerektirdiği ısındırma ve izlemeyi ekibiniz karşılayamıyorsa atlayın.

Better Stack, yukarıdaki betiğin planlı iş tarafındaki parçasıdır: uptime tarzı kontroller, uyarılar ve nöbet yönlendirmesi. Böylece yeni bir listeleme bir log dosyasına değil, bir insana ulaşır.

Listelendiğinizde kaldırma talebinden önce nedeni düzeltin

Kök neden olmadan kaldırma talebi birkaç gün kazandırır. Aynı davranışla aynı adresi tekrar gören bir liste operatörü onu yeniden listeler ve bazıları tekrarlayan listelemeleri daha sert cezalandırır.

Şu sırayla çalışın:

1. Listelenen IP'den gönderimi durdurun ya da yavaşlatın. Kötü trafik sürdükçe listeleme uzar ve yenileri eklenir.

2. Liste operatörünün listeleme kaydını okuyun. Birçoğu kanıtı belirtir: bir spam tuzağına düşme, bir hacim artışı ya da bir röle kötüye kullanım raporu.

3. Kaynağı bulun. Form uç noktalarında açık röle kötüye kullanımını kontrol edin, son içe aktarmalara bakın ve son bir hafta içinde göndermeye başlayan yeni entegrasyonları inceleyin.

4. Nedeni düzeltin, sonra operatörün kendi kaldırma sürecini kullanın. Bazı listeler sessiz bir dönemden sonra listelemeleri otomatik olarak süresi dolmuş sayar.

5. En çok etkileşen alıcılardan başlayarak düşük hacimde yeniden başlayın ve bir hafta boyunca şikayet oranını ve ertelemeleri izleyin.

Eksik ters DNS tekrar eden bir katkı nedenidir. Google, geçerli PTR kayıtlarını gönderici gereksinimleri arasında sayar. Ters kaydı olmayan bir gönderen IP, içerik değerlendirilmeden önce birçok alıcı tarafından düşük güvenilirlikli görülür.

Akışı listeye değil sinyale göre kurun

Ürününüz aktivasyon, fatura ya da güvenlik e-postaları gönderiyorsa bir listeleme, bu akışlar için bir erişilebilirlik olayıdır. Öyle ele alın: işlemsel postayı pazarlama hacminden ayrı bir yoldan gönderin ve tetikleyici katmanı teslimat durumundan haberdar edin. Böylece takılan bir aktivasyon e-postası uygulama içi bir hatırlatmaya geri döner.

Customer.io, tam da bu nedenle sıklıkla ayrı bir teslimat sağlayıcısıyla eşleştirilen olay odaklı katmandır. Davranışsal tetikleyiciler ve mesaj mantığı bir yerde durur, teslimat başka bir yerde. Akışları yeniden yazmadan teslimatı değiştirebilir ya da bölebilirsiniz. Bedeli, gözlemlenebilir tutulması gereken bir sistem daha olmasıdır.

Kopyalamaya değer kısım bu ayrımdır, farklı sağlayıcılar seçseniz bile. Bir kara liste olayı, bir mesajın nereye gittiğini değiştirmeli; mantığınızın çalışıp çalışmadığını değil.

Bu hafta neyi kurmalısınız

Üç şey var, getirisine göre sıralı. Birincisi, bölge doğrulamalı ve ayrı bir refused durumu olan, kendi çözümleyicisi olan bir sunucudan planlı bir sorgu. İkincisi, bounce'larınızın alıcı alan adına göre dağılımı; böylece trafiğiniz için hangi listelerin önemli olduğunu bilirsiniz. Üçüncüsü, bounce metniyle başlayıp kaldırma adımıyla biten yazılı bir runbook; böylece nöbetteki kişi doğaçlama yapmak zorunda kalmaz.

Hangi gönderen alan adınız bir gün listelenirse fark etmezsiniz?