Bir şirket WordPress için yeni bir işlem e-postası sağlayıcısı eklerken ikinci SPF kaydını yayımlıyor. Bazı alıcılar artık kalıcı SPF hatası veriyor. Ekip ise yalnız görünen Fromadresine bakıyor ve sağlayıcının farklı Return-Path domainini gözden kaçırıyor.
Doğru kurulum SMTP envelope kimliğiyle başlar. Bu domain adına e-posta gönderen bütün meşru hizmetleri listeleyin, gerekli kaynakları tek politikada birleştirin ve sonucu gelen iletinin başlıklarında doğrulayın.
Bu konu ne anlama gelir?
Sender Policy Framework (SPF), belirli bir SMTP MAIL FROMdomaini adına hangi sistemlerin e-posta gönderebileceğini belirten DNS politikasıdır. Alıcı sunucu bağlantı kuran IP’yi envelope domainindeki SPF kaydıyla karşılaştırır; kullanılabilir MAIL FROM kimliği yoksa HELO domainini değerlendirebilir.
SPF iletiyi imzalamaz ve okuyucunun gördüğü Fromadresini tek başına doğrulamaz. DMARC, SPF sonucunu ancak doğrulanan envelope domaini görünen From domainiyle hizalıysa kullanabilir.
Gerçekçi bir WordPress örneği
Ana domainde Microsoft 365 için mevcut bir SPF kaydı bulunuyor. WordPress sağlayıcısı eklenirken gerekli include, ayrı bir SPF TXT kaydı olarak yayımlanıyor. İki politika gören alıcılar permerrorsonucu döndürebiliyor.
DNS sorumlusu önce sağlayıcının hangi Return-Path domainini kullandığını doğruluyor. Şirket domaini değerlendiriliyorsa gerekli include mevcut politikaya ekleniyor. Sağlayıcı kendi domainini kullanıyorsa yalnız görünen From adresi nedeniyle şirket kaydı değiştirilmiyor. Kararı test iletisinin başlıkları veriyor.
Neden önemlidir ve ne zaman kullanılır?
SPF, alıcı sunucuların envelope domaini için yetkili gönderim altyapısını yetkisiz kaynaklardan ayırmasına yardımcı olur. Eksik politika meşru iletileri etkileyebilir; gereğinden geniş politika ise artık kullanılmayan sistemlere gönderim yetkisi verir.
WordPress aynı domaini kurumsal posta, destek masası, e-ticaret sistemi, pazarlama platformu veya relay ile paylaşabilir. Son allniteleyicisini sıkılaştırmadan önce aynı envelope domainini kullanan bütün kaynaklar bilinmelidir.
Kuruluş ilgili DNS’i yönetiyor ve gönderen envanterini güncel tutabiliyorsa SPF yapılandırın. Return-Path domainini sağlayıcı yönetiyorsa onun güncel dokümanını izleyin; görünen From domainine ilgisiz kayıt eklemek çözüm değildir.
Yeni başlayanlar için anlaşılır yol
- Kontrollü bir WordPress e-postası gönderin; gerçekten değerlendirilen domaini bulmak için
Return-Path,Received-SPFveAuthentication-Resultsbaşlıklarını inceleyin. - Bu domain adına gönderim yapan bütün yetkili hizmetleri, IPv4 ve IPv6 adreslerini, relay’leri ve sağlayıcı
includemekanizmalarını listeleyin. - Yetkili DNS’teki güncel TXT kayıtlarını okuyun.
v=spf1ile başlayan tek bir SPF politikası tutun; ikinci kayıt açmak yerine gerekli mekanizmaları mevcut kayıtta birleştirin. - Eski kaynakları ancak sorumlu ekip artık kullanılmadığını onayladıktan sonra çıkarın. Son
allniteleyicisini bilinçli seçin. - Yetkili DNS’i ve birden fazla resolver’ı sorgulayın, kalan her kaynaktan e-posta gönderin. SPF sonucuyla DMARC hizasını ayrı ayrı kontrol edin.
İleri teknik yol
İç içe includeve redirectzincirlerini açıp DNS sorgusu oluşturan bütün mekanizmaları SPF lookup sınırına göre sayın. Boş sonuçları, sağlayıcının yönettiği bağımlılıkları, IPv6 yetkisini, makroları ve alt domainleri inceleyin. Kısa görünen kayıt bile üçüncü taraflar nedeniyle sınırı aşabilir.
Her dış bağımlılık için sorumlu kişiyi, amacı, son inceleme tarihini ve kaldırma koşulunu kaydedin. Yetkisiz bir kaynaktan negatif test de yapılmalıdır; ancak gerçek müşteri domainini taklit etmeyen kontrollü bir ortam kullanın.
Sağlayıcı değişikliği, şirket birleşmesi, destek masası geçişi veya yeni pazarlama aracı sonrasında politikayı yeniden gözden geçirin. Üçüncü taraf, şirketin ana TXT kaydı değişmeden kendi include içeriğini değiştirebilir.
Riskler, sık hatalar, yedekleme ve geri alma
Aynı DNS adı için birden fazla SPF politikası yayımlamayın, belgelenmemiş sağlayıcı IP aralığını kopyalamayın, eski göndericileri yetkili bırakmayın ve kullanım dışı ptrmekanizmasını eklemeyin. Eksiksiz envanter olmadan doğrudan katı hata niteleyicisine geçmek meşru e-postaları engelleyebilir.
Değişiklikten önce mevcut DNS değerini ve sorumlusunu kaydedin; TTL ile yayılma süresini planlayın. Kullanılan kaynaklar başarısız olursa, yetkili DNS sunucuları farklı yanıt verirse, lookup sınırı aşılırsa veya yanlış domain değerlendirilirse önceki tek politikaya dönün ve envanteri düzeltin.
AIOWS nasıl yardımcı olur?
AIOWS SMTP Yöneticisi
AIOWS SMTP Yöneticisi, SPF hazırlanırken WordPress tarafındaki SMTP sunucusunu, gönderen kimliğini ve kontrollü testi görünür tutar. Yapılandırılan yoldan gönderilen test iletisinin başlıkları gerçek Return-Path değerini ve alıcının değerlendirdiği SPF domainini gösterir.
Bu başlıkları sağlayıcının güncel dokümanıyla ve yetkili DNS kaydıyla karşılaştırın. Aynı gönderim yolunu kullanan gerçek bir WordPress bildirimiyle testi tekrarlayın; genel test e-postası her form, sipariş veya hesap iletisinin aynı ayarı kullandığını kanıtlamaz.
AIOWS DNS kaydı yayımlayamaz veya değiştiremez, sağlayıcının SPF include kaydını yönetemez ve yetkisiz kaynağa gönderim izni veremez. Domainler farklıysa SPF pass sonucu DMARC hizası da oluşturmaz. DNS yönetimi, gönderen envanteri ve politika incelemesi modülün dışındadır.
AIOWS SMTP Yöneticisi’ni inceleyinAIOWS planlarını karşılaştırın
İlgili AIOWS yazıları
- WordPress E-postaları İçin DKIM Nasıl Ayarlanır?
- WordPress E-postaları İçin DMARC Nasıl Ayarlanır?
- WordPress Gönderen Adresi Uyuşmazlığı Nasıl Çözülür?
Sonuç ve önerilen yol
Önce gerçek envelope domainini belirleyin. Bu domain için yalnız incelenmiş gönderim kaynaklarını içeren ve değerlendirme sınırlarını aşmayan tek bir SPF politikası tutun. Her yolu yetkili DNS ve ileti başlıklarında doğrulayın; DMARC hizasını ayrıca sınayın.
