Defaults.Exposed › Raporlar

SPF'im Neden Başarısız Oluyor? Birleşik Krallık ve AB Göndericileri İçin SaaS 10 Sorgu Sorunu (2026)

Yayımlanma 2026-07-09

Veriler 2026-06-29 itibarıyla · metodoloji v7. 261 milyon derecelendirilmiş alan adı genelinde toplam sayım verileri. Nasıl derecelendirdiğimizi inceleyin.

Birleşik Krallık veya AB’de SaaS araçları kullanan bir işletme için SPF başarısız olduğunda, en olası neden hiç düşünmek zorunda kalmadığınız tek bir RFC kuralıdır: 10 DNS sorgusunun ötesinde SPF “başarısız” döndürmez — PermError döndürür; bu da kaydın hiç yokmuş gibi işlem görmesi anlamına gelir. En az 797,263 alan adı bu çizgiyi zaten geçti. 2,119,539 alan adı ise tam olarak 9–10 sorguda bekliyor — tek bir yeni araç onları aynı uçuruma sürüklemek için yeterli.

Bir SaaS aracı eklediğinizde SPF neden bozuluyor?

SPF, alan adınız adına posta göndermesi yetkili posta sunucularını listeleyerek çalışır. Modern işletmeler genellikle kendi posta sunucularını çalıştırmaz — dahili e-posta için Google Workspace, kampanyalar için Mailchimp, satış dizileri için HubSpot, CRM iletişimi için Pipedrive kullanır. Her platform, DNS’inize yapıştırmanız için bir include: satırı verir.

Sorun şu: her include: kendi başına bir DNS sorgusudur. Ve o include içindeki her kayıt, özyinelemeli olarak daha fazla sorgu tetikleyebilir. RFC 7208 §4.6.4, on adet için katı bir üst sınır belirler. Onun ötesinde, alıcı posta sunucusu değerlendirmeyi durdurup PermError döndürür — ve PermError, spam’e düşen bir yumuşak başarısızlık değildir. Bu, SPF kaydınızın mevcut değilmiş gibi işlem görmesi demektir. E-posta kimlik doğrulaması SPF ayağında başarısız olur.

Bunu DNS panelinizde göremezsiniz. Sayaç yalnızca canlı değerlendirme sırasında çalışır. Görünür kaydınızda üç include: satırı olabilir ve yine de on iki sorgu derinliğinde olabilirsiniz, çünkü her satıcının SPF kaydı kendi alt include’larını çeker.

Kaç alan adı zaten sınırın üzerinde?

En az 797,263. Bu, 100 veya daha fazla kez başvurulan her SPF include: hedefini — 95.2% tüm include referanslarını kapsayan 10,842 farklı hedef — çözümledikten ve her alan adının tam zincirini fiyatlandırdıktan sonraki sayıdır. Yüzeysel sayım (bir kayıttaki yalnızca görünür satırları sayarak bulacağınız) yaklaşık 7,958 bulur. Zincir fiyatlandırmalı rakam 100 kat daha büyük, çünkü hasarın neredeyse tamamı include hedeflerinin içinde görünmez.

Avrupa işletmesini en büyük olasılıkla etkileyen durum:

Avrupa barındırma sağlayıcıları ve zayıf SPF varsayılanları

Başladığınız barındırma sağlayıcısı önemlidir — çünkü bazıları, tek bir SaaS aracını bağlamadan önce on sorgunuzun birkaçını tüketen SPF varsayılanları ayarlar.

Sayımımızdaki Avrupa alan adlarının kullandığı en büyük barındırma sağlayıcıları arasında:

IONOS öne çıkıyor: IONOS barındırmalı alan adlarının yalnızca 1.0%‘i uygulayan DMARC’a sahip; bu da büyük çoğunluğunun hiçbir anlamlı gönderici kimlik doğrulaması olmadığı anlamına gelir. OVH alan adları, sıkı SPF ayarında (43.7%) daha iyi performans gösterse de DMARC uygulamasında 2.2%‘e düşüyor — DMARC ile bağlamadan SPF tek başına yalnızca zarfı korur, alıcının gördüğünü değil.

Microsoft 365, olumlu anlamda istisnadır: Microsoft barındırmalı alan adlarının 85.0%‘i, büyük ölçüde Microsoft’un posta akışı sihirbazının -all ayarını varsayılan olarak girmesi sayesinde sıkı SPF kullanır. Google Workspace varsayılan olarak ~all (softfail) ayarlar ve alan adlarının 92%‘ini sıkı koruma olmadan bırakır.

SPF arızanızı 60 saniyeden kısa sürede nasıl teşhis edersiniz

En hızlı kontrol, yalnızca görünür kaydı değil, tam sorgu zincirini değerlendiren ücretsiz bir araçtır. Komut satırında nslookup -type=TXT yourdomain.com komutunu çalıştırın ve gördüğünüz her include: öğesini sayın. Ardından bu kayıtların her birini arayın ve onlarınkileri sayın. Include’lar bitmeden önce parmaklarınız biterse, tehlike bölgesindesiniz.

Daha güvenilir bir yaklaşım: alan adınızı burada kontrol edin — tarayıcı, çözümlenmiş zincirin tamamını değerlendirir, PermError’u işaretler ve sorgu bütçenizi hangi mekanizmaların tükettiğini gösterir.

Üç tanısal sonuç:

• PermError — Zaten onu aştınız. Gönderdiğiniz her e-posta, alıcı tarafında SPF kontrolünde başarısız olur.
• 9–10 sorguda — Uçurumun kenarındasınız. Bir sonraki SaaS entegrasyonu sizi uçurumdan iter.
• Hardfail (-all) yerine Softfail (~all) — Sınırın altındasınız ancak kayıt gerçek koruma sağlamak için çok izin verici biçimde ayarlanmış. -all ile ~all karşılaştırması için SPF yanlış yapılandırma raporuna bakın.

Birden fazla SaaS aracı kullandığınızda SPF nasıl düzeltilir

Kalıcılık sırasına göre üç yaklaşım vardır:

1. Denetleme ve budama. Mevcut kaydınızdaki her include: öğesini listeleyerek başlayın. Artık kullanmadığınız herhangi bir platformu kaldırın — eski ESP’ler, önceki sözleşmelerin CRM araçları, deneyip bıraktığınız platformlar. Bu ücretsizdir ve çoğunlukla birkaç sorguyu geri kazandırır. Kaldırılan her include:, 1–3 alt sorguyu ortadan kaldırabilir.

2. SPF kaydınızı düzleştirme. SPF düzleştirme, tüm include: hedeflerini temel IP aralıklarına çözümler ve bunları ip4: ve ip6: mekanizmaları olarak doğrudan kaydınıza yazar. IP mekanizmaları sorgu tetiklemez, bu nedenle düzleştirilmiş bir kayıt onlarca gönderme kaynağını listeleyebilir ve yine de sıfır sorguda kalabilir. Dezavantajı: bir satıcı gönderme IP’lerini güncellediğinde — ve bu bildirim yapılmadan gerçekleşir — yeniden düzleştirmeniz gerekir. Çoğu kuruluş, bunu manuel olarak takip etmek yerine IP değişikliklerini izleyen yönetilen bir SPF düzleştirme hizmeti (PowerDMARC, EasyDMARC, Dmarcian ve diğerleri bunu sunar) kullanır.

3. SPF makrolarını kullanma. RFC 7208 makroları, bir include zinciri yerine her kontrolde tek bir DNS sorgusu gerçekleştiren ve dinamik yanıt veren kayıtlar oluşturmanıza olanak tanır. Makrolar, DNS barındırma desteği ve biraz uygulama çabası gerektirir; ancak çok sayıda SaaS gönderene sahip kuruluşlar için mimari açıdan temiz çözümdür.

SPF’yi düzelttikten sonra DMARC uygulamasıyla eşleştirin — DMARC olmadan SPF yalnızca zarf göndericisini doğrular, alıcıların gördüğü başlık From: adresini değil.

Sıkça sorulan sorular

SPF kaydım DNS aracımı geçiyor ancak e-posta başlıklarında neden başarısız olmaya devam ediyor? Çoğu DNS arama aracı yalnızca kendi kaydınızdaki görünür mekanizmaları sayar, bu mekanizmaların tetiklediği alt sorguları değil. İki include: satırınız olabilir ve yine de her satıcının kaydı birkaç tane daha içeriyorsa sınırın üzerinde olabilirsiniz. Yalnızca zincir fiyatlandırma aracı (veya alıcı bir posta sunucusu) tam derinliği sayar. Gerçek zincir sayısını görmek için alan adınızı kontrol edin.

SPF başarısız olmak e-postalarımın spam’e gideceği anlamına mı gelir? PermError (çok fazla sorgu), kimlik doğrulamanın SPF ayağının sonuçsuz bir sonuç döndürdüğü anlamına gelir — fiilen yok sayılır. DMARC hem SPF’yi hem de DKIM’i değerlendirir; DKIM geçerse, SPF PermError’una rağmen DMARC yine de geçebilir. Hiçbiri geçmezse DMARC başarısız olur ve sonuç DMARC politikanıza bağlıdır. p=none’da e-posta yine de iletilir ancak başarısızlık günlüğe kaydedilir. p=quarantine veya p=reject’te e-posta filtrelenir veya geri döner. Yalnızca DKIM’e güvenmemek için SPF’yi düzeltin.

Tipik bir SaaS yığını kaç sorgu kullanır? Sayımımızdaki p99 SPF kaydı, herhangi bir şey eklemeden önce 9 sorguda — tam sınırda — durmaktadır. Google Workspace kaydı 3–4 sorgu ekler; Mailchimp 1–2 ekler; HubSpot, mevcut yapılandırmasına bağlı olarak 1–3 ekler. Üç ana araç artı barındırma sağlayıcınızın varsayılanı çoğunlukla onu aşmaya yetecektir.

SPF düzleştirme güvenli midir? Evet, güncel tutulduğu sürece. Düzleştirme include: zincirlerini statik IP aralıklarına dönüştürür — bir satıcı gönderme IP’lerini değiştirirse ve siz yeniden düzleştirmezseniz, onların postasını reddetmeye başlarsınız. Çoğu kuruluş, bunu manuel olarak yönetmek yerine IP değişikliklerini izleyen yönetilen bir düzleştirme hizmeti kullanır.

SPF yıllardır böyle — neden şimdi aniden başarısız oluyor? Çünkü satıcılarınız sizin değil, kendi SPF kayıtlarını güncelledi. Bir SaaS platformu her yeni gönderme IP aralığı eklediğinde veya başka bir include iç içe geçirdiğinde, sizin tarafınızda herhangi bir değişiklik olmadan zincir maliyetiniz artar. 10 sorgu sınırı mesaj alındığında canlı olarak değerlendirilir; bu nedenle Salı sabahı gerçekleşen bir satıcı değişikliği, Salı öğleden sonra SPF’nizi bozabilir.

SPF düzeltmek e-posta teslim edilebilirliğini geliştirir mi? Kimlik doğrulama başarısızlığının bir kaynağını ortadan kaldırır; bu, tutarlı teslimat için bir ön koşuldur — özellikle Google ve Yahoo’nun artık toplu göndericiler için DMARC hizalamasını uyguladığı göz önüne alındığında. SPF tek başına tam resim değildir: tam e-posta kimlik doğrulaması için DKIM ve DMARC ile birleştirin.

SPF’nizi ücretsiz kontrol edin

SPF kaydınızın arama sınırının üzerinde olup olmadığından — ya da alan adınızı korumak için çok zayıf ayarlanmış olup olmadığından — emin değilseniz, ücretsiz bir kontrol çalıştırın. Çözümlenmiş zincirin tamamını değerlendirir ve bütçenin tam olarak nerede harcandığını gösterir.

Alan adınızı kontrol edin → · SPF’yi düzeltin → · SPF PermError raporu → · SPF yanlış yapılandırma raporu → · SPF benimseme olgunluk modeli → · DMARC’ı düzeltin → · Yalnızca toplu veri. Veriler AB’de depolanır ve işlenir.