Yeni bir e-posta aracı kurarken size bir SPF metni verilebilir. Bu metni DNS'e ikinci bir kayıt olarak eklemek, mevcut gönderim düzenini bozabilir. Diğer yandan bütün TXT kayıtlarını tek satıra indirmek de doğru değildir; doğrulama ve başka hizmet kayıtları ayrı amaçlar taşır. Önce tam kayıt adını ve hangi satırların gerçekten SPF olduğunu ayırın.
Birden fazla SPF ile birden fazla TXT aynı şey değildir
SPF standardı RFC 7208, aynı ad için birden fazla SPF seçilmesine neden olacak kayıt yayımlanmamasını belirtir. Kayıt içinde birden fazla metin parçası bulunması da ayrı bir kavramdır. Panelde birden fazla satır görmenin ne anlama geldiğini, gerçek DNS yanıtıyla birlikte değerlendirin. Ekran görüntüsüne bakarak bütün TXT kayıtlarını hatalı ilan etmeyin.
Meşru göndericileri önce listeleyin
Kurumsal kutu, web sitesi formu, muhasebe uygulaması ve dış gönderim araçlarını ayrı yazın. Sadece yeni aracın talimatını uygulamak, eski ama hâlâ gerekli bir göndericiyi dışarıda bırakabilir. SPF, DKIM ve DMARC rehberi temel görevleri ayırır. Bu incelemede amaç rastgele bir örnek politika üretmek değil, kendi gönderim envanterinize uygun yapıyı doğrulamaktır.
Kopyalamadan önce değişiklik planı hazırlayın
Mevcut kayıtları geri dönüş için kaydedin ve alan adının DNS'ini hangi panelin gerçekten yönettiğini doğrulayın. İki metni gelişigüzel birleştirmeyin; sağlayıcınızla sözdizimini ve gerekli kaynakları değerlendirin. MX ve DNS geçiş kontrolü, yanlış panelde yapılan değişiklikleri ayırmak için yardımcıdır. Web hosting taşındı diye bütün posta kayıtlarını değiştirmeyin.
Her gönderim kaynağından kontrollü test yapın
Yeni düzeni yalnız bir masaüstü mesajıyla sınamayın; envanterdeki önemli sistemlerden de hassas veri içermeyen testler gönderin. Sonucu yetkili doğrulama ekranından inceleyin. Teslimat rehberi doğrulama başarısının bütün gelecek mesajlar için garanti olmadığını değerlendirmeye yardımcı olur.
Kurumsal e-posta desteğine mevcut kayıt adı, kullanılan gönderim hizmetleri ve maskelenmiş test sonucunu iletin. Bir kaydı kimin ve neden değiştirdiğini belgeleyin. Sonraki araç kurulurken aynı hatanın tekrarlanmaması için yeni sağlayıcı talimatının doğrudan eklenmeden önce mevcut politikayla karşılaştırılmasını ekip kuralı hâline getirin. Böylece DNS düzeni yalnız çalışan değil, değiştirildiğinde etkisi anlaşılabilen bir yapı olur.
Metin parçalarını kayıt sayısıyla karıştırmayın
DNS panelinin uzun bir TXT değerini görsel olarak birkaç parçaya bölmesi, mutlaka birden fazla bağımsız politika yayımlandığı anlamına gelmez. Bu ayrımı yetkili teknik ekiple gerçek sorgu sonucundan doğrulayın. Düzeltme kaydında panelde görülen satırın değil, hangi ad için hangi politikanın hedeflendiğini yazın. Diğer TXT kayıtlarını aynı işleme dahil etmemek için her kaydın sahibini veya hizmet amacını belirtin. Yeni uygulama ekleme süreçlerinde DNS değişikliğini tek kişinin gözden geçirmesi yararlı olabilir. Özellikle birkaç sağlayıcının talimatları birleştiğinde rastgele birleştirme yerine tasarlanmış ve test edilmiş politika gerekir. Geçici başarıyı kalıcı envanter eksikliğini örtmek için kullanmayın.
Sıkça Sorulan Sorular
Alan adında birden fazla TXT kaydı olamaz mı?
Olabilir. Sorun bütün TXT kayıtları değil, aynı ad için birden fazla SPF seçilmesine neden olan kayıtlardır. Doğrulama kayıtlarını SPF sanıp silmeyin.
İki SPF metnini yan yana yapıştırabilir miyim?
Bunu genel çözüm saymayın. Sözdizimi, yetkilendirilen kaynaklar ve değerlendirme sınırları birlikte kontrol edilmelidir. Sağlayıcınızla doğrulanmış tek politikayı hazırlayın.
Eski sağlayıcının kaydı kullanılmıyor mu?
Bunu envanterle teyit edin. Hâlâ eski hizmetten gönderim yapan bir uygulama olabilir; yalnız geçiş tarihine bakarak karar vermeyin.
SPF düzeldiyse bütün mailler gelen kutusuna gider mi?
Hayır. SPF, teslimatı etkileyen doğrulama bileşenlerinden biridir; içerik, alıcı politikası ve başka koşullar sonucu etkileyebilir.