SPF Kaydı Yazma Rehberi: include, ip4 ve all Mekanizmaları

Bir SPF kaydı, alan adınız adına hangi sunucuların e-posta göndermeye yetkili olduğunu ilan eden tek satırlık bir TXT kaydıdır. Alıcı taraftaki sunucu, mektubu kabul etmeden önce bağlantının geldiği IP adresini bu listeyle karşılaştırır; IP listede yoksa mektup ya doğrudan çöpe gider ya da spam klasörüne düşer. Kulağa basit gelir ama pratikte SPF kaydı, e-posta altyapısında en çok yanlış yazılan ve en çok "neden Gmail'e girmiyoruz" sorusuna sebep olan kayıttır.

Bu rehberde SPF kaydının içindeki her parçayı tek tek açacağım: v=spf1 neden zorunlu, ip4 ile a arasındaki fark ne, include gerçekte ne yapıyor, -all mi ~all mı yazmalısınız ve kimsenin hatırlamadığı ama en sinsi tuzak olan 10 DNS sorgu limitine nasıl takılıyorsunuz. Sonunda kendi altyapınız için doğru kaydı yazabilecek ve elinizdeki kaydın neden çalışmadığını komut satırından teşhis edebilecek durumda olacaksınız.

SPF Kaydı Ne Yapar, Ne Yapmaz#

SPF (Sender Policy Framework), zarfın gönderen adresine — yani SMTP oturumundaki MAIL FROM alanına — bakar. Alıcı sunucu bu adresteki alan adını alır, o alan adının TXT kayıtlarını sorgular, v=spf1 ile başlayanı bulur ve bağlantının geldiği IP'yi kaydın içindeki mekanizmalarla eşleştirir. Eşleşme varsa sonuç pass, yoksa niteleyiciye göre fail, softfail veya neutral olur. Tüm kontrol, mektubun gövdesine hiç bakılmadan, bağlantı henüz kurulurken yapılır.

SPF'in en çok yanlış anlaşılan tarafı şudur: kullanıcının gördüğü From: başlığını korumaz. Kullanıcı Outlook'ta "kimden" sütununda [email protected] görür, ama SPF bunu değil, zarftaki MAIL FROM adresini denetler. Bir saldırgan kendi alan adıyla SPF pass alıp From: başlığına sizin adresinizi yazabilir. İkisini birbirine bağlayan mekanizma DMARC'tır; SPF tek başına sahtecilik kalkanı değil, o kalkanın bir bacağıdır. Diğer bacağı olan DKIM ve raporlama tarafını DMARC raporu nasıl okunur yazısında ele alıyorum, sahtecilik senaryolarının bütününü ise e-posta spoofing önleme rehberinde bulabilirsiniz.

İkinci sık yanılgı, SPF'in yönlendirmelerde de çalıştığını sanmaktır. Bir mektup [email protected] adresine gelip oradan otomatik olarak bir Gmail adresine iletiliyorsa, ileten sunucu artık orijinal gönderenin SPF listesinde olmayan bir makinedir ve mektup Gmail tarafında SPF fail alır. Bu yüzden klasik e-posta yönlendirmesi SPF'i kırar; çözüm SRS (Sender Rewriting Scheme) kullanmak ya da iletme yerine gerçek bir posta kutusu vermektir.

SPF Kaydının Anatomisi#

Bir SPF kaydı, boşlukla ayrılmış terimlerden oluşur ve daima v=spf1 ile başlar. Terimler soldan sağa değerlendirilir; ilk eşleşen mekanizma sonucu belirler ve kalan terimler hiç okunmaz. Bu "ilk eşleşen kazanır" davranışı, kaydınızdaki sıralamayı önemli kılar.

; Tipik bir SPF kaydı, parça parça
firmaniz.com.  3600  IN  TXT  "v=spf1 ip4:185.12.34.56 a:mail.firmaniz.com include:_spf.google.com -all"
;                              |      |                |                   |                      |
;                              |      |                |                   |                      +-- kalan her IP reddedilsin
;                              |      |                |                   +-- Google'ın yetkili IP'leri
;                              |      |                +-- mail.firmaniz.com'un A kaydındaki IP
;                              |      +-- tek bir IPv4 adresi
;                              +-- sürüm etiketi, zorunlu ve ilk sırada

Her mekanizmanın önüne bir niteleyici (qualifier) koyabilirsiniz. Hiçbir şey yazmazsanız varsayılan + yani "geç" demektir:

Yani -all yazdığınızda aslında "all mekanizmasını fail niteleyicisiyle işaretle" demiş olursunuz; all her zaman eşleştiği için bu, listedekiler dışındaki herkesi kapsar. Kaydınızda all yoksa varsayılan ?all gibi davranılır, yani politikanız hiçbir şey ifade etmez.

ip4, ip6, a ve mx Mekanizmaları#

En doğrudan mekanizma ip4'tür ve hiçbir ek DNS sorgusu üretmez. Tek bir adres ya da CIDR bloğu yazabilirsiniz:

; Tek IP
"v=spf1 ip4:185.12.34.56 -all"

; Bir /29 blok — sekiz adresin tamamı yetkili
"v=spf1 ip4:185.12.34.56/29 -all"

; IPv6 de destekleniyor, ayrı mekanizma
"v=spf1 ip4:185.12.34.56 ip6:2a01:4f8:1c1c::10 -all"

Sunucunuz IPv6 üzerinden de bağlantı kurabiliyorsa ip6 yazmayı unutmayın; Gmail gibi sağlayıcılar IPv6'yı tercih eder ve eksik ip6 yüzünden fail almak sık görülen bir durumdur. Blok yazarken kaç adresi yetkilendirdiğinizi bilmek isterseniz subnet hesaplayıcı aracıyla CIDR'ı hızlıca çözebilirsiniz.

a ve mx mekanizmaları ise dinamiktir: yazdığınız ismin A/AAAA kaydındaki ya da MX kaydının işaret ettiği makinelerin IP'lerini kabul eder. Argüman vermezseniz kaydın ait olduğu alan adı kullanılır.

; firmaniz.com'un kendi A kaydı ve MX sunucuları yetkili olsun
"v=spf1 a mx -all"

; Belirli bir hostun A kaydı
"v=spf1 a:mail.firmaniz.com -all"

Bunlar okunaklıdır ama her biri en az bir DNS sorgusu harcar ve web sunucunuzun IP'sini değiştirdiğinizde SPF kaydınızın anlamı sessizce değişir. Web sunucusu ile posta sunucusu aynı makinede değilse a mekanizmasını kaydınızdan çıkarmak, gereksiz bir IP'yi yetkilendirmemek adına doğru olur.

include Mekanizması ve 10 DNS Sorgu Limiti#

include:baskaalanadi.com, o alan adının SPF kaydını yeniden değerlendirir ve sonucu pass ise sizinkini de pass yapar. Google Workspace, Microsoft 365, Mailgun, SendGrid gibi servisleri bu şekilde eklersiniz. Kritik nokta şudur: include bir metin kopyalama değil, iç içe bir sorgudur. Dahil ettiğiniz kaydın içinde başka include'lar varsa onlar da sayılır.

RFC 7208, bir SPF değerlendirmesinde toplam 10 DNS sorgusundan fazlasını yasaklar. Sınırı aşan kayıt permerror döner ve permerror, pass sayılmaz; yani kaydınız tamamen işlevsizleşir. Sorgu üreten mekanizmalar şunlardır:

Üç büyük sağlayıcıyı yan yana koyduğunuzda limite şaşırtıcı biçimde çabuk yaklaşırsınız:

; Görünüşte sadece 4 terim, ama iç içe sorgularla limite dayanıyor
"v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net -all"

Kaç sorgu harcadığınızı görmenin en dürüst yolu, include zincirini elle açmaktır:

# Kendi kaydınızı görün
dig firmaniz.com TXT +short | grep spf1

# Dahil ettiğiniz kaydın içinde ne var, tek tek bakın
dig _spf.google.com TXT +short
dig sendgrid.net TXT +short

Limite yaklaşıyorsanız üç çözüm var. Birincisi, artık kullanmadığınız servisleri kayıttan çıkarmak — çoğu kayıtta eski bir pazarlama aracının include'u unutulmuş durumda durur. İkincisi, include yerine o servisin yayınladığı IP bloklarını ip4/ip6 olarak sabitlemek; sorgu maliyeti sıfıra iner ama sağlayıcı IP değiştirdiğinde sizin de güncellemeniz gerekir. Üçüncüsü, SPF düzleştirme (flattening) yapan bir servis kullanmaktır; bu da aynı bakım yükünü dışarı taşır. Hangisini seçerseniz seçin, kaydı değiştirdiğinizde mutlaka doğrulayın.

all Niteleyicisi: -all mı ~all mı#

Kaydın sonundaki all, "listede olmayan herkes" demektir ve önündeki niteleyici politikanızın sertliğini belirler. -all (hard fail) alıcıya "bu IP benim adıma yazamaz, gönül rahatlığıyla reddet" der. ~all (soft fail) ise "muhtemelen yetkisiz ama emin değilim, sen bilirsin" anlamına gelir ve çoğu alıcı bunu spam puanına küçük bir ekleme olarak yorumlar.

Uzun vadeli hedefiniz -all olmalıdır; çünkü sahteciliği gerçekten durduran budur. Ama doğrudan -all ile başlamak risklidir: unuttuğunuz bir sunucu — fatura gönderen ERP'niz, formlardan mail atan web sunucunuz, bir CRM eklentisi — varsa mektupları anında kaybolur. İzlediğim sıra şudur:

1. Kaydı ~all ile yayınlayın ve DMARC'ı p=none ile birlikte kurup rapor toplamaya başlayın.
2. İki ila dört hafta boyunca gelen raporlarda fail alan IP'leri listeleyin.
3. Meşru olanları kayda ekleyin, tanımadıklarınızı araştırın.
4. Raporlarda meşru kaynaklardan fail kalmadığında ~all yerine -all yazın.
5. Yeni bir gönderim servisi devreye aldığınızda 1. adıma geri dönün.

?all ve +all ise pratikte hiçbir zaman doğru cevap değildir. +all özellikle tehlikelidir: alan adınız adına dünyadaki herkesi yetkilendirir ve kaydı yok saymaktan daha kötüdür, çünkü sahte mektuplara pass verir.

SPF Kaydını Yayınlama ve Doğrulama#

SPF kaydı, alan adınızın kökünde bir TXT kaydı olarak yayınlanır. Bir zamanlar var olan SPF isimli özel kayıt tipi kullanımdan kaldırıldı; bugün sadece TXT geçerlidir. Kayıt eklerken sıkça karşılaşılan biçim hataları şunlardır: kaydı spf.firmaniz.com gibi bir alt alan adına koymak, tırnak işaretlerini yanlış kapatmak veya alan adı başına _spf gibi bir etiket eklemek.

cPanel kullanıyorsanız Zone Editor'da Add Record → TXT ile ekleyin; Name alanına firmaniz.com. ya da @, Record alanına kaydın tamamını yazın. Kendi DNS sunucunuzu yönetiyorsanız bölge dosyasına şu satır girer:

firmaniz.com.   3600   IN   TXT   "v=spf1 ip4:185.12.34.56 include:_spf.google.com ~all"

Yayınladıktan sonra üç kontrolü mutlaka yapın:

# 1) Kayıt görünüyor mu, tek satır mı
dig firmaniz.com TXT +short | grep spf1

# 2) Alan adında BİRDEN FAZLA spf1 kaydı var mı? Varsa ikisi de geçersizdir.
dig firmaniz.com TXT +short | grep -c spf1

# 3) Gerçek bir teslimatta ne oluyor — kendinize test maili atıp
#    alıcıdaki Authentication-Results başlığına bakın

Alıcı tarafta başlıklarda şuna benzer bir satır görmelisiniz:

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of [email protected] designates 185.12.34.56 as permitted sender)

Gönderim yolunun tamamını denetlemek isterseniz SMTP test aracı port, TLS ve PTR uyumu için gereken komutları hazır üretir.

Sık Yapılan Hatalar ve Tuzaklar#

Aynı alan adında iki SPF kaydı. Bu, gördüğüm en yaygın ve en sessiz hatadır. Yeni bir servis eklerken mevcut kaydı düzenlemek yerine ikinci bir TXT kaydı eklenir. RFC'ye göre bu durum permerror'dur ve iki kaydın ikisi birden geçersiz sayılır — yani "en azından biri çalışır" diye düşünmeyin. Tüm mekanizmalar tek bir kayıtta birleştirilmelidir.

255 karakter sınırını unutmak. Bir TXT kaydındaki tek bir dize en fazla 255 karakter olabilir. Uzun SPF kayıtları bu sınırı aşarsa DNS sunucusu kaydı ya reddeder ya da böler; bölünmüş parçalar yan yana tırnaklarla yazılmalıdır. Aynı sorun DKIM tarafında daha da sık yaşanır ve çözümünü DKIM TXT kaydı 255 karakter sınırı yazısında ayrıntılı anlattım.

Alt alan adlarını unutmak. SPF miras alınmaz. firmaniz.com için kayıt yazmanız bulten.firmaniz.com adına gönderilen mektupları kapsamaz. Hiç mail göndermeyen alt alan adları için de bir kayıt yayınlayın — boş bir politika sahteciliği kapatır:

bulten.firmaniz.com.   3600  IN  TXT  "v=spf1 -all"

ptr mekanizması kullanmak. Eski belgelerde görürsünüz ama ptr hem yavaştır hem güvenilmezdir; RFC 7208 açıkça kullanılmamasını söyler. Onun yerine ip4 yazın.

Yönlendirmelerin SPF'i kırdığını fark etmemek. Kullanıcılarınız kurumsal adreslerini kişisel Gmail'lerine iletiyorsa ve DMARC politikanız sertse, kendi mektuplarınız karşı tarafta reddedilebilir. Bu senaryoda ya iletmeyi bırakıp gerçek posta kutusu verin ya da IMAP ile erişim sağlayın; ikisinin farkını IMAP ve POP3 farkı yazısında karşılaştırdım.

Sıkça Sorulan Sorular#

SPF kaydı olmadan mail gönderebilir miyim#

Teknik olarak gönderebilirsiniz, mektuplar SMTP düzeyinde reddedilmez. Ancak Gmail, Outlook ve Yahoo gibi büyük sağlayıcılar SPF'i olmayan alan adlarını belirgin biçimde daha şüpheli sayar ve mektuplarınızın spam klasörüne düşme olasılığı ciddi biçimde artar. Toplu gönderim yapıyorsanız SPF artık bir tercih değil, kabul şartıdır. En basit kayıt bile hiç kayıt olmamasından çok daha iyidir.

SPF kaydı değişikliği ne kadar sürede aktif olur#

Yayılma süresi, kaydın TTL değerine bağlıdır. TTL'iniz 3600 ise değişikliğin her yerde görülmesi en fazla bir saat sürer; 86400 gibi yüksek bir TTL kullanıyorsanız bu bir güne kadar uzayabilir. Bir gönderim servisi ekleyip hemen kampanya başlatacaksanız, değişiklikten önce TTL'i 300'e indirip geçişten sonra tekrar yükseltmek en pratik yöntemdir.

Aynı alan adı için iki SPF kaydı yazabilir miyim#

Hayır, yazarsanız ikisi de çalışmaz. Standart, bir alan adında yalnızca bir tane v=spf1 ile başlayan TXT kaydına izin verir; ikinci bir kayıt bulunduğunda sonuç permerror olur ve doğrulama tamamen başarısız sayılır. Yeni bir gönderim servisi eklerken mevcut kaydı düzenleyin, yeni kayıt eklemeyin. Kontrol için dig firmaniz.com TXT +short | grep -c spf1 komutunun 1 döndüğünü doğrulayın.

-all ile ~all arasında hangisini seçmeliyim#

Hedefiniz -all olmalı, çünkü sahte gönderimi gerçekten durduran budur. Ancak altyapınızdaki tüm gönderici sunucuları eksiksiz listelediğinizden emin olmadan -all yazmak, unuttuğunuz bir sistemin mektuplarının sessizce kaybolmasına yol açar. Önce ~all ile yayınlayıp DMARC raporlarında meşru kaynaklardan fail gelmediğini birkaç hafta gözlemleyin, sonra sertleştirin.

SPF 10 DNS sorgu limitini nasıl kontrol ederim#

Kaydınızdaki include, a, mx ve exists terimlerini sayarak başlayın; ip4 ve ip6 sayılmaz. Ardından her include hedefini dig <hedef> TXT +short ile sorgulayıp onların içindeki include'ları da toplayın. Toplam onu geçiyorsa kaydınız permerror veriyordur. Kullanılmayan servisleri çıkarmak neredeyse her zaman en hızlı çözümdür.

SPF, DKIM ve DMARC'tan hangisi yeterli#

Üçü birbirinin yerine geçmez, birlikte çalışır. SPF hangi sunucunun gönderebileceğini söyler, DKIM mektubun yolda değiştirilmediğini imzayla kanıtlar, DMARC ise bu ikisinin sonucunu kullanıcının gördüğü From: adresiyle hizalayıp politikayı uygular ve size rapor gönderir. Sadece SPF kurmak, sahtecilik korumasının üçte birini kurmak demektir.

Kapanış#

SPF kaydı, doğru yazıldığında sessizce çalışan ve size hiç iş çıkarmayan bir kayıttır; yanlış yazıldığında ise teşhisi zor teslimat sorunlarının kaynağı olur. Aklınızda kalması gereken dört alışkanlık şudur: alan adı başına tek bir SPF kaydı tutun, ip4/ip6 yazarak DNS sorgu bütçenizi koruyun, ~all ile başlayıp raporları okuduktan sonra -all ile bitirin ve her değişiklikten sonra hem dig ile kaydı hem de gerçek bir test mektubunun Authentication-Results başlığını kontrol edin. Mail göndermeyen alt alan adlarınızı da v=spf1 -all ile kapatmayı unutmayın.

Kendi gönderim altyapınızı kurmak istiyorsanız ayrılmış IP ve temiz itibar sunan SMTP sunucu paketlerimiz SPF, DKIM ve PTR kayıtlarıyla birlikte teslim edilir; kurumsal posta kutuları için e-posta çözümlerimize, bülten ve kampanya gönderimleri için e-posta pazarlama hizmetimize göz atabilirsiniz. DNS ve mail sunucusu yapılandırmasını tamamen devretmek isterseniz sunucu yönetimi hizmetimiz bu ayarları sizin yerinize kurar ve izler.