Şirket alan adından e-posta gönderen sistemler yalnızca çalışanların posta kutularından oluşmayabilir. Pazarlama aracı, destek sistemi, ERP ve web formu da aynı alan adını kullanabilir. E-posta kimlik doğrulaması tasarlanırken bu kaynaklardan biri unutulursa meşru mesajlar sorun yaşayabilir. SPF, DKIM ve DMARC çalışmasını bu nedenle önce gönderim envanteriyle başlatmak gerekir.
Bu yazı Microsoft 365 kullanan bir kurumun değerlendirme akışını ele alır. DNS'e doğrudan uygulanacak evrensel bir kayıt seti sunmaz. Her kurumun göndericileri ve tenant bilgileri farklıdır. Mevcut DNS kayıtlarını değiştirmeden önce gönderim kaynaklarını, alan adı sahipliğini ve geri dönüş adımlarını belirleyin. Uygun olmayan bir politika iş yazışmalarını etkileyebilir.
Üç mekanizmanın görevini ayırın
SPF, alan adı adına gönderim yapabilecek kaynakların değerlendirilmesine yardımcı olur. DKIM, mesajın belirli alan adıyla ilişkili kriptografik imzasını sunar. DMARC ise ilgili kimlik doğrulama sonuçlarının görünen gönderici alanıyla hizalanmasını ve politika davranışını ele alır. Birinin varlığını diğer ikisinin de doğru çalıştığına dair kanıt saymayın.
Microsoft DMARC yapılandırma dokümanı, SPF ve DKIM hazırlığı sonrasında kademeli politika yaklaşımını açıklar. DMARC başarısı, alan adına benzeyen bütün sahte alanları veya bütün kimlik avı senaryolarını engelleme garantisi değildir. Kullanıcı farkındalığı ve diğer güvenlik kontrolleri de ayrı önem taşır.
1. Gönderici envanterini tamamlayın
Hangi sistem, hangi alan veya alt alan adıyla mesaj gönderiyor? Görünen From adresiyle teknik gönderim alanlarının ilişkisini belirleyin. Dış hizmet sağlayıcılarının kullandığı modeller değişebilir. Sadece DNS panelindeki mevcut kayıtları görmek, bütün meşru göndericileri bulduğunuz anlamına gelmez.
Finans, satış, pazarlama ve uygulama ekipleriyle görüşün. Ayda bir çalışan belge gönderimi veya dönemsel kampanya, kısa bir gözlemde görünmeyebilir. Her kaynağın iş sahibi, tedarikçisi ve test mesajı bulunsun. Kullanılmayan göndericileri de belirleyin; geçmişte eklenmiş bir kaydın hâlâ gerekli olduğunu varsaymayın.
2. SPF kaydını bir bütün olarak değerlendirin
Microsoft 365'in tek gönderici olduğu bir alan için aşağıdaki değer bir örnek olabilir. Kurumda başka göndericiler varsa bu satırı mevcut kaydın üzerine doğrudan yazmayın. Aynı isimde birden fazla SPF kaydı oluşturmak da doğru bir birleştirme yöntemi değildir.
v=spf1 include:spf.protection.outlook.com -allYetkili kaynaklar, DNS sorgu sınırları ve dış sağlayıcının önerdiği yöntem birlikte değerlendirilir. Sadece kaydı daha uzun hâle getirerek bütün hizmetleri eklemek sürdürülebilir olmayabilir. Gönderim için ayrı alt alanlar kullanmak bazı iş yüklerinde yönetimi kolaylaştırabilir; ancak bu da kurumun alan adı tasarımıyla birlikte planlanmalıdır.
3. DKIM değerlerini gerçek tenant'tan alın
DKIM selector ve hedef kayıtları ortamınıza özgüdür. İnternetteki başka bir tenant'ın CNAME değerini kopyalamayın. Yönetim arayüzünde alan adınız için gösterilen güncel değerleri yetkili DNS'e ekleyin ve ilgili hizmetin imzalama durumunu doğrulayın. DNS kaydının oluşmasıyla imzalamanın etkin olması aynı aşama değildir.
Farklı gönderim servislerinin ayrı DKIM düzenleri bulunabilir. Anahtar yenileme ve selector değişikliği sırasında hangi kayıtların kullanıldığını takip edin. Silinen bir DNS kaydının hâlâ aktif bir göndericiyi etkileyip etkilemediğini anlamadan temizlik yapmayın. Her kaydın iş sahibi ve tedarikçi bağlantısı envanterde bulunmalıdır.
4. DMARC raporlamasını kontrollü başlatın
İlk değerlendirmede gözlem amacıyla p=none politikası kullanılabilir. Bu seçim raporlama sağlar; reddetme politikası değildir. Örnekteki rapor adresi anlatım içindir ve kendi yönettiğiniz adresle değiştirilmelidir. Raporları okuyacak ve koruyacak süreç hazır olmadan adres yayımlamayın.
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:[email protected]"DNS sağlayıcısının ad alanını otomatik tamamlayıp tamamlamadığını kontrol edin. Yanlışlıkla alan adını iki kez eklemek sık görülen yapılandırma hatalarındandır. Yayınlanan kaydı dışarıdan sorgulayarak doğrulayın. Rapor hedefi başka bir alan adındaysa ilgili yetkilendirme gereksinimleri ayrıca değerlendirilir.
5. Raporları iş kaynaklarıyla eşleştirin
Raporlarda görünen her başarısız kaynak doğrudan saldırı veya gereksiz sistem olarak sınıflandırılmamalıdır. Meşru ama eksik yapılandırılmış gönderici de olabilir. Gönderici envanteriyle eşleştirme yapın, eksik kimlik doğrulama ve hizalama nedenlerini araştırın. Yönlendirilmiş mesajların davranışı da incelemeyi etkileyebilir.
Kapsam yeterince anlaşılmadan quarantine veya reject politikasına geçmek meşru yazışmayı etkileyebilir. Geçiş kararını tüm iş döngülerini temsil eden gözlem ve test sonuçlarıyla verin. Sabit bir gün sayısı her kurum için yeterli değildir. Test listesinde uygulama bildirimleri, kampanyalar ve belge gönderimleri de bulunmalıdır.
İşletim kontrol listesi
- Bütün meşru göndericiler ve iş sahipleri listelendi.
- SPF, DKIM ve DMARC sonuçları test mesajlarında incelendi.
- Raporlama adresi, erişim ve takip sorumlusu belirlendi.
- Politika geçişinin kabul ve geri dönüş ölçütleri yazıldı.
- Yeni gönderici ekleme süreci DNS yönetimiyle ilişkilendirildi.
CieloSync ile kurumsal e-posta güvenliği ve DNS ihtiyaçlarınızı değerlendirebilirsiniz. Kayıtları tek tek eklemek yerine bütün gönderim düzeninin birlikte çalışmasını hedefleyelim.