Popüler araçlar

Tema

SPF Kaydı Sorgulama

SPF kaydı sorgulama ve SPF sorgulama için: bir alan adının SPF kaydını alıcı e-posta sunucuları gibi kontrol edin. Her include kendi DNS sorgu maliyetiyle, 10 sınırına karşı toplam sayıyla, void sorgularla ve herhangi bir gönderen IP için sonucu belirleyen terimle birlikte gösterilir.

Kaynaklar: alan adının TXT kayıtları ve her include, Google Public DNS üzerinden (arkasında Cloudflare 1.1.1.1) · RFC 7208 check_host, sunucumuzda çalıştırılır · hiçbir şey saklanmaz

Tam olarak yazdığınız ad sorgulanır: SPF'de miras yoktur, bu yüzden mail.example.com'un kendi kaydı olmalıdır.

Deneyin

SPF kaydı nedir?

SPF kaydı, bir alan adı adına e-posta göndermesine izin verilen sunucuları listeleyen bir TXT kaydıdır. v=spf1 ile başlar, ardından göndericileri terim terim sayar ve alıcıların diğer herkese ne yapması gerektiğini söyleyen bir bitişle sona erer (RFC 7208, Nisan 2014, hâlâ geçerli standart).

Alıcılar onu, bağlanan sunucunun adresine ve zarf göndericisindeki alan adına, yani MAIL FROM veya Return-Path'e göre kontrol eder; okuyucunun gördüğü From: satırına göre değil. SPF'yi From: ile ilişkilendirmek DMARC'ın işidir.

Bir kayıt yalnızca durduğu adı kapsar: SPF'de miras yoktur, bu yüzden mail.example.com'un kendi kaydı olmalıdır. E-posta göndermeyen bir alan adı v=spf1 -all yayımlamalıdır.

Terim terim bir SPF kaydıgoogle.com · TXT · 24 Ekim 2026 tarihinde kaydedildi · TTL 5 dakika
v=spf1Sürüminclude:_spf.google.comMekanizma · 1 sorgu~allNiteleyici ~ · all mekanizması

Include _spf.google.com adını gösteriyor · 8 aralık, başka sorgu yok

ip4:74.125.0.0/16ip4:209.85.128.0/17ip6:2001:4860:4864::/56ip6:2404:6800:4864::/56ip6:2607:f8b0:4864::/56ip6:2800:3f0:4864::/56ip6:2a00:1450:4864::/56ip6:2c0f:fb50:4864::/56~all

SürümTam olarak v=spf1, en başta: başka şekilde başlayan bir kayıt SPF kaydı değildir.
Mekanizmalarinclude, a, mx, ip4, ip6, exists, ptr ve all, soldan sağa denenir: ilk eşleşme karar verir.
Niteleyiciler+ pass (varsayılan), - fail, ~ softfail, ? neutral; bir mekanizmanın önüne yazılır.
Değiştiricilerredirect= kontrolü başka bir kayda devreder; exp= bir fail sonucunu açıklar.
google.com alan adının kaydının tamamı üç terimden oluşur: bir alıcı include'u alır, gönderen IP'yi onun aralıklarıyla eşleştirir veya ~all'a ulaşır. 24 Ekim 2026 tarihinde Google Public DNS üzerinden kaydedildi.

SPF kaydı nasıl sorgulanır

Yukarıya bir alan adı yazın; sorgu aracı TXT kayıtlarını okur, v=spf1 ile başlayanı seçer, ardından bir alıcı sunucunun yapacağı gibi her include ve redirect'i izler ve her DNS sorgusunu sayar.

Elle yapmak için TXT kayıtlarını isteyin: dig TXT example.com +short veya nslookup -type=TXT example.com. Yanıtta o addaki tüm TXT kayıtları bulunur; SPF kaydı v=spf1 ile başlayandır ve uzun bir kayıt, SPF'nin boşluksuz birleştirdiği birkaç tırnaklı dize olarak gelir. Her include bir sorgu daha demektir ve onları kendiniz saymanız gerekir.

Belirli bir sunucunun gönderip gönderemeyeceğini görmek için IP test et sekmesine geçin: aynı kontrolü o adres için çalıştırır ve eşleşen terimi gösterir.

dig TXT example.com +short

Çözümleyicinizdeki haliyle o addaki tüm TXT kayıtları; SPF kaydı v=spf1 ile başlayandır. Her include için yeniden çalıştırın.

dig'in gösterdikleri ve göstermediklerigithub.com · dig TXT · 24 Ekim 2026 tarihinde kaydedildi
Terminal24 TXT kaydı arasında 1'i
$ dig TXT github.com @dns1.p08.nsone.net +norec +noall +answer
github.com.  300  IN  TXT  "v=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com include:_netblocks.google.com include:_netblocks2.google.com include:mail.zendesk.com include:_spf.salesforce.com include:servers.mcsv.net include:mktomail.com include:sendgrid.net ip4:62.253.2" "27.114 ip4:166.78.69.169 ip4:166.78.69.170 ip4:166.78.71.131 ~all"

# ardından her include, tek tek sorgu olarak:
$ dig +short TXT _spf.salesforce.com
"v=spf1 exists:%{i}._spf.mta.salesforce.com -all"
  1. Bir kayıt v=spf1 ile başlıyor. Yanındaki 23 başka TXT kaydı (doğrulama belirteçleri ve benzerleri), yanıtın boyutu dışında SPF için önemli değil.
  2. 2 dize, boşluksuz birleştirilir. 255 baytlık bölünme ip4:62.253.227.114 içine denk geliyor: alıcılar dizeleri yeniden birleştirir, bu yüzden sorun yok.
  3. TTL 5 dakika. Bir değişiklikten sonra çözümleyicilerin bu kopyayı ne kadar tutabileceği. Bölgenin kendi sunucusu 5 dakika diyor; çözümleyici kendi kopyasından kalan süreyi gösterir.
  4. Her include ayrı bir sorgudur. github.com alan adının kaydını izlemek, iç içe olanlar dahil 10 sorgu gerektiriyor. dig bir seferde bir ad gösterir: 10 sınırına kadar sayımı kendiniz toplamalısınız.
Windows
$ nslookup -type=TXT github.com 8.8.8.8
PowerShell
# o addaki tüm TXT kayıtları, Google Public DNS'ten
PS> Resolve-DnsName -Name github.com -Type TXT -Server 8.8.8.8
Bu sayfa
/tr/spf-checker?domain=github.com
github.com alan adının kendi ad sunucusundan TXT yanıtı: SPF kaydı, alan adının diğer TXT kayıtları arasında, boşluksuz birleştirilen iki dize olarak geliyor.

Sonucu okumak: include ağacı

Karar, kaydın listelemediği bir gönderici için alıcıların ne aldığını söyler: bitişiyle birlikte geçerli (~all için softfail, -all için fail), nedeniyle birlikte bir permerror ya da DNS yanıt vermediyse "kontrol edilemedi".

Lacivert sütun sorgu bütçesidir: her DNS sorgusu için bir hücre, onu harcayan include'a göre renklendirilmiş, 10'a karşı toplam sayı ve void sorgular halka olarak. 10.'dan sonra hücreler kırmızıya döner ve alıcıların durduğu dal işaretlenir.

Ağaç görünümü bulguları, başarısızlıklar önce, her biri RFC bölümü ve çözümüyle listeler; ardından her sorguyu bir alıcının sorduğu sırayla gösterir.

github.com için SPF kaydı sorgulama: 10 DNS sorgusunun 10'u, bir void, sorgu bütçesinde her include'un maliyetigithub.com için SPF kaydı sorgulama: 10 DNS sorgusunun 10'u, bir void, sorgu bütçesinde her include'un maliyetiKararKaydın listelemediği bir gönderici için alıcıların ne aldığı ve buna karar veren bitiş.Terim terim kayıtHer terim türüne göre renklendirilmiş; bir include sahibinin işaretini ve kendi sorgu maliyetini taşır.BulgularTek kayıt, geçerli sözdizimi, sorgular, void'ler, bitiş, ptr, DMARC: başarısızlıklar önce, her biri kendi çözümüyle.Sorgu bütçesiHer DNS sorgusu bir hücre olarak, onu harcayan include'a göre renklendirilmiş, 10 sınırına karşı.Her include'un maliyetiHer include için bir dal: kendi hücreleri, içine yerleştirdikleri ve toplam sayı.Void sorgularBoş dönen sorgular için halkalar; üçüncüsü kontrolü bitirir.
github.com için bir SPF sorgusu: karar, terimlerine bölünmüş kayıt, bulgular ve her include'un kendi maliyetini gösteren sorgu bütçesi. Her bölümün neyi gösterdiğini görmek için bir numara seçin.

10 sorgu sınırı ve "çok fazla DNS sorgusu" (permerror)

Alıcılar DNS sorgusu gerektiren her terimi (include, a, mx, ptr, exists ve redirect) iç içe tüm include'lar boyunca sayar ve 10'da durur. 11. sorgu permerror verir (RFC 7208 §4.6.4). ip4, ip6, all ve exp hiçbir şeye mal olmaz.

Bu bir fail değil, permerror'dır: alıcının onunla ne yapacağı kendi seçimidir, ancak DMARC altında permerror hiçbir zaman pass sayılmaz. Kontrol ilk eşleşmede durduğu için, sınırı aşan bir kayıt erken listelenen göndericiler için yine pass verir ve yalnızca geç listelenenler için bozulur.

Maliyet include'ların içinde saklanır: include:_netblocks.mimecast.com tek başına 9, Yandex 360 8, Freshdesk 7, Mailgun 5 harcar. Google ve Microsoft 365 include'ları birer sorguya mal olur. 10'un altına inmek için artık kullanmadığınız göndericileri çıkarın ve toplu gönderim yapan birini kendi kaydı olan bir alt alan adına taşıyın.

10 sorguyu kim harcıyorMaliyetler 24 Ekim 2026 tarihinde ölçüldü · gerçek include'lardan oluşan uydurma bir kayıt

v=spf1 include:spf.protection.outlook.com include:_netblocks.mimecast.com include:mailgun.org include:sendgrid.net -all

17 sorgu gerekiyor
İlk 10 sorgu içinde listelenen: passMicrosoft 3651Mimecast2–10
10. sorgudan sonra listelenen: permerrorMailgun11–15Twilio SendGrid16–17

Diğer herkes de kaydın -all fail sonucunu değil, permerror alır: alıcılar oraya ulaşmadan durur.

Bir include'un maliyetiHer sağlayıcının kendi belgelediği include · 24 Ekim 2026 tarihinde ölçüldü
  • _netblocks.mimecast.comMimecast9 sorgu
  • _spf.yandex.netYandex 3608 sorgu
  • email.freshdesk.comFreshdesk7 sorgu
  • mailgun.orgMailgun5 sorgu
  • icloud.comiCloud+5 sorgu
  • spf.titan.emailTitan Email4 sorgu
  • secureserver.netGoDaddy3 sorgu
  • _spf.google.comGoogle Workspace1 sorgu
  • spf.protection.outlook.comMicrosoft 3651 sorgu
Sorgular RFC 7208 §4.6.4'ün saydığı gibi sayıldı: include'un kendisi artı içindeki her şey. Bu sayfadaki canlı sayılar her zaman bu tablodan değil, izlemeden gelir.

Void sorgu nedir?

Void sorgu, hiç kayıt döndürmeyen bir sorgudur: ad mevcut değildir (NXDOMAIN) ya da mevcuttur ancak istenen kayıt yoktur. Alıcıların ikisine izin vermesi gerekir; üçüncüsü permerror'dır (RFC 7208 §4.6.4).

Artık var olmayan bir host'a işaret eden a:old.example.com gibi bir terim tek başına hata değildir: yalnızca eşleşmez ve bir void sayılır. Salesforce'un listelemediği her gönderici için exists:%{i}._spf.mta.salesforce.com da öyledir; include sırasının önemli olmasının nedeni budur.

Bir sunucu hatası ya da zaman aşımı void değildir: temperror'dır ve alıcılar genellikle sonra yeniden dener.

Dört yanıt, üç sonuçRFC 7208 §4.6.4

salesforce.com alan adının kendi kaydı, 192.0.2.1 için, 24 Ekim 2026 tarihinde kaydedildi

v=spf1 include:_spf.google.com include:_spf.salesforce.com exists:%{i}._spf.corp.salesforce.com ~all

Void sorgular2 / 2üçüncüsü: permerror
  1. exists:%{i}._spf.mta.salesforce.com192.0.2.1._spf.mta.salesforce.com → NXDOMAIN · 3. sorgu · _spf.salesforce.com içinde
  2. exists:%{i}._spf.corp.salesforce.com192.0.2.1._spf.corp.salesforce.com → NXDOMAIN · 4. sorgu · salesforce.com içinde

Sonuç: softfail, izin verilen iki void de harcanmış

Ad var, kayıt yoka:mail.example.com, hâlâ var olan ama artık adresi bulunmayan bir ad için: yanıt yok, NOERROR. Eşleşme yok, bir void, kontrol sürer.NODATAvoid sorgu
Ad mevcut değilexists:%{i}._spf.mta.salesforce.com her gönderen IP'den bir ad oluşturur; Salesforce hizmetinin listelemediği bir adres için yanıt NXDOMAIN'dir: her seferinde bir void.NXDOMAINvoid sorgu
Üçüncü voidmx:shop.example.com, artık var olmayan bir ad, zaten 2 void harcandıktan sonra: alıcılar burada durur.NXDOMAINpermerror
Hiç yanıt yokinclude:_spf.vendor.example için SERVFAIL veya zaman aşımı: DNS başarısız oldu, bu yüzden hiçbir şey void sayılmaz.SERVFAILtemperror, void değil

blastmail hizmetinin include:spf.bmv.jp include'u, böyle iki exists terimiyle başlar: listelemediği bir adres için izin verilen iki void'i tek başına harcar.

Yalnızca boş yanıt void sayılır. Bir hata temperror'dır ve kontrol sonra yeniden denenir.

SPF düzleştirme: ne zaman işe yarar, ne zaman bozar

Düzleştirme, bir include'u listelediği adreslerle değiştirir; böylece kayıt daha az sorguya mal olur. Nadiren değişen aralıklar için işe yarar; bir sağlayıcı hiç kopyalamadığınız bir sunucu eklediğinde ters teper: o sunucudan gelen e-posta SPF'yi geçemez.

Microsoft include:spf.protection.outlook.com düzleştirilmemesini söyler; ayrıca Google ve Microsoft include'ları zaten birer sorguya mal olur. Toplu gönderim yapan birini news.example.com gibi bir alt alan adına taşımak ona kendi kaydını ve kendi 10 sorgusunu verir.

Düzleştirilmiş bir includemailgun.org · 24 Ekim 2026 tarihinde kaydedildi

Önce

include:mailgun.org

Sorgular
5
Alınan kayıtlar
5
Kaydınızdaki bayt
19
Mailgun bir aralığı değiştirir
hemen alınır

Sonra

ip4:159.135.224.0/20 ip4:69.72.32.0/20 ip4:204.220.90.0/23 ip4:204.220.92.0/22 +18 tane daha

Sorgular
0
Kaydınızdaki bayt
450
Gereken TXT dizeleri
2
Mailgun bir aralığı değiştirir
kopyanız eskimiş

Eski kopya riski. Bugün 22 aralık kopyalıyorsunuz; Mailgun bir tane eklediğinde, biri fark edip kaydı güncelleyene kadar ondan gelen e-posta SPF'yi geçemez.

  1. kopyalandı
  2. Mailgun bir aralık ekler
  3. ondan gelen e-posta SPF'yi geçemez
Düzleştirin yalnızca nadiren değişen aralıkları, örneğin kendi sunucularınızın adreslerini.
Düzleştirmeyin Microsoft 365: Microsoft gönderim adreslerinin sık değiştiğini söylüyor, bu yüzden include'u koruyun.
Tercih edin her toplu göndericiye bir alt alan adı: her biri kendi kaydını ve 10 sorgusunu alır.
Düzleştirme sorguları bakım yüküyle takas eder: kopya, sağlayıcı aralıklarını değiştirene kadar doğrudur.

~all ve -all (ve DMARC)

Son terim, listede olmayan her gönderene ne olacağını söyler. -all fail'dir, en güçlü ifadedir; ~all softfail'dir, "büyük olasılıkla değil"; ?all neutral'dır ve alıcılar onu hiç SPF yokmuş gibi ele alır; +all herkesin geçmesine izin verir ve asla yayımlanmamalıdır.

~all ile -all arasında yanlış bir cevap yoktur. Google, Google Workspace için ~all; Microsoft ise Microsoft 365 için -all önerir. DMARC uygulama modundayken ~all, DMARC'ın DKIM'e göre karar vermesini sağlar: bazı alıcılar, DMARC geçen bir DKIM imzasını görmeden önce -all nedeniyle reddeder; bu yüzden yönlendirilen e-postalar geri dönebilir (RFC 9989 §7.1).

Dört bitişRFC 7208 §2.6 · RFC 9989 §7.1
~all
softfail“Büyük olasılıkla yetkili değil”: alıcılar yalnızca buna dayanarak reddetmemelidir.
BelgeleyenGoogle WorkspaceMailguniCloud+
-all
failEn güçlü ifade: bir alıcı iletiyi SMTP aşamasında reddedebilir.
BelgeleyenMicrosoft 365ZendeskGoDaddy
?all
neutralHiçbir ifade yok: alıcılar onu tıpkı SPF yokmuş gibi ele alır.
BelgeleyenFastmailIONOS ve OVHcloud include'ları da ?all ile biter: orada zararsızdır, çünkü yalnızca bir include içindeki pass eşleşir.
+all
herkes için passİnternet'teki her sunucu alan adı adına geçer.
Asla yayımlamayın

DMARC p=reject iken -all

  1. SPF: fail
  2. SMTP'de reddedildi
  3. DKIM hiç kontrol edilmedi

Bazı alıcılar önce SPF'ye göre davranır; bu yüzden geçerli bir DKIM imzası olan yönlendirilmiş bir ileti DMARC çalışmadan reddedilebilir ve kayıp DMARC raporlarında hiç görünmez.

DMARC p=reject iken ~all

  1. SPF: softfail
  2. DMARC DKIM'i kontrol eder
  3. hizalı DKIM: pass

DMARC karar verir. Ancak DKIM imzası yoksa Microsoft, ~all başarısızlıkları için DMARC'ın fiilen yok sayıldığını söyler ve bu nedenle -all önerir.

~all de -all de geçerli seçimlerdir; ?all hiçbir şey söylemez ve +all herkesin geçmesine izin verir.

Sık görülen SPF hataları ve çözümleri

Bozuk kayıtların çoğu üç hatadan gelir: ikisini birleştirmek yerine ilkinin yanına eklenen ikinci bir SPF kaydı, artık kullanılmayan bir sağlayıcının include'u ve belgelerden kopyalanıp içinde yazım hatası olan bir değer.

Sağlayıcı belgelerinin bir kısmı bunları kendisi yazıyor: Mimecast –all değerini en dash ile, Postmark include: spf.mtasv.net değerini boşlukla yazıyor, Twilio SendGrid var olmayan bir aaaa mekanizması listeliyor. Herhangi bir sözdizimi hatası tüm kaydı permerror yapar. Alan adının sonundaki nokta ise geçerlidir.

Sekiz kayıt, sekiz sonuçGerçek hataların uydurma örnekleri

İki SPF kaydıpermerror

v=spf1 include:_spf.google.com ~allv=spf1 include:sendgrid.net ~all

Çözüm: tek kayıtta birleştirin: tek v=spf1, her include bir kez, tek bitiş.

Sorgu sınırı (10) aşılıyorpermerror

v=spf1 include:_netblocks.mimecast.com include:mailgun.org -all

14 sorgu

Çözüm: artık kullanmadığınız göndericileri çıkarın ya da toplu göndericiye kendi alt alan adını verin.

Üçüncü bir void sorgupermerror

v=spf1 a:old.example.com mx:gone.example.net exists:%{i}.spf.example.org -all

3 void

Çözüm: artık var olmayan adlara giden terimleri silin ve exists include'larını en sona koyun.

Arkasında SPF kaydı olmayan bir includepermerror

v=spf1 include:spf.retired-vendor.example -all

Çözüm: adı düzeltin ya da bıraktığınız sağlayıcıyı çıkarın.

–all içinde bir en dashpermerror

v=spf1 include:_netblocks.mimecast.com –all

Mimecast hizmetinin kendi belgelerinde bu şekilde yazılmış

Çözüm: düz bir tire: -all.

include: sonrasında bir boşlukpermerror

v=spf1 a mx include: spf.mtasv.net ~all

Postmark hizmetinin kendi belgelerinde bu şekilde yazılmış

Çözüm: include:spf.mtasv.net

Bir aaaa mekanizmasıpermerror

v=spf1 aaaa:example.com ~all

Twilio SendGrid hizmetinin kendi belgelerinde bu şekilde yazılmış

Çözüm: a:example.com; a zaten IPv6 gönderenlerin AAAA kayıtlarıyla da eşleşir.

Sondaki noktageçerli

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

Geçerli: RFC 7208 §7.3 bunu yayımlamamayı söyler, ancak alıcılar kabul etmek zorundadır.

Zendesk yardım sayfası ayrıca “redirect: sözdizimi destekleniyor” diyor: değiştirici redirect= biçiminde yazılır (RFC 7208 §6.1).

Her kayıt uydurma bir örnektir; hatalar alıcıların en sık gördükleridir.

Gmail, Yahoo ve Microsoft ne istiyor

Şubat 2024'ten beri Gmail ve Yahoo her göndericiden SPF veya DKIM kurmasını ister. Toplu göndericilerin ikisine de, en az p=none olan bir DMARC kaydına ve ikisinden biriyle hizalı bir From: alan adına ihtiyacı vardır. Outlook.com yüksek hacimli göndericilerden hem SPF hem DKIM ister ve 5 Mayıs 2025'ten beri ikisi olmayanları reddediyor.

Gmail'in eşiği kişisel hesaplara günde 5.000'den fazla ileti; Yahoo hiçbir eşik yayımlamıyor. SPF tek başına e-postayı hiçbir zaman "hizalı" yapmaz: MAIL FROM alan adı sağlayıcının geri dönüş (bounce) alan adı değil, sizin alan adınız olmalıdır.

Üç posta kutusu sağlayıcısının kurallarıHer sağlayıcının kendi sayfalarında okundu, 24 Ekim 2026
GmailYahooOutlook.com
Toplu gönderim eşiğiGmailkişisel Gmail hesaplarına günde 5.000 iletiden fazla, birincil alan adı başına sayılırYahooyayımlanmış yok: “Bir hacim eşiği belirtmeyeceğiz”Outlook.comgünde 5.000 adetten fazla (Microsoft'un blogu); tek bir From: alan adından 5.000 veya daha fazla (destek makalesi)
Tüm göndericilerGmailSPF veya DKIM, ayrıca ileri ve ters DNS, TLS ve %0,3 altında spam oranıYahooSPF veya DKIM, ayrıca ileri ve ters DNS ve %0,3 altında spam oranıOutlook.comkatı bir kural yok
Toplu göndericilerGmailSPF ve DKIM, DMARC (p=none yeterli), SPF veya DKIM ile hizalı From:, pazarlama e-postaları için tek tıkla abonelikten çıkmaYahooSPF ve DKIM, en az p=none olan ve geçen DMARC, SPF veya DKIM ile hizalı From:, tek tıkla abonelikten çıkmaOutlook.comSPF geçmeli ve DKIM geçmeli, en az p=none olan DMARC, SPF veya DKIM ile hizalı
YürürlükteGmail1 Şubat 2024; reddetmeler Kasım 2025 ayından itibaren hızlandıYahooŞubat 2024Outlook.com5 Mayıs 2025 (reddetme)
SPF hatası şöyle görünürGmail4.7.275.7.27YahooSPF için belgelenmemişOutlook.com550 5.7.515

Japonya: NTT docomo hizmetinin en sıkı ayarı olan 「全て拒否する」, alan adının SPF kaydının yetkilendirmediği gönderen IP'den gelen e-postayı ve hiç SPF kaydı yayımlamayan alan adlarından gelen e-postayı reddeder. docomo.ne.jp

Kaynaklarsupport.google.comsenders.yahooinc.comtechcommunity.microsoft.com

Her sağlayıcının kuralları, kendi sayfalarında 24 Ekim 2026 tarihinde belirtildiği gibi.

SPF sorgulama ile dig ve nslookup farkı

dig ve nslookup TXT kayıtlarını çözümleyicinizdeki haliyle gösterir: SPF kaydını ve o addaki diğer her şeyi. include'ları izlemez, sorguları veya void'leri saymaz, bir alıcının ne karar vereceğini söylemez.

Buradaki gibi bir SPF sorgulama aracı kaydın tamamını izler, bu yüzden sayılar bir alıcı sunucunun hesapladığıyla uyuşur. Tek bir ad için dig'i, karar için bu aracı kullanın.

SPF'ye bakmanın üç yoluHer birinin gösterdikleri
Bu araçdig TXTnslookup -type=TXT
TXT kayıtlarını gösterirBu araçEvetterimlere bölünmüşdig TXTEvetnslookup -type=TXTEvet
Uzun bir kaydın dizelerini birleştirirBu araçEvetalıcılar gibidig TXTHayırher dizeyi ayrı gösterirnslookup -type=TXTHayırher dizeyi ayrı gösterir
Her include'u izlerBu araçEvetağacın tamamıdig TXTHayırsorgu başına bir adnslookup -type=TXTHayırsorgu başına bir ad
10 sınırına kadar sorguları sayarBu araçEvetinclude başına toplam sayıdig TXTHayırellenslookup -type=TXTHayırelle
Void sorguları sayarBu araçEvetadlarıyla birliktedig TXTHayırnslookup -type=TXTHayır
İki kayıt = permerror derBu araçEvetdig TXTHayırikisini de yazdırırnslookup -type=TXTHayırikisini de yazdırır
Gönderen bir IP'yi test ederBu araçEvetcheck_host ve eşleşen terimdig TXTHayırnslookup -type=TXTHayır
Kendi çözümleyicinize sorarBu araçHayırGoogle Public DNS, sunucumuzdandig TXTEvetnslookup -type=TXTEvet
Aynı soru üç şekilde sorulmuş: dig ve nslookup kendi çözümleyicinizdekini, bu araç bir alıcının hesapladığını gösterir.

SPF sorgulama: sık sorulan sorular

SPF kaydı sorgulama nedir?

SPF kaydı sorgulama, bir alan adının SPF kaydını, yani v=spf1 ile başlayan TXT kaydını okur ve alıcı bir e-posta sunucusu gibi izler: her include ve redirect takip edilir, her DNS sorgusu 10 sınırına, her boş yanıt 2 sınırına karşı sayılır. Sonuçta listede olmayan bir gönderici için alıcıların ne aldığı, ya da permerror ve nedeni gösterilir.

Bir IP adresinin alan adım adına e-posta gönderip gönderemeyeceğini nasıl test ederim?

IP test et seçeneğini seçin, alan adını ve gönderen sunucunun IPv4 veya IPv6 adresini, isteğe bağlı olarak da MAIL FROM adresini ve HELO adını girin. Sorgu aracı o adres için check_host'u çalıştırır ve pass, fail, softfail, neutral veya permerror sonucunu, eşleşen terimi, niteleyicisini ve ona götüren include zincirini gösterir.

"SPF çok fazla DNS sorgusu" ne demek?

Kaydı kontrol etmenin RFC 7208'deki sınır olan 10'dan fazla DNS sorgusu gerektirdiği anlamına gelir. Her include, a, mx, ptr, exists ve redirect, include'ların içindekiler dahil bir sorguya mal olur. Alıcılar 11.'de permerror ile durur; bu yüzden o noktadan sonra listelenen göndericiler SPF'yi geçemez. Kullanılmayan include'ları çıkarın ya da bir göndericiyi kendi kaydı olan bir alt alan adına taşıyın.

SPF permerror nedir?

Permerror, SPF'nin "bu kayıt değerlendirilemiyor" sonucudur. 10'dan fazla DNS sorgusundan, 2'den fazla void sorgudan, aynı adda iki SPF kaydından, SPF kaydı olmayan bir adın include edilmesinden ya da bir sözdizimi hatasından kaynaklanır. Fail değildir: alıcılar onunla ne yapacaklarına kendileri karar verir, ancak DMARC altında hiçbir zaman pass sayılmaz.

SPF'de void sorgu nedir?

Void sorgu, bir SPF terimi için yapılan ve boş dönen DNS sorgusudur: ad mevcut değildir (NXDOMAIN) ya da istenen türde kaydı yoktur. RFC 7208, alıcıların ikisine izin vermesi gerektiğini söyler; üçüncüsü permerror'dır. Bir sunucu hatası veya zaman aşımı void sorgu değil, alıcıların genellikle sonra yeniden denediği bir temperror'dır.

SPF kaydım ~all ile mi yoksa -all ile mi bitmeli?

İkisi de geçerlidir. -all (fail) en güçlü ifadedir ve Microsoft onu Microsoft 365 için önerir; ~all (softfail) ise Google'ın Google Workspace için önerdiğidir. DKIM imzası ve karantina ya da reject modunda DMARC varken ~all çoğu zaman daha güvenli bitiştir, çünkü bazı alıcılar DMARC geçen bir DKIM imzasını kabul etmeden önce -all nedeniyle reddeder.

Bir alan adının iki SPF kaydı olabilir mi?

Hayır. Bir adda v=spf1 ile başlayan iki TXT kaydı varsa alıcılar birini seçemez ve kontrol, her gönderici için daha ilk sorgudan önce permerror ile biter (RFC 7208 §4.5). Bu genellikle yeni bir sağlayıcının kaydı eskisinin yanına eklendiğinde olur. İkisini tek v=spf1, her include bir kez ve tek bir bitişle tek kayıtta birleştirin.

SPF düzleştirme nedir ve kullanmalı mıyım?

Düzleştirme, include'ları listeledikleri IP aralıklarıyla değiştirir; böylece kayıt daha az DNS sorgusu gerektirir. Nadiren değişen aralıklar için işe yarar, ancak düzleştirilmiş bir kopya sağlayıcı sunucu eklediği anda eskir ve o sunuculardan gelen e-posta SPF'yi geçemez. Kullanılmayan include'ları çıkarmayı ya da toplu göndericiye kendi alt alan adını vermeyi tercih edin; Microsoft 365 include'unu asla düzleştirmeyin.

Bir alt alan adının kendi SPF kaydı olmalı mı?

Evet. SPF'de miras yoktur: bir kayıt yalnızca yayımlandığı adı kapsar; bu yüzden MAIL FROM veya HELO'da geçiyorsa mail.example.com veya news.example.com'un kendi kaydı olmalıdır. Bu, kurumsal alan adına geri dönen DMARC'tan farklıdır. E-posta göndermeyen bir alt alan adı v=spf1 -all yayımlayabilir.

SPF burada geçiyor ama Gmail'de neden başarısız oluyor?

Genellikle Gmail farklı bir alan adını ya da adresi kontrol ettiği için. SPF, MAIL FROM (Return-Path) alan adı ve bağlanan sunucunun IP'si için değerlendirilir; bu alan adı sizinki değil, sağlayıcınızın geri dönüş alan adı olabilir. Yönlendirme de SPF'yi bozar, çünkü yönlendiricinin IP'si kaydınızda yoktur. Gerçek bir iletinin Authentication-Results başlığına bakın ve o IP ile alan adını burada test edin.

SPF, DKIM ve DMARC arasındaki fark nedir?

SPF, bir alan adı adına göndermesine izin verilen sunucuları listeler ve zarf göndericisine göre kontrol edilir. DKIM her iletiyi DNS'te yayımlanan bir anahtarla imzalar; bu yüzden imza yönlendirmeden sağ çıkar. DMARC bunları okuyucunun gördüğü From: adresine bağlar: SPF veya DKIM, From: ile hizalı bir alan adı için geçerse ileti DMARC'ı geçer ve politika aksi halde ne yapılacağını söyler.

Bir SPF kaydı değişikliğinin etkili olması ne kadar sürer?

Çözümleyiciler eski kaydı tuttuğu sürece: alan adının belirlediği TTL'ye kadar (kontrol ettiğimizde google.com ve github.com için 300 saniye, microsoft.com için bir saat). Alıcılar kendi çözümleyicisine sorar, bu yüzden bir değişiklik her önbellek kopyası dolduğunda görünür. Bu araç TTL'yi alan adının kendi ad sunucusunun sunduğu haliyle gösterir; o süre geçtikten sonra yeniden kontrol edin.

İlgili e-posta ve DNS araçları