Neden bu konu önemlidir?
Birçok şirket aynı alan adını (ör. @firma.com) kullanarak birden fazla sistemden e-posta gönderir: CRM’den satış otomasyon mailleri, helpdesk’ten ticket bildirimleri, e-ticaret altyapısından sipariş e-postaları, insan kaynakları araçlarından davetler, e-bülten sisteminden kampanyalar gibi. Bu sistemlerin bir kısmı sizin mail sunucunuz üzerinden değil, üçüncü taraf sağlayıcıların gönderim altyapısı üzerinden iletim yapar. Sonuçta alıcı tarafta “Bu alan adına sahip maili gerçekten bu firma mı gönderdi?” sorusuna teknik bir yanıt gerekir.
SPF, DKIM ve DMARC birlikte çalışarak bu yanıtı üretir. Ancak çoklu gönderici kaynakları söz konusu olduğunda yanlış planlama; SPF limitlerine takılma, DKIM imzası gelmemesi, DMARC uyumsuzluğu ve en önemlisi teslim edilebilirlik sorunlarıyla sonuçlanabilir. Bu rehber, bir alan adından birden fazla SaaS/uygulama ile güvenli ve tutarlı e-posta gönderimi için pratik bir çerçeve sunar.
Önce resmi çıkarın: Kim, ne gönderiyor?
Teknik ayara başlamadan önce en kritik adım envanterdir. Aşağıdaki sorulara net yanıt vermek sonraki tüm kararları kolaylaştırır:
- Hangi sistemler şirket adına e-posta gönderiyor? (CRM, helpdesk, e-bülten, e-ticaret, uygulama sunucuları, fatura sistemi vb.)
- Bu sistemler hangi adresten gönderiyor? (From: satış@, destek@, noreply@ gibi)
- Gerçekte hangi alan adını kullanıyor? (ana domain mi, alt domain mi?)
- Gönderim hangi altyapıdan çıkıyor? (Sizin SMTP’niz mi, sağlayıcının MTA’ları mı?)
- Her sistem için DKIM imzası var mı ve hangi domain/selector ile imzalanıyor?
Birçok organizasyonda gölge IT yüzünden bazı araçlar yıllar önce eklenmiş ve kimlik doğrulama hiç düşünülmemiş olabilir. DMARC raporları burada ayrıca yardımcı olabilir; ancak envanter çalışması yine de şarttır.
SPF: Kimler bu domain adına mail gönderebilir?
SPF, gönderen sunucunun IP’sinin (veya SPF kaydında belirtilen mekanizmaların) alan adı tarafından yetkilendirilip yetkilendirilmediğini kontrol eder. Çoklu SaaS kullanımı SPF’i iki açıdan zorlar: “include” zincirlerinin büyümesi ve 10 DNS lookup limitine yaklaşılması.
SPF’te yapılacaklar
- Tek bir SPF kaydı yayınlayın. Aynı domain altında birden fazla SPF TXT kaydı hata üretir.
- Her üçüncü taraf için onların önerdiği include/ipv4/ipv6 kayıtlarını mevcut SPF’e ekleyin.
- Politikayı gerçekçi belirleyin: -all (fail), ~all (softfail) veya ?all (neutral). Tam reddetme kararı DMARC stratejinizle birlikte değerlendirilmelidir.
- SPF kaydını büyütürken DNS lookup sayısını kontrol edin; include sayısı arttıkça limit problemi oluşabilir.
SPF’te sık yapılan hatalar
- Birden fazla SPF TXT kaydı yayınlamak: “v=spf1 …” içeren ikinci bir TXT eklemek sorunu çözmez, daha da büyütür.
- Yanlış alan adına SPF yazmak: Bazı araçlar, göndereni farklı bir return-path (envelope-from) alan adıyla ayarlayabilir. SPF kontrolü çoğunlukla envelope-from üzerinde çalışır.
- ‘Her şeyi ekleyelim’ yaklaşımı: Kullanılmayan sağlayıcıları SPF içinde tutmak gereksiz risk ve limit tüketimidir.
DKIM: İçerik imzası ve marka tutarlılığı
DKIM, e-postanın belirli başlıklarını ve gövdesini kriptografik olarak imzalayarak iletim sırasında değiştirilmediğini ve imzanın ilgili domain adına doğrulanabildiğini gösterir. Çoklu sistemlerde DKIM’in değeri artar; çünkü SPF bazı senaryolarda (özellikle yönlendirmeler ve bazı geçişler) zayıflayabilirken, DKIM imzası korunabilir.
Çoklu SaaS ortamında DKIM planı
- Her sağlayıcı için ayrı DKIM selector kullanın. Örneğin: crm1, helpdesk1, newsletter1 gibi. Bu hem yönetimi kolaylaştırır hem de sorun gidermede hız kazandırır.
- Mümkünse aynı “From:” domaini ile uyumlu DKIM imzası kullanın. DMARC açısından önemli olan “alignment” yani uyumdur.
- DKIM DNS kayıtlarını yayınladıktan sonra sağlayıcının panelinde doğrulama adımını tamamlayın; sadece DNS’e eklemek yetmez.
- Anahtar ömrü/rotasyon planı yapın. Zamanla sağlayıcı değişebilir veya anahtar rotasyonu gerekebilir.
DKIM’de tipik sorunlar
- Yanlış TXT değeri: Kopyalama sırasında tırnak, boşluk veya satır bölünmesi hataları.
- Yanlış kayıt türü veya isim: Selector._domainkey.domain.tld yapısının bozulması.
- Sağlayıcının farklı domain ile imzalaması: Bazı sistemler kendi domainleriyle DKIM imzalar; bu durumda DMARC uyumu bozulabilir.
DMARC: Politika, görünürlük ve tutarlı uygulama
DMARC, alıcı tarafa iki şeyi söyler: “Bu domain için SPF/DKIM sonuçlarını hangi uyum kurallarıyla değerlendireceksin?” ve “Başarısız olursa ne yapacaksın?”. Ayrıca raporlama mekanizmalarıyla görünürlük sağlar.
DMARC’in çoklu gönderici kaynaklarındaki rolü
- Hangi sistemlerin doğru yetkilendirildiğini görmenizi sağlar.
- Hatalı yapılandırılmış SaaS araçlarını erken yakalatır.
- Sahte gönderimleri azaltmaya yardımcı olur; özellikle politika seviyeniz sıkılaştıkça.
Pratik DMARC yaklaşımı
- Başlangıçta görünürlük: p=none ile başlayıp rapor toplayın.
- Kaynakları sınıflandırın: Meşru kaynaklar, yanlış yapılandırılmış meşru kaynaklar ve yetkisiz kaynaklar.
- Uyumu düzeltin: Öncelik, kritik iş e-postaları (fatura, şifre sıfırlama, sipariş) olmalıdır.
- Kademeli sıkılaştırma: quarantine ve daha sonra reject seviyesine geçişi kontrollü yapın.
Alt domain stratejisi: Riskleri ve itibarı ayırın
Çoklu gönderim yapan şirketler için en temiz yöntemlerden biri iş yüklerini alt domainlere bölmektir. Örneğin:
- news.firma.com: e-bülten ve pazarlama
- notify.firma.com: uygulama bildirimleri
- support.firma.com: helpdesk
Bu yaklaşımın faydası; SPF/DKIM/DMARC ayarlarının daha sade hale gelmesi, itibarın ayrışması ve bir kanalın sorun yaşaması durumunda diğer kanalların daha az etkilenmesidir. Ancak marka algısı ve “From:” adreslerinin kullanıcı beklentisi de gözetilmelidir.
Değişiklik yönetimi: DNS, TTL ve test
Kimlik doğrulama ayarları genellikle DNS üzerinde yürür; bu da değişikliklerin yayılma süresi ve geri dönüş planı gerektirdiği anlamına gelir.
- Değişiklikten önce TTL değerlerini gözden geçirin; kritik değişikliklerde geçici olarak düşürmek işleri kolaylaştırabilir.
- Her sağlayıcı eklemesinden sonra küçük kapsamlı test gönderimleri yapın ve sonuçları kontrol edin.
- SPF/DKIM/DMARC değişikliklerini tek seferde değil, kontrollü adımlarla uygulayın.
- Kaydı “temiz” tutun: kullanılmayan include’ları kaldırın, hangi satırın hangi sisteme ait olduğunu iç dokümantasyonda belirtin.
Operasyonel kontrol listesi
- Gönderici envanteri çıkarıldı ve sahiplik belirlendi (hangi ekip/kim sorumlu?).
- Tek SPF kaydı var ve gereksiz include yok.
- Her sistemin DKIM’i etkin ve doğru domain ile uyumlu.
- DMARC raporları takip ediliyor ve aksiyon planı var.
- Yeni bir SaaS eklendiğinde standart prosedür: önce alt domain kararı, sonra SPF/DKIM, sonra DMARC uyumu.
- İşten ayrılan çalışanlar veya kapanan araçlar sonrasında DNS temizliği yapılıyor.
Sonuç: Çoklu göndericiyle düzenli ve güvenli e-posta mümkün
Modern şirketler tek bir mail sunucusuyla yetinmiyor; e-postanın üretildiği yerler çoğalıyor. Bu da kimlik doğrulama tasarımını bir “tek seferlik kayıt” işinden çıkarıp yaşayan bir yönetişim sürecine dönüştürüyor. SPF’in sınırlarını ve bakım ihtiyacını kabul edip DKIM’i sağlam kurmak, DMARC ile görünürlük ve politika disiplini sağlamak uzun vadede teslim edilebilirliği korumanın en pratik yoludur.
Alan adınızın DNS’ini ve kurumsal posta akışını yönetirken, posta kutuları ve domain ayarlarını merkezi bir şekilde yönetebileceğiniz bir yapı operasyonel yükü azaltır. MX1Mail kullanan ekipler, bu tür kimlik doğrulama değişikliklerini planlarken posta altyapısı yönetimini daha düzenli bir süreç haline getirebilir.