Posta Listesi Hijyeni: Gönderim Öncesi Adres Ayıklama Hattı
Liste hijyeni bir temizlik işi değil, gönderimden önce çalışan bir kabul kontrolü katmanıdır. Rol, tipografik hatalı ve tuzak olma ihtimali yüksek adresleri SMTP'ye dokunmadan, ucuzdan pahalıya sıralı bir filtre hattıyla nasıl ayıklayacağınızı ve recycled spam-tuzaklarını zamanlama ile nasıl engelleyeceğinizi anlatıyoruz.
EvilMail Team14 Temmuz 202612 dk okuma
Alınmış ya da yıllardır dokunulmamış 50.000 kişilik bir listeyi ilk kez patlatan ekiplerin çoğu aynı duvara çarpar: gönderimden 20 dakika sonra Spamhaus CSS listelemesi, Gmail tarafında domain reputation'ın "High"dan "Low"a düşmesi ve haftalarca süren spam-klasörü sürgünü. Sebep genellikle tek bir adrestir. Recycled bir spam-tuzağına atılan tek bir mesaj, IP ve domain itibarınızı aylarca yakar; bunu bounce raporunda göremezsiniz bile, çünkü tuzak mektubu sessizce kabul eder.
Satın alınmış ya da uzun süre bakımsız kalmış bir listede adreslerin tipik olarak %8-15'i çürüktür (hard bounce üretir), %0,1-0,5'i ise tuzaktır. Sorunu çözmenin yolu "bounce'ları temizlemek" değildir, çünkü o zaten gecikmiş bir tepkidir: zarar gönderim anında oluşur. Doğru yaklaşım, adresi SMTP'ye hiç dokunmadan göndermeden önce sınıflandırmaktır. Bu yazı, ucuzdan pahalıya sıralı çalışan bir kabul kontrolü (admission control) hattı kurar ve teknik filtrenin göremediği tuzakları zamanlama ile engeller.
Çürük adresin anatomisi: neyi neden eliyoruz
Dört ayrı sınıf var ve her biri teslimata farklı biçimde zarar verir. Hepsini "geçersiz" kovasına atmak yanlıştır, çünkü müdahaleleri farklıdır.
Sözdizimi / tipografik hatalı:gmial.com
Posta Listesi Hijyeni: Gönderim Öncesi Adres Filtreleme | evilmail.pro — EvilMail Blog
,
@gmail.con
,
hotnail.com
, sondaki boşluklar, çift nokta. Bunlar temiz
hard bounce
üretir. Zararsız görünür ama yüksek bounce oranı (>%2) tek başına spam sınıflandırıcısını tetikler.
Rol adresleri:info@, sales@, support@, postmaster@, abuse@ (RFC 2142). Bunlar bir kişiye değil bir ekibe gider; kimse opt-in etmemiştir, dolayısıyla şikayet oranını (complaint rate) patlatır ve bazıları doğrudan abuse ekiplerine düşer.
Disposable / temp-email: evilmail dahil geçici posta domain'leri. Kullanıcı adresi bir kez açar, bir daha dönmez. Bu adresler açılma/tıklama üretmez, engagement metriklerinizi aşağı çeker.
Spam-tuzakları: İki tür. Pristine tuzak hiçbir zaman gerçek sahibi olmamış, yalnızca satın alınmış/kazınmış listelerde bulunan honeypot'tur. Recycled tuzak ise terk edilmiş gerçek bir adresin, ESP tarafından ~6-12 ay sonra tuzağa çevrilmiş halidir. İkisi de itibarı yakar; recycled olan özellikle sinsidir, çünkü liste bir zamanlar meşruydu.
Disposable tarafını içeriden biliyoruz: evilmail.pro'nun ürettiği domain'ler döner bir havuzdan gelir ve MX kayıtları ortaktır. Tespitin doğru yolu adresin local part'ına bakmak değil, domain'i güncel bir disposable listesine karşı eşlemektir — çünkü kullanıcı adı tamamen rastgeledir ve hiçbir desen taşımaz.
Filtre hattı: ucuzdan pahalıya sıralı kabul kontrolü
Mimari karar tek cümlede: her katman bir sonrakine daha az adres bırakır, en pahalı ve en riskli kontrol en sona gelir. Sözdizimi kontrolü mikrosaniye sürer ve RAM'de biter; SMTP probu ise saniyeler sürer, ağ gerektirir ve kendi IP itibarınızı riske atar. Onu 50.000 adresin tamamına uygulamak hem yavaş hem tehlikelidir. Bu yüzden hattı bir huni gibi kurarsınız.
Katman 1-2: sözdizimi, normalizasyon ve yerel desen tespiti
RFC 5321'e tam uyumlu bir e-posta regex'i yazmaya kalkmayın. O gramer o kadar geniştir ki (yorumlar, quoted-string local part'lar, IP literal'ler) doğru regex okunamaz ve yine de teslim edilebilirliği garanti etmez. Pratik kural: adresin kabacalocal@domain yapısına uyduğunu doğrulayan hafif bir kontrol yapın, geri kalanı MX katmanına bırakın. Doğrulamanın gerçek kanıtı sözdizimi değil, domain'in mektup kabul edip etmediğidir.
Normalizasyon dedup için kritik. Gmail için nokta anlamsızdır ve +etiket yok sayılır: [email protected], [email protected] ile aynı posta kutusudur. Bunları katlamadan dedup ederseniz aynı kişiye üç kez gönderirsiniz. IDN domain'leri doğrulamadan önce punycode'a çevirin (köln.de → xn--kln-sna.de).
Tipografik düzeltme için en yaygın alıcı domain'lerine — gmail.com, hotmail.com, outlook.com, yahoo.com, icloud.com — Damerau-Levenshtein mesafesi ≤2 ile yakınlık ölçün. gmial.com, gmai.com, gmail.con, hotnail.com, yahooo.com bu şekilde yakalanır. Bunları otomatik silmeyin, karantinaya alıp düzeltme önerin; çünkü gmail.co gerçek bir Kolombiya domain'i olabilir.
javascript
// Gmail normalizasyonu + basit sözdizimi + tipo karantinası
const GMAILISH = new Set(["gmail.com", "googlemail.com"]);
const COMMON = ["gmail.com","hotmail.com","outlook.com","yahoo.com","icloud.com"];
function normalize(raw) {
const email = raw.trim().toLowerCase();
if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email)) return { ok: false, reason: "syntax" };
let [local, domain] = email.split("@");
if (GMAILISH.has(domain)) {
local = local.split("+")[0].replace(/\./g, "");
domain = "gmail.com";
}
for (const good of COMMON) {
if (domain !== good && damerau(domain, good) <= 2) {
return { ok: false, reason: "typo", suggest: `${local}@${good}` };
}
}
return { ok: true, value: `${local}@${domain}`, domain };
}
Rol ve disposable listelerini statik tutmayın. Rol listesi RFC 2142 çekirdeğiyle başlar (postmaster, abuse, hostmaster, webmaster, noc, security, info, sales, support, marketing) ama pratikte hello, contact, team, billing gibi eklemeler gerekir. Disposable domain listesini ise haftalık güncelleyin; bu havuz sürekli döner ve evilmail gibi sağlayıcılar düzenli olarak yeni domain devreye alır.
Katman 3: DNS ve MX doğrulama
Bu katman ölü domain'leri eler ve neredeyse bedavadır. dig ile MX kaydını sorgulayın; MX yoksa RFC 5321 gereği A/AAAA kaydına düşülür.
bash
$ dig +short MX gmail.com
10 alt1.gmail-smtp-in.l.google.com.
5 gmail-smtp-in.l.google.com.
# MX yok — A kaydına düş
$ dig +short MX brokendomain.example
$ dig +short A brokendomain.example
93.184.216.34
# Null MX (RFC 7505): domain açıkça "mektup kabul etmiyorum" diyor
$ dig +short MX no-mail.example
0 .
Karar mantığı nettir: geçerli MX varsa kabul et. MX yoksa ama A/AAAA varsa koşullu kabul et (bazı küçük domain'ler hâlâ böyle çalışır). 0 . şeklinde null MX dönüyorsa bu kesin ret sinyalidir — RFC 7505 bunun "bu domain e-posta almaz" anlamına geldiğini söyler, tereddütsüz suppress edin. Ne MX ne A varsa domain ölüdür, reddedin.
Katman 4: SMTP RCPT probu — ne zaman, neden dikkatli
En pahalı ve en yanlış anlaşılan katman. Hedef MX'e bağlanır, MAIL FROM:<> (boş envelope-from, böylece bir bounce zinciri tetiklemezsiniz) ve RCPT TO:<hedef> gönderir, dönen kodu okur, DATA göndermedenQUIT dersiniz. Mektup asla iletilmez.
$ nc gmail-smtp-in.l.google.com 25
220 mx.google.com ESMTP
EHLO mta.evilmail.pro
250 mx.google.com at your service
MAIL FROM:<>
250 2.1.0 OK
RCPT TO:<[email protected]>
250 2.1.5 OK # kutu var
RCPT TO:<[email protected]>
550 5.1.1 The email account does not exist # kutu yok
QUIT
Kulağa kesin çözüm gibi geliyor ama üç tuzağı var:
Catch-all (accept-all) domain'ler. Bazı domain'ler her RCPT'ye 250 döner — var olmayan kutular dahil. Bu domain'lerde SMTP sonucu anlamsızdır. Onları silmeyin, "riskli / doğrulanamaz" olarak işaretleyin ve engagement geçmişiyle karar verin.
Greylisting. İlk denemede 450/451 (4xx) dönebilir. Bu geçersiz demek değildir — sunucu "sonra tekrar dene" diyor. 4xx'i asla hard bounce saymayın; retry gerektirir.
Kendi itibarınız. Yüksek hacimde RCPT probu, MX operatörlerinin gözünde adres toplama (harvesting) gibi görünür ve ana gönderen IP'nizi kara listeye sokabilir. Bu yüzden: düşük hacim, gönderim IP'nizden ayrı bir IP, agresif throttle.
Dürüst tavsiyem: çoğu ekip bu katmanı atlamalı. Katman 1-3 riskin büyük kısmını zaten alır. SMTP probunu yalnızca yüksek değerli, elle küçük listeler için ve ayrı bir IP'niz varsa çalıştırın. Toplu liste için getirisi, taşıdığı itibar riskine değmez.
Spam-tuzaklarını göndermeden önce engellemek
Tüm bu teknik doğrulama bir tuzağı göremez. Recycled bir tuzak, geçerli MX'e sahip, RCPT'ye 250 dönen, sözdizimi kusursuz gerçek bir adrestir. Filtre hattınız onu temiz sayar. Gerçek savunma teknik değil, zamanlamadır.
İki kural pratikte tuzakların çoğunu keser. Birincisi, satın alınmış ya da kazınmış listeyi asla kullanmayın — pristine tuzak yoğunluğu oralarda en yüksektir ve teknik doğrulama bunu göstermez; tek doğru karar hiç göndermemektir. İkincisi, bir sunset policy uygulayın: son açma/tıklama >180 gün ise adresi re-engagement segmentine alın, tek bir "hâlâ ilgileniyor musun?" kampanyası gönderin; >270 gün ve hiç yanıt yoksa suppression listesine taşıyın. Recycled tuzaklar terk edilmiş adresler olduğundan, zamanında budayan bir liste tuzak penceresine hiç girmez.
Ölçüm ve geri besleme: hangi sinyalleri izle
Gönderdikten sonra körlemesine ilerlemeyin. Google Postmaster Tools domain reputation'ı (High/Medium/Low/Bad) ve spam oranını gösterir; hedef <%0,1, kesin tavan <%0,3. Microsoft SNDS + JMRP (FBL) Outlook/Hotmail tarafındaki şikayetleri verir. Bounce'ları ayırın: hard bounce (5xx) anında suppress, soft bounce (4xx) sınırlı retry sonrası suppress. Bounce oranı hedefi <%2, ideal <%1.
Şubat 2024'ten beri yürürlükte olan ve 2026'da hâlâ geçerli Gmail/Yahoo toplu gönderici gereksinimlerini karşılayın: SPF + DKIM + DMARC hizalı, gönderen IP'de geçerli PTR (forward-confirmed reverse DNS), kullanıcı bildirimli spam oranı <%0,3, ve tek tıkla abonelikten çıkma. Sonuncusu iki header ister:
RFC 8058 gereği List-Unsubscribe-Post header'ı, kullanıcının tek tıkla çıkabilmesini ve isteğin bir POST ile geldiğini garanti eder. Bunu koymayan toplu göndericiler doğrudan spam klasörüne gider.
Uygulama kontrol listesi
Normalize et (lowercase, Gmail nokta/+etiket katla, IDN→punycode) ve dedup et.
Rol adreslerini (RFC 2142 + kendi eklemelerin) ve disposable domain'leri ele; disposable listesini haftalık güncelle.
Tipografik adayları Damerau-Levenshtein ≤2 ile karantinaya al, otomatik silme.
dig +short MX ile doğrula; null MX (0 .) → kesin ret, MX yoksa A fallback.
SMTP RCPT probunu yalnızca ayrı IP + throttle ile, yüksek değerli küçük listelerde kullan; catch-all'ı "riskli" işaretle, 4xx'i geçersiz sayma.
Satın alınmış/kazınmış listeyi asla gönderme.
Sunset policy uygula: >180 gün sessiz → re-engagement, >270 gün → suppress.
