SPF kaydı nedir? Nasıl eklenir, 10 DNS arama sınırı nasıl aşılır?

SPF, iletide görünen "Kimden" (From) adresine bakmaz. İki kimliği denetler: gönderen sunucunun SMTP oturumunda HELO/EHLO ile bildirdiği ad ve MAIL FROM adresi. MAIL FROM, zarf göndericisidir (envelope sender): alıcı onu iletinin başına Return-Path başlığı olarak yazar ve hata bildirimleri (bounce) bu adrese gider (RFC 5321 §4.4). Alıcı, bağlanan IP adresinin bu adın SPF kaydında yetkili olup olmadığına bakar (RFC 7208 §1, §2.3, §2.4).

Kullanıcının gördüğü From adresi bu kimliklerden farklı olabilir; RFC 7208 §11.2 bunu açıkça uyarır. Bu açığı DMARC kapatır: SPF'nin doğruladığı alan adının From alan adıyla uyumlu (hizalı, aligned) olmasını ister (RFC 9989 §4.4.2). SPF geçse bile alan adları uyuşmuyorsa DMARC için SPF sayılmaz; ayrıntı DMARC rehberinde.

Gmail'e ileti gönderiyorsanız SPF'siz kalmak da sorun çıkarır: Google, 1 Şubat 2024'ten beri Gmail'e gönderen herkesten SPF ya da DKIM'i, günde 5.000'den fazla ileti gönderenlerden SPF, DKIM ve DMARC'ı birlikte ister. Doğrulanmamış iletiler spam olabilir ya da 5.7.26 hatasıyla reddedilebilir.

Kayıt, boşlukla ayrılmış terimlerden oluşur. Alıcı terimleri soldan sağa işler; ilk eşleşen terim sonucu belirler (RFC 7208 §4.6.2). Aşağıdaki kayıt sırayla şunu söyler: 203.0.113.25 adresi yetkili, alan adının MX sunucuları yetkili, Google'ın listesindekiler yetkili, geri kalan her şey softfail.

v=spf1 ip4:203.0.113.25 mx include:_spf.google.com ~all

Niteleyici (qualifier) eşleşince verilecek sonucu seçer: + pass (yazılmazsa varsayılan; mx ile +mx aynıdır), - fail, ~ softfail, ? neutral.

include adı yanıltıcıdır: dahil edilen kaydın yalnızca "eşleşti mi" sonucu kullanılır. O kaydın sonundaki -all ya da ~all sizin politikanızı belirlemez (RFC 7208 §5.2). Örneğin Microsoft'un spf.protection.outlook.com kaydı -all ile biter; gönderen adres orada yoksa include "eşleşmedi" sayılır ve sizin kaydınızdaki sonraki terimler değerlendirilir. Dahil edilen adda SPF kaydı yoksa sonuç permerror olur.

Hiçbir terim eşleşmezse ve redirect yoksa sonuç neutral olur; RFC kaydı açıkça all ya da redirect ile bitirmenizi önerir (§4.7). all'dan sonraki terimler hiç denenmez (§5.1).

İkisi de listede olmayan sunuculara uygulanır; fark verilen sonuçtadır: -all fail, ~all softfail üretir. RFC 7208, alıcının yalnızca softfail'e dayanarak iletiyi reddetmemesini ister (§8.5); fail ise açık bir "yetkisiz" ifadesidir ve alıcı iletiyi reddedebilir (§8.4).

Sağlayıcılar farklı öneriyor. Google ~all önerir: -all ile SPF'den geçmeyen iletilerin reddedilme olasılığı artar ve reddedilen iletilerden kaydınızdaki eksikleri bulamazsınız; Google göndericileri bulmak için DMARC raporlarına bakmanızı söyler. Microsoft, DKIM ve DMARC de kurulacağı için Microsoft 365 alan adlarında -all önerir. Tüm göndericilerinizi bilmiyorsanız ~all ile başlayın.

+all herkese izin verir, ?all karar vermez; RFC neutral sonucunun "none" ile aynı işlenmesini zorunlu kılar (§8.2), yani ?all SPF yokmuş gibidir. Raporumuz +all'ı hata, ?all'ı uyarı sayar.

E-posta göndermeyen alan adları için kayıt v=spf1 -all'dır (RFC 7208 §10.1.2). IANA'nın belgeleme için ayırdığı example.com bunu uygular (26 Ekim 2026):

$ dig +short TXT example.com | grep spf1
"v=spf1 -all"

Aynı alan adına iki v=spf1 kaydı eklerseniz alıcı hangisini seçeceğini bilemez ve permerror verir (RFC 7208 §3.2, §4.5). Yeni bir servis eklerken ikinci kayıt oluşturmayın; terimleri tek kayıtta toplayın ve yalnızca sona bir all bırakın. Önce (iki kayıt, permerror):

v=spf1 include:_spf.google.com ~all
v=spf1 ip4:203.0.113.25 ~all

Sonra (tek kayıt):

v=spf1 ip4:203.0.113.25 include:_spf.google.com ~all

Aynı adda site doğrulama kodları gibi başka amaçlı TXT kayıtları da bulunabilir; yalnızca v=spf1 ile başlayanlar SPF sayılır. google.com adında 26 Ekim 2026'da 17 TXT kaydı vardı ve yalnızca biri SPF'ydi:

$ dig +short TXT google.com | wc -l
17
$ dig +short TXT google.com | grep -c '^"v=spf1'
1

Alıcı her denetimden yedi sonuçtan birini çıkarır (RFC 7208 §2.6). Sonuca ne yapacağı alıcının kendi politikasına bağlıdır (§8).

permerror'un tipik nedenleri: iki SPF kaydı, 10 aramanın aşılması, sözdizimi hatası, ikiden fazla boş arama ve include edilen adda SPF kaydı olmaması. Sonucu alıcının başlıklarında görürsünüz; RFC 7208 §9.2'deki biçimle (örnek):

Authentication-Results: mx.ornek.net; spf=pass smtp.mailfrom=ornek.com

Buradaki smtp.mailfrom, SPF'nin denetlediği zarf göndericisidir.

RFC 7208 §4.6.4'e göre DNS sorgusu gerektiren terimler (include, a, mx, ptr, exists ve redirect) bir değerlendirmede toplam 10'u geçemez; 11'incide sonuç permerror olur. ip4, ip6, all ve exp sayılmaz. Sayaç tek ve geneldir: include ile açılan kayıtlardaki terimler de sizin sayacınıza girer (§4.1).

Bu yüzden "en çok 10 include" demek yanıltır: Microsoft'un belgesinin vurguladığı gibi 10'dan az include, 10'dan az arama demek değildir; Google'ın belgesi de iç içe aramaların sayıldığını söyler. Alıcı eşleşmede durduğu için bazı iletiler sınıra hiç takılmayabilir; yine de gönderen IP'yi siz seçemezsiniz, kaydın tamamını 10'un altında tutun.

Bir zinciri elle izleyelim. google.com'un kaydında tek bir include var; içindeki terimleri sayıyoruz (26 Ekim 2026, 19:25 UTC; çıktı zamanla değişebilir):

$ dig +short TXT google.com | grep spf1
"v=spf1 include:_spf.google.com ~all"
$ dig +short TXT _spf.google.com | grep -Eo 'ip[46]:|include:|redirect=' | sort | uniq -c
   2 ip4:
   6 ip6:

_spf.google.com içinde yalnızca 2 ip4 ve 6 ip6 var, başka include ya da redirect yok: toplam 1 arama, yani 1 / 10. E-posta güvenliği kartımız bu alan adı için "1 / 10 DNS araması · ~all" gösterir.

Raporumuzdaki "N / 10 DNS araması" böyle bulunur: denetim kaydın tüm terimlerini ve include/redirect zincirini baştan sona gezip sınıra sayılan altı terimi toplar. Alıcı gibi eşleşmede durmaz; bu yüzden gerçek bir iletide harcanan arama sayıdan az olabilir. Sayı 10'u aşarsa "Düzeltilmesi gerekenler" bölümüne "SPF 10 DNS arama sınırını aşıyor" hatası eklenir. Denetim boş aramaları saymaz.

Boş arama (void lookup), yanıtı "ad yok" (NXDOMAIN) ya da "ad var ama o türde kayıt yok" (NOERROR, sıfır yanıt) olan aramadır. RFC boş aramaları ikiyle sınırlamayı önerir; sınır aşılırsa sonuç permerror olur (§4.6.4, §11.1). Silinmiş ya da yanlış yazılmış bir a:, mx: veya exists: hedefi böyle bir arama üretir. include ile bakılan adda SPF kaydı yoksa tek başına permerror alırsınız (§5.2).

$ dig +noall +comments TXT yok.ornek.invalid | grep -Eo 'status: [A-Z]+'
status: NXDOMAIN

Değerler, sağlayıcıların yönetici belgelerinden 26 Ekim 2026'da alındı. Kayda adres değil include adı yazdığınız için sağlayıcı adres listesini değiştirdiğinde kaydınız güncel kalır. Google ve Microsoft'un yönetici konsollarında SPF ayarı yoktur; kaydı DNS'inizin tutulduğu yerde eklersiniz.

Google Workspace

v=spf1 include:_spf.google.com ~all

Google, yalnızca Workspace ile gönderiyorsanız bu satırı olduğu gibi kopyalamanızı söyler. Harcadığı arama: 1.

Microsoft 365

v=spf1 include:spf.protection.outlook.com -all

Bu kayıt dünya geneli ve GCC bulutları içindir; GCC High ile DoD için include:spf.protection.office365.us, 21Vianet için include:spf.protection.partner.outlook.cn kullanılır. Microsoft bu include'un düzleştirilmemesini söyler, çünkü adresleri sık değişir. Harcadığı arama: 1.

Yandex 360

v=spf1 redirect=_spf.yandex.net

Yalnızca Yandex sunucularından gönderiyorsanız Yandex'in belgesi bunu verir. Başka sunucularınız da varsa belgedeki biçim şudur (IP-1, IP-2, IP-3 kendi adresleriniz):

v=spf1 ip4:IP-1 ip4:IP-2 ip4:IP-3 include:_spf.yandex.net ~all

Alan adını Yandex sunucularına devrettiyseniz kayıt otomatik oluşur. Harcadığı arama: 8. Sayımlar (26 Ekim 2026, 19:25 UTC; çıktı zamanla değişebilir):

$ dig +short TXT spf.protection.outlook.com | grep -Eo 'ip[46]:|include:|redirect=' | sort | uniq -c
   6 ip4:
   5 ip6:
$ dig +short TXT _spf.yandex.net
"v=spf1 redirect=_spf.yandex.ru"
$ dig +short TXT _spf.yandex.ru
"v=spf1 include:_spf-ipv6.yandex.ru include:_spf-ipv4-yc.yandex.ru include:_spf-ipv4-yc-a.yandex.ru include:_spf-ipv4-yc-b.yandex.ru include:_spf-ipv4-yc-d.yandex.ru include:_spf-ipv4-x.yandex.ru ~all"
$ for n in ipv6 ipv4-yc ipv4-yc-a ipv4-yc-b ipv4-yc-d ipv4-x; do dig +short TXT _spf-$n.yandex.ru; done | grep -Eo 'ip[46]:|include:|redirect=' | sort | uniq -c
  19 ip4:
   5 ip6:

Microsoft'un kaydında include yok: 1 arama. Yandex'te sizin satırınız 1, _spf.yandex.net içindeki redirect 1, _spf.yandex.ru içindeki altı include 6 arama eder; o altı hedefte yalnızca ip4 ve ip6 var. Toplam 8, yani sınırın büyük kısmı.

SPF kaydını DNS'in tutulduğu yerde eklersiniz: hosting paneli, alan adı sağlayıcısı ya da Cloudflare gibi bir DNS hizmeti. Alan adınızın DNS raporunda "Düzeltilmesi gerekenler" bölümünde, SPF bulgusunun altında "Nasıl eklenir?" ("Nasıl değiştirilir?") bloğu açılır: cPanel ve DirectAdmin'de hangi menüye girileceği, hangi alana ne yazılacağı ve kopyala düğmeleri. Blok yalnızca raporun hazır kayıt önerebildiği bulgularda çıkar (SPF yok, +all, ?all, all eksik); iki kayıt, 10 sınırı ve ptr bulgularında kaydı elle düzeltirsiniz.

SPF yokken önerilen v=spf1 mx ~all yalnızca bir başlangıçtır; yukarıdaki sağlayıcı değerlerini ve kendi sunucularınızı yazın. Kayıt alanlarında şunlara dikkat edin:

• Tür: TXT (DNS kayıt türleri). RFC 7208 ayrı SPF kayıt türünü (99) kullanımdan kaldırdı (§3.1, §14.1); panel önerse de kullanmayın.
• Ad: kök alan adı için @; bazı paneller alan adının tamamını ister (ornek.com.). Alt alan adı için o adın kendisi: bulten ya da panelin biçimine göre bulten.ornek.com.
• Tırnak: Bölge dosyasında metin tırnak içinde yazılır (RFC 1035 §5.1), ama "Nasıl eklenir?" adımları cPanel ve DirectAdmin'de tırnak yazmamanızı söyler: tırnağı siz de eklerseniz karakter kaydın parçası olur, kayıt v=spf1 ile başlamaz ve alıcı onu SPF saymaz (RFC 7208 §4.5). Panel açıkça tırnak istiyorsa ekleyin; Google'ın belgesi de böyle sağlayıcılar olduğunu söyler.
• TTL ve süre: Microsoft en az 3600 saniye önerir; Yandex, TTL zorunluysa 21600 yazmanızı söyler. Google SPF'nin çalışmasının 48, Yandex yayılmanın 72 saati bulabileceğini belirtir.

255 bayt kuralı. Bir metin dizgesi (character-string) en çok 255 bayt olabilir (RFC 1035 §3.3). Daha uzun değer birden çok tırnaklı dizgeye bölünür ve alıcı bunları araya boşluk koymadan birleştirir (RFC 7208 §3.3); bu yüzden bölme noktasındaki boşluğu dizgelerden birinin sonuna koyun, yoksa iki terim yapışır ve kayıt permerror verir. Örnek kısa tutuldu; gerçekte bölme 255. baytta yapılır:

ornek.com.  3600  IN  TXT  "v=spf1 ip4:192.0.2.0/25 ip4:192.0.2.128/25 " "ip4:198.51.100.0/24 include:_spf.google.com ~all"

Kaydı doğrulamak

ornek.com yerine kendi alan adınızı yazın; yayımlanmış kayıt tek bir v=spf1 satırı döndürür:

$ dig +short TXT ornek.com | grep spf1

dig yoksa (Windows) nslookup -type=TXT ornek.com aynı kayıtları listeler. Geçerliliği, 10 sınırını ve include zincirini e-posta güvenliği aracımız tek sorguda gösterir: durum etiketi (Geçerli, Zayıf, Hatalı, Yok), kayıt, "N / 10 DNS araması" ve zincir. Son olarak kendinize bir test iletisi gönderip alıcıdaki başlıkta spf=pass görün.

Yandex, Google ve Microsoft include'larını tek kayıtta toplarsanız 8 + 1 + 1 = 10 arama harcarsınız; kayıt tam sınırdadır:

v=spf1 include:_spf.yandex.net include:_spf.google.com include:spf.protection.outlook.com ~all

Bu kaydı, ölçtüğümüz kayıtlarla kurduğumuz bir deneme bölgesinde denetimimizden geçirdik: "10 / 10 DNS araması", durum Geçerli. Sonuna mx eklenince "11 / 10" olur ve "SPF 10 DNS arama sınırını aşıyor" hatası çıkar. Sırayla şunları deneyin:

1. Kullanılmayanı silin. Google, artık ileti göndermeyen üçüncü tarafların include'larını ve yinelenen terimleri silmenizi söyler. Hizmet taşıdıysanız eski sağlayıcıyı çıkarın; Yandex'ten ayrılmak 8 aramayı geri kazandırır.
2. Include'un gerekli olup olmadığına bakın. SPF, iletideki Return-Path alan adının kaydına bakar. Servisin gönderdiği iletide Return-Path servisin kendi alan adıysa o ileti için sizin kaydınız sorgulanmaz; sizin alan adınızsa include gereklidir. Silmeden önce servisin belgesine bakın.
3. Servisleri alt alan adlarına bölün. Her ad kendi 10 aramalık bütçesine sahiptir (Microsoft). Toplu e-posta gibi servisleri bulten.ornek.com gibi bir alt alan adından gönderip o ada ayrı SPF kaydı yazın; Microsoft, denetiminizde olmayan servisler için alt alan adını ana alan adının itibarını korumak amacıyla önerir. Servisin iletide bu alt alan adını kullanması gerekir; belgesine bakın.
4. Kendi sunucularınızı ip4/ip6 ile yazın. Bu terimler arama harcamaz. RFC 7208 §10.1.2: adresler sık değişmiyorsa ip4/ip6, a'dan; a da mx'ten daha az kaynak harcar.
5. Son çare: düzleştirme (flattening). Include'ları sağlayıcının yayımladığı IP aralıklarıyla değiştirirsiniz. Microsoft bunu yalnızca sağlayıcının sabit ve belgelenmiş adresleri varsa ve diğer yollar (alt alan adı, servis sayısını azaltma) uygulanamıyorsa uygun bulur.

Düzleştirmenin iki riski var. Birincisi eskime: sağlayıcı adres eklerse kaydınız bunları içermez ve o adreslerden gelen ileti SPF'den geçmez. Microsoft, değiştirdiğiniz include'ları ve tarihini not etmenizi, sağlayıcının belgesini izlemenizi, en az üç ayda bir gözden geçirmenizi ve her değişiklikten sonra denemenizi söyler. Adres listesinin değişip değişmediğini şöyle izleyebilirsiniz (hedef olarak düzleştirdiğiniz include'un adını yazın):

$ dig +short TXT _spf.google.com | tr ' ' '\n' | grep -E '^ip[46]:' | sort > bugun.txt
$ wc -l bugun.txt
       8 bugun.txt

Bir sonraki ay komutu başka bir dosyaya yazıp diff ile karşılaştırın. İkinci risk boyuttur: ip4/ip6 listeleri uzundur. 26 Ekim 2026'da Yandex'in 24 adresini (19 ip4, 5 ip6) v=spf1 … ~all içinde art arda yazınca 534 bayt, üç sağlayıcınınkini birlikte yazınca 952 bayt çıktı; include'lu kayıt ise 94 bayttır:

$ printf '%s' 'v=spf1 include:_spf.yandex.net include:_spf.google.com include:spf.protection.outlook.com ~all' | wc -c
94

255 baytı aşan değer bölünür (255 bayt kuralı). RFC 7208 §3.4, yanıtın 512 baytlık UDP paketine sığması için DNS adı ve aynı türdeki tüm kayıtlarla birlikte 450 baytın altında kalmasını önerir; sığmayan kayıt bazı doğrulayıcılarca sessizce yok sayılabilir.

• Servisi unutmak. İletişim formu, bülten servisi, muhasebe ya da müşteri yönetimi yazılımı gibi her gönderici kayıtta olmalı; kayıtta olmayan göndericinin iletileri daha çok spam olarak işaretlenir (Google). Google, kaydı yazmadan önce web sunucularını, şirket içi ve hosting sağlayıcınızın posta sunucularını, çıkış geçitlerini ve iletişim formları gibi otomatik gönderenleri listelemenizi söyler.
• redirect= ile all'ı birlikte yazmak. Kayıtta all varsa redirect yok sayılır (RFC 7208 §6.1; Google'ın belgesi de aynısını söyler). Yandex'in yalnızca redirect içeren kaydının sonuna ~all eklerseniz hiçbir terim eşleşmez ve Yandex sunucularından gelen ileti de softfail alır. İkisinden birini kullanın.
• Yazım hataları. include: yerine include= yazarsanız terim bilinmeyen bir değiştirici (modifier) sayılıp sessizce yok sayılır: include çalışmaz ama hata da görünmez (RFC 7208 §6). İki nokta üst üste sonrasına boşluk koyarsanız kayıt sözdizimi hatasıyla permerror verir (§4.6). Microsoft'un belgesi bu iki yazımı yaygın hatalar arasında sayar.
• Alt alan adlarını kapsadığını sanmak. Kök alan adındaki kayıt bulten.ornek.com için geçerli değildir; her alt alan adı kendi kaydını ister (Google ve Microsoft belgeleri). E-posta göndermeyen adlara v=spf1 -all yazın.
• ptr kullanmak. RFC 7208 §5.5 bu mekanizmanın yayımlanmamasını söyler: yavaştır, DNS hatalarında güvenilmezdir. Raporumuz uyarı verir; yerine ip4, ip6 ya da include yazın.
• SPF'yi yeterli saymak. Yönlendirilen iletide bağlanan IP, yönlendiren sunucunun IP'si olur ve SPF başarısız olabilir (RFC 7208 §10.2); e-posta listeleri de genellikle zarf adresini yeniden yazar (§2.2, §10.3). DMARC, SPF ya da DKIM'den birinin hizalı geçmesini yeterli sayar (RFC 9989 §1), bu yüzden ikisini birlikte kurun. İletileriniz yine spam'e düşüyorsa kontrol listesine bakın.