Catch-all email: Tehlikeli mi faydalı mı? Net karar rehberi

Catch-all email (tüm posta) kuralı, bir alan adındaki mevcut olmayan e-posta adreslerine gelen mesajları tek bir hesaba yönlendirir. Bu ayar, kaçırılmayan e-posta hedefleri açısından fayda sağlar; ancak kimlik doğrulama eksikse spam ve kimlik avı (phishing) riskini görünmez biçimde artırabilir. Bu rehberde catch-all’ın ne yaptığını, tehlike oluşturduğu durumları ve güvenli kurulum için uygulanabilir kontrol listesini net şekilde göreceksiniz.

Catch-all email tam olarak ne yapar?

Catch-all, DNS tarafında veya posta sunucusu (mail server) ayarlarında “tanımsız yerel kısma” gelen postaları yakalayıp belirlediğiniz bir adrese teslim eder.

Örnek senaryo: - Alan adınız: ornek.com - Mail sunucusunda yalnızca [email protected] ve [email protected] tanımlı - [email protected] gibi tanımsız bir adrese posta gelirse, catch-all bunu [email protected] veya “maildrop” gibi bir havuza yollar.

Bu sistem, gelen kutusunda şu etkileri doğurur: - Kullanıcı hataları (yazım yanlışları) nedeniyle kaybolan e-postalar toparlanır. - Yanlış gönderimler “teslim edildi” görünebilir; fakat gerçek alıcı tanımlı değilse organizasyon içi hedefleme dağılır. - Spam filtrelemesi ve kimlik doğrulama (SPF/DKIM/DMARC) zayıfsa istenmeyen trafik tek bir adreste birikebilir.

Catch-all ile mail forwarding karıştırmayın

Catch-all, tanımsız adresleri kapsayan bir “yakalama” kuralıdır. Mail forwarding ise belirli bir hesabın gelenini başka hesaba kopyalar. Catch-all, kontrolsüz adres alanını genişletir; bu yüzden güvenlik ve filtreleme birlikte ele alınmalıdır.

Tehlikeli olan catch-all değil: kontrolsüz kurulumdur

Catch-all’ın riskleri çoğunlukla “kimlik doğrulama” ve “filtreleme” katmanları eksik olduğunda ortaya çıkar. Aşağıdaki tablo, catch-all’ı hangi koşullarda daha riskli ya da faydalı yaptığını özetler.

Güvenlik açısından en kritik 5 kontrol

Catch-all’ı kullanacaksanız güvenlik değerlendirmesini şu 5 başlık üzerinden yapın.

1) SPF, DKIM ve DMARC gerçek şekilde düzgün mü?

• SPF: Alan adınız adına gönderim yapan sunucuları belirtir.
• DKIM: Mesajın bütünlüğünü ve imzanın doğruluğunu test eder.
• DMARC: SPF/DKIM başarısızsa ne yapılacağını politikaya bağlar.

Net hedef: DMARC politikanız “quarantine” veya “reject” seviyesine yaklaşmalıdır. Yalnızca “p=none” bırakmak, catch-all açık olduğunda istenmeyen trafiğin havuzda görünür olmasını artırır.

2) Catch-all hedef hesabı “tek bir kutu” olmamalı

En doğru desen, catch-all’ı doğrudan ana ekibin gelen kutusuna dökmemektir.

Önerilen kurulum: - Catch-all teslim adresi: [email protected] gibi ayrı bir hesap - Bu hesapta kurallar: spam skorlama, karantina, etiketleme, gerekirse otomatik arşivleme

Bu sayede: - Operasyon ekipleri ana gelen kutusunu korur. - Catch-all’ın gerçekten çalıştığını doğrulayan ölçümler (kaç mesaj geliyor, kaç tanesi spam) takip edilebilir.

3) RBL / spam skorlama seviyesini catch-all moduna göre ayarlayın

Catch-all açıkken tanımsız adresler de dahil tüm akış tek havuza gidebileceğinden spam oranı artış gösterebilir. Bu artış “spam filter’ın yoğun çalışmasını” gerektirir.

Uygulanabilir kontrol listesi: - RBL (Realtime Blackhole List) gibi kaynaklardan yararlanma - İletiyi belirli eşiğin altında karantina/işaretleme - Karantina süresini ve kurtarma sürecini netleştirme

4) Rate limit ve teslimat logları kullanın

Catch-all havuzuna gelen trafik arttığında saldırganların deneme yapması da kolaylaşır. Bu nedenle şu iki veri olmadan karar vermeyin: - Günlük/saatsel teslimat sayıları - Red/karantina oranları

Mail sunucusunun veya kontrol panelinin sunduğu logları kullanın. Örneğin Plesk/cPanel benzeri panellerde “mail queue”, “spam policy” ve “message headers” ile doğrulama yapılır.

5) “Seçici yakalama” yaklaşımı uygulayın

Catch-all tek düğme gibi kullanılmak zorunda değildir. Bazı sunucularda şu yöntemler uygulanır: - Tanımlı adresler önceliklidir (mevcut hesaplar) - Tanımsız adresler yalnızca belirli koşullarda teslim edilir

Bu yaklaşım, beklenmeyen adreslerin tamamını aynı sertlikle havuza akıtmayı azaltır.

Faydası hangi durumda gerçek değer yaratır?

Catch-all’ın faydalı olduğu net senaryolar vardır.

Senaryo A: Küçük ekip, çok sayıda varyasyon içeren adresler

Bazı işletmelerde aynı kişiye birden fazla varyasyon e-posta ile yazılır: - adsoyad@ - ad.soyad@ - departman@ yerine farklı yazımlar

Özellikle müşteri iletişiminde kullanıcıların yazım hatası yapma ihtimali yüksektir. Catch-all, bu “kaçan” mesajları kurtarır.

Senaryo B: Sık adres değişikliği veya geçiş dönemi

Domain geçişlerinde (ör. old.com → new.com) kullanıcılar eski adrese veya yanlış varyasyonlara yazabilir. Catch-all, geçiş süresi boyunca kayıp yaşanmasını azaltır.

Senaryo C: Catch-all havuzu “aktif yönetiliyor”

Catch-all açıkken belirli bir sorumluluk akışı kurarsanız (etiketleme, haftalık rapor, belirli adreslere otomatik routing) fayda, riski aşar.

Hangi durumda catch-all doğrudan kaçınmanız gereken bir tercihtir?

Catch-all şu durumlarda risk/zarar dengesini olumsuz etkiler.

1) SPF/DKIM/DMARC yok veya bozuk

Bu durumda saldırganlar sahte gönderen taklitleriyle havuzu besleyebilir.

2) Organizasyonda mail filtreleme olgun değil

Spam karantina yönetimi yoksa, catch-all havuzu hızla “işlenemeyen” mesaj ambarına dönüşür.

3) Çok yüksek spam toleransı yok

Özellikle müşteri destek ve satış ekiplerinde gecikme maliyeti yüksekse (SLA) catch-all’ın havuza yığma etkisi üretkenliği düşürür.

Net kullanım rehberi: Güvenli şekilde nasıl karar verilir?

Aşağıdaki adımlarla “tehlikeli mi faydalı mı?” sorusuna sayısal ve operasyonel cevap verin.

Adım 1: 14 gün veri toplayın

Catch-all kapalıyken: - Tanımsız adrese gelen toplam mesaj sayısını ölçün - Bu mesajların spam oranını (veya spam skor dağılımını) inceleyin

Eğer tanımsız adreslerden gelen mesaj hacmi düşükse catch-all’ın faydası sınırlı kalır. Hacim yüksekse (ör. yazım hatası çok) catch-all daha anlamlı olur; ama filtreleme ve politikalar hazır olmalıdır.

Adım 2: Kimlik doğrulamasını tamamlayın

• SPF ekleyin ve kapsamı doğru tutun
• DKIM imzasını aktif edin
• DMARC’ı raporlayın (önce p=none ile rapor), ardından kademeli şekilde quarantine/reject seviyesine ilerleyin

Adım 3: Catch-all’ı ayrı havuza yönetin

• catchall@domain gibi bir hesap
• Otomatik etiketleme + karantina
• Belirli içerik türlerini (ör. ek içeren dosyalar) daha sert filtreleme

Adım 4: Kurtarma akışını tanımlayın

Kullanıcı “bana gelmedi” dediğinde şu soruların cevabı hazır olmalı: - Mesaj catch-all havuzuna düştü mü? - Spam/karantina olarak mı sınıflandı? - Ne kadar sürede inceleniyor?

Adım 5: Operasyon eşiğini belirleyin

Net eşiği yazın: - Örneğin “catch-all havuzunda günlük 500 mesajı aşarsa filtreleme sertleştirilecek” gibi.

Bu eşik belirlenmezse catch-all, performans/iş yükü açısından sürdürülemez hale gelir.

İlgili e-posta ayarlarıyla ilişki: Catch-all tek başına düşünülmez

Catch-all’ın etkisi diğer e-posta kontrolleriyle birlikte değerlendirilmelidir.

Mail forwarding ve catch-all birlikte nasıl etkiler?

• Forwarding, belirli bir hesabın teslimini başka hesaba taşır.
• Catch-all, tanımsız adreslerin teslimini kapsar.

İkisini aynı anda kullanıyorsanız hedef hesapta çift filtre/çift kural oluşabilir. Kural çakışmalarını logla doğrulayın.

Otomatik silme/karantina politikasını netleştirin

Catch-all havuzunda spam/şüpheli içerik otomatik silinirse gerçek mesajlar da kaybolabilir. Bu yüzden karantina süresi ve kurtarma süreci net olmalıdır.

Örnek karar matrisi: Hızlı yönlendirme

Aşağıdaki kısa matrisle “uygula/uygulama” ayrımını hızlandırın.

• SPF + DKIM + DMARC doğru → Catch-all’u ayrı havuza yönlendirerek uygula
• Kimlik doğrulama eksik → önce SPF/DKIM/DMARC düzelt, sonra catch-all aç
• Spam karantina ve loglar yok → catch-all açma; önce filtreleme altyapısını kur
• Adres yazım hatası çok (14 günde tanımsız adres trafiği yüksek) → catch-all faydalı
• Tanımsız adres trafiği düşük → catch-all gereksiz; kapalı tut

Sonuç: Catch-all faydalı olabilir, ama “havuz + doğrulama + filtreleme” şart

Catch-all email doğru ayarlarla kullanıldığında kullanıcı yazım hatalarından kaynaklı kayıpları azaltır ve geçiş dönemlerini yönetmeyi kolaylaştırır. Ancak SPF/DKIM/DMARC zayıfsa ve havuzda karantina/etiketleme/log yönetimi yoksa risk büyür; spam ve kötü niyetli denemeler görünmez bir şekilde tek noktada birikir. Kararınızı netleştirmek için önce 14 gün veri toplayın, ardından kimlik doğrulamasını tamamlayın ve catch-all’ı mutlaka ayrı bir catch-all havuzuna yönlendirip filtreleme eşiğini belirleyin.

Eğer bu adımları şu an yapamıyorsanız, catch-all’ı açmak yerine tanımlı hesaplarınızı netleştirin ve kullanıcıdan gelen hata varyasyonlarını yakalamak için alternatif bir yöntem (destek formu, doğrulama e-postaları, kullanım kılavuzu) uygulayın; böylece riski kontrol altında tutarak gerçekten ihtiyaç olduğunda catch-all’a geçin.