Defaults.Exposed › Düzeltmeler › Guides

E-Posta Sağlayıcısı Değiştirdikten Sonra SPF Çalışmayı Durdurdu — Geçiş Düzeltmesi (2026)

Yayımlanma 2026-07-08

Veriler: 2026-06-29 itibarıyla · metodoloji v7. 261 milyon derecelendirilmiş alan adı üzerinde toplam sayım verileri. Bkz. nasıl derecelendiriyoruz.

SPF, genellikle e-posta sağlayıcısı değişikliğinden sonra bozulur çünkü yeni sağlayıcının kaydı eskisinin yanına eklenir. İki v=spf1 kaydı kalıcı bir hatadır — SPF tamamen geçersiz olur. Defaults.Exposed”ın 261 milyon alan adı sayımına göre 1,013,416 alan adı — SPF deneyenlerin yaklaşık 138‘inde biri — bu durumdadır. Bunları tek bir kayıtta birleştirin.

Düzeltme yaklaşık on dakika sürer: geçişin geride bıraktıklarını tam olarak görmek için alan adını tarayın, her SPF kaydını yetkili ad sunucularınızda listeleyin, yalnızca yeni sağlayıcınızı içeren tek bir kayıtta birleştirin ve dig ile yeniden doğrulayın. Bu kılavuz, çoğu geçişin unuttuğu DKIM ve ad sunucu kontrollerini de dahil ederek her adımı açıklar.

SPF neden geçişten hemen sonra bozuldu?

Çünkü yeni sağlayıcının kurulum kılavuzu “bu TXT kaydını ekleyin” dedi — ve siz de eskisinin yanına eklediniz. Bu, SPF standardının izin vermediği tek şeydir. RFC 7208 (§3.2, §4.5”te öngörülen hata sonucu) her alan adı başına tam olarak bir v=spf1 kaydına izin verir; ikisini veya daha fazlasını bulan bir alıcı hangisinin yetkili olduğunu tahmin etmek yerine PermError döndürmek zorundadır. PermError, SPF”nin geçersiz olduğu anlamına gelir: eski kayıt değil, yeni kayıt değil, hiç SPF yok.

Ve bu kadar da değil. DMARC bir PermError”u SPF ayağında başarısızlık sayar, dolayısıyla postanız tamamen DKIM”e bağımlı olur. Yeni sağlayıcının DKIM”i henüz kurulmamışsa — geçiş ortasında yaygın — altyapıyı değiştirdiğiniz tam anda kimlik doğrulamasız gönderiyorsunuzdur; bu, alıcıların sizi en çok incelediği andır.

Bu, sağlayıcı değiştirdiğinizde korumayı geçersiz kılan kopyala-yapıştırdır ve nadir değildir: 1,013,416 alan adı şu anda iki veya daha fazla SPF kaydı yayınlıyor — Defaults.Exposed”ın 261 milyon alan adı sayımına göre SPF denemeye çalışan 139 milyonluk nüfusun yaklaşık 138‘inde biri (veriler: 2026-06-29 itibarıyla). İki kayıt tuzağının tam sayıları için kendi raporu var; bu sayfa prosedürel düzeltmedir.

Geçiş geride ne bıraktı?

Neredeyse her geçiş sonrası SPF başarısızlığını beş geride bırakılan neden oluşturur. Bunları şu sırayla kontrol edin:

Nasıl düzeltilir? Geçiş kontrol listesi

1. Önce defaults.exposed üzerinde ücretsiz taramayı çalıştırın. Canlı DNS”inizi okur ve birden fazla SPF kaydınız olup olmadığını, eksik bir include”ı ya da DKIM boşluğunu söyler — herhangi bir şeye dokunmadan önce teşhis koyun.

2. Yetkili ad sunucularında her SPF kaydını listeleyin. dig +short NS yourdomain.com, ardından birine karşı dig +short TXT yourdomain.com @<nameserver>. v=spf1 ile başlayan dizeleri sayın. Güvenli sayı 1”dir.

3. Tek bir kayıtta birleştirin. v=spf1 ile başlayan bir kayıt, yeni sağlayıcınızın include”unu ve hâlâ kullandığınız diğer gönderici hizmetleri (faturalama aracı, CRM, bülten platformu), tek bir -all veya ~all ile. Örnek — eski Google Workspace, yeni Microsoft 365, boşaltma sırasında:

   Önce:  "v=spf1 include:_spf.google.com ~all"
          "v=spf1 include:spf.protection.outlook.com -all"
   
   Sonra: "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"
   Daha sonra: "v=spf1 include:spf.protection.outlook.com -all"
   

   Sağlayıcı değerleri ve DNS panel incelikleri Google Workspace ve Microsoft 365 kurulum kılavuzlarında.

4. Fazladan kayıtları silin. Silmeden birleştirmek hiçbir şeyi düzeltmez — PermError sayıdan kaynaklanır.

5. Eski sağlayıcının include”unu yalnızca eski sistem hâlâ gönderirken tutun — zamanlanmış raporlar, eski bir CRM bağlantısı, unutulmuş bir posta kutusu. Boşaltma tamamlanınca kaldırın: eski bir include eski altyapının sizin adınıza göndermeye yetkili kalmasını sağlar ve her include, en az 797,263 alan adının bu sınırı aşarak SPF”yi geçersiz kıldığı SPF”nin 10 sorguluk sınırına karşı DNS sorgusu maliyeti taşır (sayım, 2026-06-29).

6. Yeni sağlayıcının DKIM”ini kurun — ve eski seçicileri henüz silmeyin. Yeni seçiciler yeni postaları imzalar; eski seçiciler onlarla imzalanmış her mesaj iletilene ve yönlendirmeler yerleşene kadar yayında kalmalıdır. Tam talimatlar için bkz. e-posta araçlarını değiştirdikten sonra DKIM başarısız oluyor.

7. Ad sunucularını da değiştirdiyseniz her ikisini de kontrol edin. DNS geçişleri çoğunlukla e-posta geçişleriyle birlikte gerçekleşir. Eski ve yeni NS setini doğrudan sorgulayın (dig TXT yourdomain.com @old-ns ve @new-ns) — tescilci delegasyonu tamamen yayılana kadar bazı alıcılar hâlâ eski sunuculara soruyor, bu nedenle düzeltilmiş kayıt hangi set yanıt verirse orada bulunmalıdır.

8. Taramayı yeniden çalıştırın ve SPF”nin geçişle tek bir geçerli kayıt gösterdiğini onaylayın.

SPF aslında hangi alan adını kontrol eder?

Alıcılar SPF”yi Return-Path (RFC5321.MailFrom) alanına — geri dönüş adresine — karşı değerlendirir; alıcılarınızın gördüğü From başlığına değil. Bir geçişten sonra bu iki kez önem taşır: yeni sağlayıcınız özel bir yapılandırana kadar kendi geri dönüş alanını kullanıyor olabilir ve sizin alanınız olmayan bir alanda SPF “geçmesi” DMARC için hizalanmaz. Bunun düzeltmesi yeni sağlayıcının DKIM”idir, alan adınızla imzalanmış.

Aynı anda hem geçiş yapıyor hem de yeniden markalaşıyor musunuz?

Alan adını da değiştirdiniz mi? Bunları iki iş olarak ele alın. Yeni alan adının ilk günden tam yığına ihtiyacı var — SPF, DKIM, DMARC; yeni alan adı e-posta kontrol listesini kullanın. Eski alan adı yönlendirme veya yanıt trafiği aktığı sürece kimlik doğrulamalı kalır ve park edildiğinde (sadece terk edilmek yerine) açıkça kilitlenir. Geriye bırakılan, yarı bozuk SPF”li eski bir alan adı, eski adınızı taşıyan bir sahtecilik hedefidir.

Sık sorulan sorular

Geçiş sırasında iki SPF kaydını tutabilir miyim? Hayır. Standartta yetkisiz süre yoktur — iki v=spf1 kaydı, ikincisi mevcut olduğu andan itibaren PermError”dur ve sayıma göre 1,013,416 alan adı 2026-06-29 itibarıyla bu durumda oturuyor. Geçiş güvenli örüntü, çakışma sırasında her iki sağlayıcının include”larını taşıyan tek bir kayıttır.

Eski sağlayıcının include”unu ne kadar süre tutmalıyım? Eski sağlayıcı üzerinden hiçbir şey gönderilmeyene kadar — genellikle çakışma pencerenizin uzunluğu, günlerden birkaç haftaya. Hâlâ eski sistem üzerinden gelen mesajların Return-Path”ini izleyin; bu trafik durduğunda include”u kaldırın ve sorgu sayınızı yeniden kontrol edin.

Düzelttikten sonra denetleyici hâlâ eski kaydımı gösteriyor — neden? DNS önbelleğe alma, kaydın TTL”ine uyar ve ad sunucularınız değiştiyse bazı çözümleyiciler hâlâ eski seti sorgular. Yetkili ad sunucularında dig TXT yourdomain.com @<ns> ile doğrudan doğrulayın — yanıt orada doğruysa düzeltme tamamlanmıştır ve önbellekler yetişecektir. Bir NS setinde yanlışsa bkz. ”SPF kaydı bulunamadı” — gerçek nedenler.

Sağlayıcı değiştirdiğimde DMARC”ı değiştirmem gerekiyor mu? Genellikle kaydın kendisini değil — rapor posta kutunuzu ve politikanızı adlandırıyor, sağlayıcınızı değil. Ancak DMARC sonuçlarınız az önce geçiş yaptığınız SPF ve DKIM”e bağlıdır: geçiş sırasında raporlarda düşüş bekleyin ve politikayı sıkılaştırmadan önce her iki ayağın geçtiğini onaylayın. Tarama SPF ayağının hâlâ başarısız olduğunu gösteriyorsa SPF”yi düzeltin ile başlayın.

Sahibine raporu gönderin

Bu geçişi bir müşteri için yapıyorsanız, kanıtla kapatın. Birleştirme yayına girdikten sonra ücretsiz taramayı yeniden çalıştırın ve derecelendirilmiş raporu işletme sahibine gönderin: yeni sağlayıcıda SPF, DKIM ve DMARC geçiyor, sade bir dille, tarihli. Bu, siber sigorta yenileme ve bir sonraki tedarikçi güvenlik anketi için dosyalayacakları eserdir — geçişin alan adı başladığından daha iyi kimlik doğrulanmış bıraktığının kanıtı.

Alan adınızı kontrol edin → · E-posta araçları değiştirildikten sonra DKIM başarısız oluyor → · ”SPF kaydı bulunamadı” — gerçek nedenler → · Nasıl derecelendiriyoruz → · Yalnızca toplu veriler. Veriler AB”de depolanır ve işlenir.