Defaults.Exposed › Düzeltmeler › Guides

"SPF Kaydı Bulunamadı" — Ama Yayınladığınızdan Eminsiniz? 5 Gerçek Neden (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.

Bir denetleyici “SPF kaydı bulunamadı” diyorsa ama siz kesinlikle yayınladığınızı biliyorsanız, kayıt genellikle eksik değil, görünmez durumdadır: 1,013,416 alan adı — SPF deneyenlerin yaklaşık 138‘de biri — iki veya daha fazla SPF kaydı yayınlıyor; bu, RFC 7208 §3.2 kapsamında pek çok denetleyicinin “bulunamadı” olarak raporladığı bir PermError”dır. Bunu, Defaults.Exposed”ın 261 milyon alan adı sayımı ortaya koymuştur.

Tek bir oturumda düzeltilebilecek beş gerçek neden vardır: yanlış host, yinelenen kayıt, yanlış DNS türü veya bozuk tırnak, tutarsız ad sunucuları ya da uzunluk/CNAME çakışması. Aşağıda: kontrol sırası dahil her biri için 60 saniyelik test ve düzeltme adımları.

Kaydın gerçekten var olduğundan emin misiniz?

En yaygın ihtimalle başlayın: Defaults.Exposed sayımında derecelendirilen 261,086,232 alan adından 121,145,609 — %46.4 — hiç SPF kaydı yayınlamıyor. “Bunu zaten ayarladım” diyenlerden pek çoğunun kaydı artık yetkili olmayan eski bir DNS sağlayıcısına ya da hazırlık ortamına eklenmiş olduğu görülüyor. Ad sunucularınızın gerçekten işaret ettiği DNS sağlayıcısında (çoğunlukla alan adı tescilcisi değil) v=spf1 ile başlayan bir TXT kaydı olup olmadığını kontrol edin. Gerçekten yoksa dedektiflik yapmayı bırakıp SPF kaydınızı düzeltin sayfasına gidin.

SPF kaydı nasıl düzgün kontrol edilir?

Web tabanlı denetleyiciler DNS”i kendi önbellekli çözümleyicileri üzerinden sorgular. Gerçeği görmek için alan adınızın yetkili ad sunucusunu doğrudan sorgulayın:

# yetkili ad sunucularını bulun
dig NS yourdomain.com +short

# TXT kayıtları için doğrudan birine sorun
dig TXT yourdomain.com @ns1.yourdnshost.com +short

Windows”ta: nslookup -type=TXT yourdomain.com ns1.yourdnshost.com.

İki yorumlama kuralı. Birincisi, v=spf1 ile başlayan satırları sayın — sayı içerik kadar önemlidir. İkincisi, doğru adı sorguladığınızı kontrol edin: alıcılar SPF”yi Return-Path (RFC5321.MailFrom, “envelope from”) alan adına karşı değerlendirir; alıcıların gördüğü From adresi değil. Bülten aracınız bounce.yourdomain.com üzerinden geri dönen posta gönderiyorsa, ana ad adresindeki mükemmel bir kayıt alıcıların aradığı kayıt değildir.

Beş gerçek neden nelerdir?

Veriler: 2026-06-29 itibarıyla.

1. Kayıt yanlış hostta mı?

Klasik hata: posta yourdomain.com adresinden geldiğini iddia ederken SPF mail.yourdomain.com”a eklendi ya da tam tersi. SPF aşağı doğru devralınmaz — ana addaki kayıt alt alan adları hakkında hiçbir şey söylemez ve tam tersi. Return-Path”inizdeki adda yayınlayın. Kendi geri dönüş alt alan adı üzerinden gönderen bir satıcının o alt alan adında bir kaydının olması gerekir; bu genellikle satıcının sağladığı bir CNAME veya TXT”dir (GoDaddy SPF kurulum kılavuzu bu alanların nerede olduğunu gösterir).

2. İki SPF kaydınız var mı?

Manşet nedenin bu olduğu ve e-posta kimlik doğrulamadaki en yanıltıcı hata mesajı. RFC 7208 §3.2 açıktır: bir alanda tam olarak bir SPF kaydı bulunmalıdır. İki veya daha fazlası PermError”dur — alıcılar SPF”nizi geçersiz sayar. Bazı denetleyiciler bu durumu doğru raporlar (“birden fazla kayıt bulundu”); diğerleri net etkiyi raporlar: geçerli SPF kaydı bulunamadı. Panelinizdeki kaydı görür ve denetleyicinin bozuk olduğu sonucuna varırsınız. Öyle değil — bir kayıt fazlanız var.

Sayım, 1,013,416 alan adının iki veya daha fazla SPF kaydı taşıdığını buldu — SPF deneyenlerin yaklaşık 138‘inde biri — her birinin SPF”si fiilen kapalı. Bu durum genellikle bir sağlayıcı değişikliği sırasında gerçekleşir: yeni sağlayıcının sihirbazı eskisini düzenlemek yerine yeni bir kayıt ekler. Düzeltme bir birleştirmedir, ikinci kayıt değil: her şeyi tek bir v=spf1 … ~all satırında birleştirin ve gerisini silin. İki SPF kaydı = hiç yok adlı veri raporumuz bir milyon alan adının buraya nasıl geldiğini açıklıyor; bu durum bir geçişten sonra başladıysa sağlayıcı değiştirdikten sonra SPF çalışmayı durdurdu sayfasına bakın. Birleştirirken her include: satırını körü körüne birleştirmeyin — her biri, SPF”nin 10 sınırına karşı DNS sorgusu maliyeti taşır ve “bulunamadı” yerine PermError: çok fazla DNS sorgusu hatası verebilir.

3. Yanlış kayıt türü mü yayınladınız — yoksa arayüz mi bozdu?

Erken SPF”nin kendi DNS kayıt türü vardı (tür 99, tam adıyla “SPF”). Bu tür kullanımdan kaldırıldı: RFC 7208 TXT gerektiriyor ve alıcılar tür 99”u sorgulamıyor. Bazı DNS panelleri hâlâ kayıt türü açılır menüsünde “SPF” sunuyor; bunu seçerseniz kaydınız gerçek, düzgün biçimlendirilmiş ve görünmez olur. Tür sütununu kontrol edin ve TXT olarak yeniden yayınlayın.

Daha ince kardeş sorun tırnaklamadır. Kendi tırnaklarını ekleyen bir alana tırnak içine alınmış bir değer yapıştırmak ""v=spf1 …"" üretir — bu artık v=spf1 ile başlamaz, dolayısıyla bir doğrulayıcı için mevcut değildir. dig çıktınız gerçeği gösterir; DNS paneli bunu çoğunlukla görsel olarak gizler.

4. Gerçekten “hâlâ yayılıyor” mu?

“Yayılması için 24-48 saat verin” DNS”teki en fazla abartılan tavsiyedir. Yayılma sadece önbelleklerin süresinin dolmasıdır: kaydın TTL”i geçtikten sonra (genellikle 1 saat, nadiren 24 saatten fazla) her çözümleyici yeni yanıtı görebilir. 24 saatten sonra hâlâ bulunamıyorsa yayılma neden değildir.

İki gerçek suçlu: negatif önbellekleme — kaydı eklemeden önce sizi sorgulayan bir çözümleyici negatif TTL süresi dolana kadar “böyle bir kayıt yok” yanıtını önbelleğe alır — ve bir geçişten sonra tutarsız ad sunucuları, alan adı artık düzenlemediğiniz eski sağlayıcının ad sunucularını yenileriyle birlikte listeliyorsa dünyanın yarısı artık düzenlemediğiniz bir bölgeyi okur. Her listelenen ad sunucusunu doğrudan sorgulayın; yanıtlar farklıysa buldunuz. Yalnızca gerçekten düzenlediğiniz sağlayıcının yetkili olması için tescilcinin NS delegasyonunu düzeltin.

5. Kayıt çok uzun mu veya CNAME tarafından mı engelleniyor?

TXT kaydındaki tek bir dize en fazla 255 karaktere ulaşabilir. Daha uzun SPF kayıtları yasal olsa da tek bir kayıt içinde birden fazla tırnaklı dize olarak bölünmeleri gerekir — DNS sağlayıcısı web arayüzleri ise değeri kesmek veya bir mekanizmanın ortasında kırmak suretiyle bölmeyi düzenli olarak bozar. Kaydınız uzunsa, dig çıktısında aniden biten bir değer olup olmadığını kontrol edin.

Ayrıca DNS, CNAME bulunan bir adda TXT kaydına izin vermez. mail.yourdomain.com sağlayıcınıza bir CNAME”se, oraya SPF de koyamazsınız — bazı paneller bunu kabul eder ama sonra yalnızca CNAME”i sunar. Kaydı CNAME”in işaret ettiği yere koyun (kontrol edebiliyorsanız) ya da gönderme adının CNAME”li olmaması için yeniden yapılandırın. Temiz TXT işlemli sağlayıcılar her ikisini de kolaylaştırır — bkz. Cloudflare SPF kurulum kılavuzu.

Adım adım nasıl düzeltilir?

1. defaults.exposed üzerinde ücretsiz taramayı çalıştırın — canlı DNS”inizi okur ve herhangi bir şeye dokunmadan önce beş durumdan hangisinde olduğunuzu söyler.
2. Hangi ad sunucularının yetkili olduğunu (dig NS) ve hepsinin hemfikir olduğunu onaylayın.
3. Tam Return-Path alan adı için yetkili ad sunucusunda TXT”yi sorgulayın.
4. v=spf1 satırlarını sayın: sıfır ise bir tane yayınlayın; iki veya daha fazlası ise tek bir tanede birleştirin.
5. Türün TXT olduğunu, değerin tam olarak v=spf1 ile başladığını ve yanlış tırnak ya da kesme oluşmadığını doğrulayın.
6. Bir TTL bekleyin, ardından her yerde düzgün çözümlendiğini onaylamak için yeniden tarayın.

Sık sorulan sorular

Denetleyici “bulunamadı” diyorken DNS panelimde kaydı görebiliyorum — neden? Genellikle neden 2 veya 4: ikinci bir v=spf1 kaydı her ikisini de geçersiz kılar — 2026-06-29 itibarıyla 1,013,416 alan adının içinde bulunduğu, bazı araçların “bulunamadı” olarak raporladığı bir PermError — ya da paneliniz aslında yetkili olan DNS değildir.

Düzeltmemi denetleyiciler ne zaman görür? Bir TTL — genellikle bir saat, en fazla 24 saat. Bu süreden sonra “yayılma” açıklama değildir; ad sunucusu tutarlılığından başlayarak beş nedeni yeniden kontrol edin.

DNS panelimin sunduğu “SPF” kayıt türünü kullanmalı mıyım? Hayır. Tür 99 kullanımdan kaldırıldı; RFC 7208 yalnızca TXT gerektiriyor. Tür 99 kaydı modern alıcılara görünmezdir.

Kayıt artık bulunuyor — posta neden hâlâ SPF”de başarısız oluyor? Çünkü SPF, From başlığına değil Return-Path alan adına karşı kontrol edilir ve kayıt gerçekten sizin için gönderen sunucuları listelemelidir. Bulunmak birinci adımdır; SPF kaydınızı düzeltin kılavuzu geçişi kapsar.

Hiç SPF kaydının olmaması gerçekten bu kadar yaygın mı? Evet — 121,145,609 alan adı, Defaults.Exposed sayımında derecelendirilen 261,086,232 içindeki %46.4 (2026-06-29 itibarıyla), hiç SPF yayınlamıyor. “Bulunamadı” internetin varsayılan durumudur.

Sahibine raporu gönderin

Kayıt düzgün çözümlendiğinde taramayı yeniden çalıştırın ve derecelendirilmiş raporu, alan adı kendisine ait olan işletme sahibine veya müşteriye iletin. Rapor, sade bir dille neyin bozuk olduğunu, neyi düzelttiğinizi ve alan adının şu anda nerede durduğunu gösterir — siber sigorta yenilemelerinde ve tedarikçi güvenlik anketlerinde tam olarak istenecek kanıttır. Rapor, yapılan işin makbuzudur.

SPF kaydınızı ücretsiz kontrol edin

Alan adınızın hangi beş “bulunamadı” durumundan birinde olduğunu öğrenin — gizli ve yalnızca sahibine.

Alan adınızı kontrol edin → · SPF”yi düzeltin → · Sağlayıcı değiştirdikten sonra SPF bozuldu → · Nasıl derecelendiriyoruz → · Yalnızca toplu veriler. Veriler AB”de depolanır ve işlenir.