DMARC raporlarınızı incelediniz ve alan adınız adına gönderim yapan, haberiniz olmayan servisler buldunuz. Pazarlama ekibi bir platform kurmuş, İK başka bir araç kullanıyor, bir departman kendi çözümünü bulmuş.
Bu dağınıklık, teslimat sorunlarının ve güvenlik risklerinin kaynağıdır. Bu yazı, e-posta gönderiminde kurumsal düzeni ele alıyor.
Dağınıklık Nasıl Oluşur?
Kimse kötü niyetli değildir; her ekip kendi ihtiyacını çözer:
- Pazarlama bir platform kurar. Kampanya göndermek için.
- İK bir işe alım aracı kullanır. Adaylara yazışma yapar.
- Muhasebe bir fatura yazılımı kurar. Otomatik fatura gönderir.
- Bir geliştirici test için servis ekler. Sonra kalıcı hâle gelir.
- Destek ekibi bir bilet sistemi kurar.
Her biri tek başına makuldür. Sorun toplamdadır: alan adınız adına, farklı yerlerden, farklı kalitede gönderim yapılmaktadır ve kimse toplamı görmez.
Ortaya Çıkan Sorunlar
| Sorun | Etkisi |
|---|---|
| SPF kaydı şişer | Sorgu limiti aşılır, tüm gönderim etkilenir |
| İtibar paylaşılır | Bir ekibin hatası hepsini etkiler |
| İzin yönetimi bölünür | Çıkan kullanıcı başka sistemden ileti alır |
| Görünürlük kaybolur | Toplam gönderim hacmi bilinmez |
| Güvenlik riski artar | Denetlenmeyen sistemler |
| Maliyet kontrolü kalkar | Birden fazla abonelik |
Üçüncü satır en somut ve en çok şikâyet üreten sorundur: bir sistemden abonelikten çıkan kullanıcı, diğerinden ileti almaya devam eder. Kullanıcı açısından bu, isteğinin dikkate alınmaması demektir ve doğrudan spam şikâyetine dönüşür.
İkinci satır ise teknik bir gerçektir: aynı alan adından gönderim yapan tüm sistemler, aynı itibar havuzunu paylaşır.
İlk Adım: Envanter
Düzen kurmadan önce mevcut durumu görmek gerekir. Kaynaklar:
- DMARC raporları. Alan adınız adına gönderim yapan tüm kaynakları gösterir.
- SPF kaydınız. Yetkilendirdiğiniz servisler.
- Fatura kayıtları. Hangi e-posta servislerine ödeme yapılıyor?
- Ekiplere sormak. Hangi araçları kullanıyorlar?
Birinci madde en kapsamlı görüntüyü verir ve genellikle sürpriz içerir: raporlarda, kimsenin hatırlamadığı eski sistemler görünür — yıllar önce kurulmuş ve unutulmuş araçlar hâlâ gönderim yapıyor olabilir.
Üçüncü madde de etkili bir yöntemdir: e-posta servisi aboneliklerinin faturaları, envanterinizi tamamlar.
Politikanın Bileşenleri
Yazılı bir politika şunları tanımlamalıdır:
Kim Gönderebilir?
Hangi ekipler, hangi tür iletileri gönderme yetkisine sahip? Yeni bir gönderim ihtiyacı doğduğunda kime başvurulacak?
Hangi Altyapıdan?
Onaylı gönderim kanalları nelerdir? Yeni bir servis eklemek için onay süreci nedir?
Temel kural: alan adınız adına gönderim yapacak her servis, kayıt altına alınmalıdır.
Hangi Adresten?
Hangi akış hangi gönderen adresini kullanacak? Alt alan adı ayrımı var mı?
İzin Nasıl Yönetilecek?
Bastırma listesi merkezi mi? Bir sistemden çıkan kullanıcı diğerlerinden de çıkarılıyor mu?
Kim Sorumlu?
Teslimat performansını kim izliyor? Sorun çıktığında kime haber veriliyor?
Son madde çoğu kurumda tanımsızdır: e-posta teslimatı kimsenin görev tanımında olmadığı için, sorunlar ancak müşteri şikâyetiyle fark edilir.
Merkezi Gönderim Yapısı
Dağınıklığı çözmenin en etkili yolu, tüm gönderimleri tek bir noktadan geçirmektir:
- SPF kaydı sadeleşir. Tek bir kaynak tanımlanır.
- İzin yönetimi merkezileşir. Bastırma listesi tek yerde.
- Metrikler birleşir. Toplam performans görünür.
- Politikalar tek yerde uygulanır. Hız sınırı, filtreleme, imzalama.
- Maliyet kontrolü kolaylaşır. Tek abonelik.
Bu yapıda farklı uygulamalar ve ekipler kendi araçlarını kullanmaya devam eder, ancak gönderim tek bir altyapı üzerinden yapılır.
İkinci madde en değerli kazançtır: merkezi bastırma listesi, "bir sistemden çıktım ama diğerinden ileti geliyor" sorununu yapısal olarak çözer.
Akış Ayrımı
Merkezileştirme, her şeyin aynı kimlikten gitmesi anlamına gelmez. Doğru ayrım:
| Akış | Önerilen ayrım |
|---|---|
| Kurumsal yazışma | Ana alan adı |
| İşlemsel iletiler | Ayrı alt alan adı |
| Pazarlama | Ayrı alt alan adı |
| Sistem bildirimleri | Ayrı alt alan adı |
Bu ayrımın amacı itibar korumasıdır: pazarlama gönderimlerindeki bir sorun, şifre sıfırlama iletilerinizi ve kurumsal yazışmanızı etkilemez.
Ancak aşırıya kaçmayın: çok sayıda alt alan adı, her birinin yeterli itibar biriktirememesine yol açar.
Yeni Servis Onay Süreci
Politikanın işler olması için, yeni bir gönderim kaynağı eklenirken izlenecek bir süreç gerekir:
- İhtiyaç doğrulanır. Mevcut altyapıyla karşılanabilir mi?
- Gönderim hacmi tahmin edilir. İtibar etkisi değerlendirilir.
- Kimlik doğrulama planlanır. SPF ve DKIM nasıl kurulacak?
- İzin yönetimi tanımlanır. Bastırma listesi nasıl senkronize olacak?
- Envantere kaydedilir.
- Sorumlu atanır.
Birinci madde çoğu talebi çözer: yeni bir servise gerçekten ihtiyaç var mı, yoksa mevcut altyapı bu işi zaten yapabilir mi?
Dördüncü madde ise pazarlıksızdır: izin yönetimi entegre edilemeyen bir servis, şikâyet üretmeye mahkûmdur.
Gölge Sistemleri Önlemek
Politika çok katı olursa ekipler onu atlar ve daha da kontrolsüz çözümler üretir. Dengeyi kurmak için:
- Süreci hızlı tutun. Onay haftalar sürerse kimse beklemez.
- Alternatif sunun. "Hayır" demek yerine "şunu kullan" deyin.
- Gerekçeyi açıklayın. Kuralın nedeni anlaşılırsa uyum artar.
- Kolaylaştırın. Merkezi altyapı kullanmak, kendi çözümünü kurmaktan kolay olsun.
Dördüncü madde en etkili yaklaşımdır: kurallar değil kolaylık uyum üretir. Merkezi altyapıya bağlanmak birkaç dakika sürüyorsa, kimse ayrı bir servis kurmaz.
Sürekli İzleme
Politika bir kez kurulup unutulmaz. Düzenli kontroller:
- DMARC raporlarını inceleyin. Yeni bir kaynak belirdi mi?
- SPF kaydını gözden geçirin. Kullanılmayan servis var mı?
- Gönderim hacmini takip edin. Beklenmedik artış var mı?
- Şikâyet oranlarını akış bazında izleyin. Hangi akış sorun üretiyor?
- Envanteri güncel tutun.
Birinci madde bir erken uyarı sistemidir: raporlarda daha önce görülmeyen bir gönderim kaynağı belirmesi, ya yeni bir gölge sistem ya da bir taklit girişimidir — ikisi de araştırılmalıdır.
Ekip Farkındalığı
Politikanın işlemesi, ekiplerin gerekçeyi anlamasına bağlıdır. Paylaşılması gerekenler:
- Neden merkezi gönderim gerekli?
- Bir ekibin hatası neden herkesi etkiliyor?
- Yeni bir servis ihtiyacında kime başvurulacak?
- Bir teslimat sorunu fark edilirse ne yapılacak?
İkinci madde en ikna edici argümandır: pazarlama ekibinin satın aldığı bir listeye gönderim yapması, tüm şirketin e-postalarının spam'e düşmesine yol açabilir.
Bu bağlantı anlaşıldığında, politikaya uyum kendiliğinden artar.
Nereden Başlamalı?
Mevcut dağınıklığı toplamak kademeli bir iştir:
- Envanter çıkarın — DMARC raporlarıyla
- Kullanılmayanları kapatın — en kolay kazanç
- Kritik akışları merkezileştirin — işlemsel iletilerden başlayın
- İzin yönetimini birleştirin
- Politikayı yazılı hâle getirin
- Yeni talepler için süreç kurun
İkinci madde hızlı ve görünür bir kazanç sağlar: envanterde çıkan kullanılmayan servisleri kapatmak, SPF kaydınızı rahatlatır ve güvenlik riskini azaltır.
Üçüncü madde ise doğru öncelik sırasıdır: işlemsel iletiler en kritik akıştır ve önce onların güvence altına alınması gerekir.
Merkezi bir gönderim altyapısı kurmak, bu düzenin teknik zeminini oluşturur — farklı uygulamalar tek bir noktadan gönderim yapar, politikalar orada uygulanır ve tüm metrikler tek yerde toplanır.
Sonuç
E-posta gönderim dağınıklığı kötü niyetten değil, her ekibin kendi ihtiyacını çözmesinden doğar — ama sonucu ortaktır: bir ekibin hatası, tüm şirketin e-posta teslimatını etkiler. İlk adım envanterdir ve en iyi kaynak DMARC raporlarıdır; genellikle kimsenin hatırlamadığı eski sistemler ortaya çıkar. Politikayı kurarken en kritik madde izin yönetimidir: merkezi bir bastırma listesi olmadan, bir sistemden çıkan kullanıcı diğerinden ileti almaya devam eder. Ve unutmayın — kurallar değil kolaylık uyum üretir.
Sıkça Sorulan Sorular (SSS)
Kimlerin gönderim yaptığını nasıl öğrenirim?
En kapsamlı kaynak DMARC raporlarıdır — alan adınız adına gönderim yapan tüm kaynakları gösterir ve genellikle sürpriz içerir. Bunu SPF kaydınız, e-posta servisi faturaları ve ekiplere sorarak tamamlayın.
Dağınık gönderim neden sorun?
Aynı alan adından gönderim yapan tüm sistemler aynı itibar havuzunu paylaşır — bir ekibin hatası hepsini etkiler. Ayrıca SPF kaydı şişer ve sorgu limiti aşılabilir; en somut sorun ise izin yönetiminin bölünmesidir.
İzin yönetimi neden merkezi olmalı?
Aksi hâlde bir sistemden abonelikten çıkan kullanıcı, diğerinden ileti almaya devam eder. Kullanıcı açısından bu, isteğinin dikkate alınmaması demektir ve doğrudan spam şikâyetine dönüşür — en hızlı itibar zedeleyen senaryolardan biridir.
Ekipler politikaya nasıl uyar?
Kurallarla değil kolaylıkla. Merkezi altyapıya bağlanmak kendi çözümünü kurmaktan kolay olursa kimse ayrı servis aramaz. Ayrıca gerekçeyi paylaşın: bir ekibin satın alınmış listeye gönderim yapmasının tüm şirketi etkileyeceği anlaşıldığında uyum kendiliğinden artar.
