Transaksiyonel ve Pazarlama Trafiğini Ayrı Alt Alan Adlarına Bölmek: İtibarı ve Teslimatı Yalıtma
Tek bir pazarlama kampanyasındaki yüzde 0.3'lük şikayet oranı, aynı organizasyonel alandan çıkan OTP ve şifre sıfırlama e-postalarını da spam'e gömer. İtibar IP'ye değil alan adına yapışır. Trafiği t.evilmail.pro ve news.evilmail.pro olarak ayırmayı DNS, Postfix ve OpenDKIM seviyesinde gerçek konfigürasyonla anlatıyoruz.
EvilMail Team17 Temmuz 202613 dk okuma
Gece 02:14. Pazarlama ekibi, aylardır dokunulmamış 80 binlik bir listeye "yaz indirimi" kampanyası attı. Sabah 09:00'da destek kanalı yanıyor: kullanıcılar şifre sıfırlama bağlantısını alamıyor, OTP kodları gelmiyor. Postmaster Tools'u açıyorsun; transactional akışın haftalardır yeşil olan itibar grafiği bir gecede kırmızıya dönmüş. Kimse şifre sıfırlama sunucusuna dokunmadı — dokunmasına gerek yoktu. İki akış da evilmail.pro üzerinden d=evilmail.pro ile imzalanıyordu ve Gmail itibarı IP'de değil, o d= alanında biriktiriyor.
Bu bir kapasite problemi değil, bir patlama yarıçapı (blast radius) problemi. Çözüm de trafiği IP'lere değil, ayrı alt alan adlarına bölmek: transactional akış t.evilmail.pro, pazarlama news.evilmail.pro üzerinden gider; kök evilmail.pro ise sıfır e-posta gönderecek şekilde temiz tutulur. Aşağıda bunu DNS, Postfix ve OpenDKIM seviyesinde nasıl kurduğumuzu gösteriyorum.
İtibar neden alan adına yapışır
Gmail Postmaster Tools'taki "Domain reputation" grafiğinin bağlı olduğu şey gönderdiğin IP değil, DKIM imzasındaki
Transaksiyonel ve Pazarlama E-postasını Alt Alan Adıyla Ayırma | EvilMail — EvilMail Blog
d=
alanı ve onun organizasyonel alanıdır (eTLD+1, yani Public Suffix List'e göre
evilmail.pro
). SPF ve DKIM'in
From
başlığıyla hizalanması (DMARC alignment) sağlandıktan sonra alıcı sağlayıcı, o mesajın davranış puanını organizasyonel alana yazar. IP itibarı hâlâ önemlidir ama ikincildir; alan itibarı IP değişse bile seninle taşınır. Sıfırdan bir /24 blok kiralasan bile, aynı
d=
ile imzaladığın sürece geçmişini sırtında taşırsın.
Alt alan itibarı başlangıçta kök alandan bir miktar miras alır, ama zamanla kendi davranış geçmişini biriktirerek kök alandan ayrışır. Bütün strateji bu ayrışmanın üzerine kurulur.
İki akışın doğası taban tabana zıt:
Transactional (OTP, şifre sıfırlama, fatura, sipariş onayı): düşük hacim, çok yüksek açılma/etkileşim oranı, kullanıcının aktif olarak beklediği, kritik. Şikayet oranı doğal olarak dipte.
Pazarlama (bülten, kampanya, duyuru): yüksek hacim, dalgalı, eski listelerde spam-trap ve bozuk adres riski yüksek, "işaretle spam" oranı yapısal olarak daha yüksek.
Bu ikisini aynı d= altında topladığında, pazarlamanın kaçınılmaz şikayet gürültüsü doğrudan transactional akışının teslimatını kirletir. Pazarlamada yüzde 0.3 şikayet oranı normaldir; ama o oran organizasyonel alana yazıldığında, aynı alandan çıkan OTP'ni de Gmail'in gözünde şüpheli yapar.
Alan adı mimarisi: kökü boş bırak
Adlandırma planı basit ve kasıtlı:
`t.evilmail.pro` — transactional. OTP, şifre sıfırlama, fatura, sistem bildirimleri. Hedef itibar: her zaman High.
`news.evilmail.pro` — pazarlama, bülten, kampanya. Dalgalanmasına izin verilen akış.
`evilmail.pro` (kök) — HİÇ e-posta göndermez. Yalnızca web sitesi ve kurumsal MX (insanların birbirine yazdığı gerçek posta kutuları).
Kökü neden temiz tutuyoruz? İki neden. Birincisi, kök alan phishing saldırganlarının en çok taklit etmeye çalıştığı isimdir; kökten hiç transactional göndermezsen, p=reject politikasını meşru bir trafiği kırma korkusu olmadan uygulayabilirsin. İkincisi, kök itibarı bir kez bozulursa toparlaması en zor olandır, çünkü organizasyonel alanın tamamına dokunur. Kökü "asla ateşlenmeyen sigorta" olarak sakla.
Ayrı gönderim IP'leri opsiyoneldir ama hacim büyüdükçe değerlidir: transactional için dedike bir IP (203.0.113.10), pazarlama için ayrı bir havuz (212.22.69.211). IP ayrımı alan ayrımının yerini tutmaz — asıl yalıtımı d= sağlar — ama ikisini birleştirmek en temiz sonucu verir.
DNS: her alt alan kendi SPF/DKIM/DMARC'ını taşır
Her alt alan bağımsız bir kimliktir. Kendi SPF kaydı, kendi DKIM seçicisi ve gerektiğinde kendi DMARC kaydı olur. Kritik nokta: Return-Path (envelope MAIL FROM) alt alanla hizalanmalı, çünkü SPF envelope'a bakar, DKIM d='ye bakar, DMARC ise bu ikisinden en az birinin From başlığıyla hizalanmasını ister.
dns
; --- transactional: t.evilmail.pro ---
t.evilmail.pro. IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.evilmail.pro -all"
s1._domainkey.t.evilmail.pro. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQ...IDAQAB"
_dmarc.t.evilmail.pro. IN TXT "v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:[email protected]; fo=1"
; --- pazarlama: news.evilmail.pro ---
news.evilmail.pro. IN TXT "v=spf1 ip4:212.22.69.211 -all"
s1._domainkey.news.evilmail.pro. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQ...IDAQAB"
_dmarc.news.evilmail.pro. IN TXT "v=DMARC1; p=quarantine; pct=25; adkim=s; aspf=s; rua=mailto:[email protected]"
; --- kök: gönderime kapalı ---
evilmail.pro. IN TXT "v=spf1 -all"
_dmarc.evilmail.pro. IN TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:[email protected]; fo=1"
; --- taşıma güvenliği (her alt alan için ayrı) ---
_mta-sts.t.evilmail.pro. IN TXT "v=STSv1; id=20260704T120000Z"
_smtp._tls.t.evilmail.pro. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"
DKIM anahtarları 2048-bit RSA olmalı; 1024-bit artık zayıf kabul ediliyor ve bazı sağlayıcılar puanlarken bunu dikkate alıyor. Her alt alan kendi seçicisini (s1) taşır; seçici adı çakışabilir çünkü FQDN farklı (s1._domainkey.t... ile s1._domainkey.news... iki ayrı kayıttır).
Postfix + OpenDKIM: iki akışı ayrı imzala
İşin kalbi, OpenDKIM'in her alt alanı kendi özel anahtarıyla imzalaması. Önce anahtarları üret:
s1.txt içindeki p= değerini yukarıdaki DNS kayıtlarına yapıştır. Sonra SigningTable ve KeyTable ile hangi gönderenin hangi anahtarla imzalanacağını bağla:
/etc/opendkim.conf içinde SigningTable refile:/etc/opendkim/SigningTable ve KeyTable refile:/etc/opendkim/KeyTable satırlarının açık olduğundan emin ol. OpenDKIM, imzalanacak d='yi mesajın From başlığındaki alandan seçer — dolayısıyla uygulaman kampanyaları [email protected], OTP'leri [email protected] ile göndermelidir. İmza otomatik olarak doğru anahtara düşer.
Postfix tarafında iki yaklaşım var. En temizi: uygulamanın her akış için farklı bir From ve Return-Path (envelope sender) ile bağlanması. Envelope sender'ı mutlaka alt alanla eşleştir, yoksa SPF hizalaması kırılır:
Ayrı çıkış IP'leri kullanacaksan Postfix'te sender_dependent_default_transport_maps ile envelope-from'a göre farklı bir smtp transport'una (dolayısıyla farklı smtp_bind_address'e) yönlendirebilirsin. Ama pratikte çoğu ekip için uygulama seviyesinde iki ayrı SMTP bağlantısı yönetmek daha az kırılgandır.
Gönderdikten sonra doğrula: Gmail'de mesajı aç, "Show original" de; SPF: PASS, DKIM: PASS, DMARC: PASS gördüğünden ve en önemlisi DKIM signed by: t.evilmail.pro (kök değil, alt alan) yazdığından emin ol.
adkim=s ve aspf=s katı (strict) hizalama demektir: alt alanın kendisi tam olarak eşleşmeli, gevşek modda olduğu gibi organizasyonel alana geri düşülmez. Transactional akış için bunu istiyorsun — sıkı olması, taklit girişimlerinin From başlığında kök alanı kullanıp SPF'i başka bir alt alanla geçmesini engeller.
Kritik ve sık atlanan kural: kök _dmarc kaydındaki `sp=` yalnızca kendi `_dmarc` kaydı OLMAYAN alt alanlara uygulanır. news.evilmail.pro için ayrı bir _dmarc.news.evilmail.pro kaydı yayınladığın anda, o kayıt kökün sp='sini ezer. Bu tam da istediğimiz esnekliktir: kök sp=reject'te kalırken, pazarlamayı kendi kaydında p=quarantine; pct=25 ile yumuşak başlatırsın.
Kademeli rollout stratejisi akışa göre farklı hızda:
Transactional:p=none (bir hafta rua topla) → hizalamayı doğrula → doğrudan p=reject. Hacim düşük ve kontrollü olduğu için hızlı ilerle.
Pazarlama:p=none → p=quarantine; pct=25 → pct=100 → gerekirse p=reject. Üçüncü taraf ESP'ler devredeyse, hizalamayı bozan uçları rua raporlarında görene kadar acele etme.
rua raporlarını (Google, Microsoft, Yahoo günlük gönderir) haftalık incele. fo=1 ile SPF veya DKIM'den herhangi biri hizalanmadığında failure raporu istersin — bozuk bir gönderim ucunu bulmanın en hızlı yolu budur.
Isınma ve izleme
Yeni bir alt alan sıfır itibarla başlar. Her alt alanı (ve varsa her IP'yi) ayrı ısıt. Kabaca reçete: ilk gün ~50 mesaj, sonrasında günlük hacmi kabaca iki katına çıkararak 4-8 haftada tam hacme ulaş. İlk mesajları en çok etkileşen kullanıcılara gönder — açılma ve tıklama, itibarı hızla yukarı çeker.
İzleme olmadan bunların hiçbiri işe yaramaz:
Her alt alanı Gmail Postmaster Tools'a ayrı kaydet (DNS TXT ile doğrulama). Microsoft tarafında IP'lerini SNDS'ye ekle.
Postmaster'daki spam oranını transactional için yüzde 0.10 altında tut. Yüzde 0.30 kırmızı çizgidir — Gmail'in kendi belgelenmiş eşiği; geçtiğinde teslimat düşmeye başlar.
Domain reputation kategorileri High / Medium / Low / Bad. Transactional'ın Medium'a düşmesi bile alarmdır; nedenini bulana kadar hacmi artırma.
2024'ten beri yürürlükte olan Gmail/Yahoo toplu gönderici kuralları (Gmail'e günde 5000+ mesaj atanlar için) alt alan ayrımını zaten pratik bir zorunluluk hâline getiriyor: SPF + DKIM + DMARC şart, DMARC en az p=none olmalı — ama hizalama olmadan bir işe yaramaz — ve pazarlama e-postalarında List-Unsubscribe ile tek tıkla abonelikten çıkış (RFC 8058, List-Unsubscribe-Post: List-Unsubscribe=One-Click) zorunlu. Bu başlığı yalnızca pazarlamaya ekle — OTP'ye "abonelikten çık" koymak anlamsız ve yanlıştır.
MTA-STS ve TLS-RPT'yi her alt alan için ayrı yayınla. MTA-STS yalnızca TXT kaydından ibaret değildir: her alt alan için https://mta-sts.t.evilmail.pro/.well-known/mta-sts.txt yolunda HTTPS ile sunulan bir politika dosyası (mode: enforce, mx: satırları, max_age) da gerekir; TXT kaydındaki id, politika dosyası her değiştiğinde güncellenmeli. Taşıma şifrelemesi düşürme (downgrade) saldırılarına karşı sigortadır; TLS-RPT ise kimlerin STARTTLS'i kaçırdığını sana raporlar. BIMI'yi ise yalnızca marka görünürlüğü istediğin alanda (genelde pazarlama veya kök) düşün; transactional için önceliğin değil.
Kurulum kontrol listesi
1. Kökten (evilmail.pro) tüm uygulama gönderimini kes; SPF'i v=spf1 -all yap, _dmarcp=reject; sp=reject.
2.t. ve news. alt alanlarını oluştur; her birine ayrı SPF, DKIM (2048-bit) ve DMARC kaydı ver.
3. OpenDKIM'de her alt alan için ayrı seçici + KeyTable/SigningTable girişi; özel anahtarlar opendkim:opendkim, chmod 600.
4. Return-Path / envelope MAIL FROM'u ilgili alt alanla hizala (bounce@t..., bounce@news...).
5. Her alt alanı (ve IP'yi) ayrı ısıt: gün 1 ~50, günlük ~2x, 4-8 hafta.
6. Her alt alanı Postmaster Tools'a, IP'leri SNDS'ye ayrı kaydet.
