# SPF Kaydı Nedir? Sözdizimi, Sınırlar ve Hata Modları URL: https://notificationharbor.com/tr/journal/spf-kaydi-nedir Type: blog Locale: tr Published: 2026-10-20 Updated: 2026-10-23 --- > SPF kaydı, alan adınız adına posta gönderen sunucuları listeler. Sözdizimi, 10 sorgu sınırı, yönlendirme hataları ve kaydınızı nasıl kontrol edeceğiniz bu yazıda. SPF kaydı nedir? Alan adınızın DNS bölgesinde yayımlanan tek bir TXT kaydıdır ve hangi sunucuların o alan adı üzerinden posta gönderebileceğini listeler. Alıcı sunucu, mesajı gönderen IP adresini bu listeyle karşılaştırır ve sonucu pass, fail, softfail ya da neutral olarak döndürür. SPF, mesajın içeriğini değil gönderim yolunu doğrular. Kullanıcının gördüğü From adresi hakkında ise hiçbir şey söylemez. Bu ayrım, destek kayıtlarında gördüğümüz SPF sorunlarının çoğunu açıklıyor. ## SPF kaydı, DNS'te yayımlanan bir gönderici izin listesidir SPF, Sender Policy Framework'ün kısaltmasıdır ve [RFC 7208](https://datatracker.ietf.org/doc/html/rfc7208) ile tanımlanır. Kayıt, alan adının kökünde bir TXT girdisidir ve `v=spf1` ile başlar. En küçük bir örnek şöyle görünür: `example.com. IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.provider.example ~all"`Kaydı soldan sağa okuyun. Alıcı terimleri sırayla kontrol eder ve ilk eşleşmede durur. Sondaki `all` terimi, önceki terimlerle eşleşmeyen her şeyi yakalar. Kontrol edilen alan adı From başlığı değildir. SMTP `MAIL FROM` komutundaki alan adıdır; zarf göndereni ya da Return-Path olarak da bilinir. Bu değer boşsa, örneğin bounce mesajlarında, alıcı `HELO` adına geri döner. ![Laptop terminali ve elle çizilmiş ağ diyagramı defteriyle bir geliştirici masası](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-10/0bf38c-inline1.webp) ## Mekanizmalar: ip4, ip6, a, mx, include ve exists Her terim bir mekanizmadır ve isteğe bağlı bir niteleyiciyle başlayabilir. Neredeyse her gerçek kaydı altı mekanizma karşılar: - **`ip4:` ve `ip6:`** Sabit bir adresi ya da CIDR aralığını eşleştirir. Sorgu maliyeti sıfırdır. - **`a`** Alan adının A ve AAAA kayıtlarını eşleştirir. Bir sorgu harcar. - **`mx`** Alan adının MX kayıtlarındaki sunucuları eşleştirir. Bir sorgu ve her sunucu için bir ek sorgu harcar. - **`include:`** Başka bir alan adının SPF kaydının eşleştirdiği her şeyi eşleştirir. Bir sorgu harcar, içindeki her şey de sayılır. - **`exists:`** Oluşturulmuş bir ad için herhangi bir A kaydını eşleştirir. Bir sorgu harcar. - **`ptr`** Bağlanan IP'nin ters DNS kaydını eşleştirir. Sorgu harcar ve RFC 7208 bu kullanımı önerilmez sayar. Niteleyiciler, bir terim eşleştiğinde sonucu belirler. `+` pass anlamına gelir ve varsayılandır, `-` fail, `~` softfail, `?` neutral. Yani `-all` "listelenmeyen her şeyi reddet" demektir, `~all` ise "kabul et ama işaretle". Adresin sizin kontrolünüzde olduğu durumlarda `ip4:` ve `ip6:` tercih edin. Sıfır sorgu harcarlar ve başka birinin DNS'i değiştiğinde bozulmazlar. ## 10 DNS sorgu sınırı, gerçek kayıtları bozan kısıttır RFC 7208, tek bir SPF değerlendirmesinde DNS sorgusu tetikleyen en fazla 10 terim tanımlar: `include`, `a`, `mx`, `ptr`, `exists` ve `redirect` değiştiricisi. İç içe include'lar da sayılır. Sınır aşıldığında sonuç `permerror` olur ve kontrol geri dönüş yapılmadan kalıcı olarak başarısız sayılır. İkinci bir sınır daha var ve daha az dikkat çekiyor. Boş yanıt ya da NXDOMAIN dönen terimler boş sorgu sayılır ve spec bunları en fazla ikiyle sınırlar. Geçen yıl bıraktığınız bir sağlayıcıya işaret eden eski bir `include:` kaydı, ödediğiniz ama işe yaramayan bir boş sorgudur. Ekiplerin bu tavana nasıl dayandığını düşünün. Google Workspace bir include ekler. Bir transactional sağlayıcı bir include ekler. Bir pazarlama platformu bir include ekler ve içine üç tane daha yerleştirir. Bir destek masası, bir CRM ve bir faturalama aracı dört include daha ekler. Hiçbir sıradışı şey yapmadan 11'e ulaşmış olursunuz. Hata sessizdir. Posta yine gönderilir, bazı alıcılar yine teslim eder, ama SPF artık sizin için hiçbir şeyi doğrulamaz. DMARC hizalamanızı SPF üzerinden kuruyorsanız, kaydı sadeleştirene ya da gönderenleri kaldırana kadar bu yol kapalıdır. Üç çözüm var, tercih sırasına göre: - Artık kullanmadığınız göndericileri kaldırın. Include'ları son 90 günün DMARC toplu raporlarına göre denetleyin. - Toplu trafiği `mail.example.com` gibi bir alt alana taşıyın. Bu alt alanın kendi SPF kaydı ve kendi 10 sorgulık bütçesi olsun. - Include'ları sabit `ip4:` aralıklarına açın, ama yalnızca otomasyonla. Sağlayıcılar IP'lerini değiştirir ve elle açılmış bir kayıt, hiçbir uyarı vermeden eskir. ![Bir dizi gönderen servisten tek bir merkezi kutuya uzanan okların elle çizilmiş taslağı](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-10/96537f-inline2.webp) ## Alan adı başına tek bir SPF kaydı yayımlayın Bir alan adı iki SPF kaydı yayımlamamalıdır. Bir alıcı iki `v=spf1` TXT girdisi bulursa sonuç `permerror` olur, tıpkı sorgu sınırında olduğu gibi. Bu genellikle biri yeni bir araç için kayıt eklerken, diğerinin zaten bir kayıt koyduğunu bilmediğinde olur. Düzeltme mekaniktir. Terimleri tek bir kayda birleştirin: başta bir `v=spf1`, sonda bir `all`. Satıcının dokümantasyonunun eklemenizi istediği her şey mevcut kaydın içine yeni bir `include:` olarak girsin, asla yeni bir TXT girdisi olarak değil. İki küçük tuzak daha var. 255 karakterden uzun bir TXT dizgisi aynı kaydın içinde birden fazla tırnaklı dizgiye bölünmelidir; çoğu DNS sağlayıcısı bunu sizin yerinize yapar. Ayrıca mümkünse tüm yanıtı yaklaşık 450 bayt altında tutun, çünkü daha büyük yanıtlar UDP'den TCP'ye geçebilir ve bazı çözümleyiciler bunu kötü yönetir. ## Softfail mi hardfail mi: gördüğünüz şeye göre seçin `all` terimi bir politika beyanıdır. Sık verilen "-all kullanın" tavsiyesi ise önemli kısmı atlıyor. Sert bir fail, bütün meşru göndericileri bildiğinizde güvenlidir. Hata ayıklamalarda izlediğimiz pratik kural şu: - Göndericileri hâlâ envanterlerken ya da yönlendirilen postayı kontrol edemediğinizde `~all` kullanın. - DMARC raporları birkaç hafta boyunca her meşru kaynağın geçtiğini gösterdikten sonra `-all` kullanın. - Asla `+all` kullanmayın, çünkü bu tüm internete yetki verir. Üretim alan adında `?all` de kullanmayın. Pratikte fark, insanların beklediğinden daha küçük. Büyük alıcıların çoğu SPF'yi birçok sinyalden biri olarak değerlendirir ve DMARC politikası varken karar veren DMARC sonucudur. Yine de eksik bir kayıtta `-all`, faturaların kaybolmasının yollarından biridir. ![Bir sunucu rafında etiketli ethernet kablo demeti](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-10/3e48d3-inline3.webp) ## SPF yönlendirmede bozulur, bu tasarımın bir parçasıdır SPF, alıcı sunucuya bağlanan IP'yi doğrular. Bir ileti yönlendirildiğinde, bir posta listesi tarafından yeniden dağıtıldığında ya da bir takma ad servisi tarafından aktarıldığında, bağlanan IP yönlendiriciye aittir, size değil. SPF kontrolü, siz hiçbir şey yanlış yapmamışken başarısız olur. Bunu SPF'nin içinde çözemezsiniz. DKIM'in SPF'nin yanında var olmasının nedeni de budur: imza bu sıçramadan sağ çıkar, IP listesi çıkamaz. Yalnızca SPF'ye bağlı bir alan adı, yönlendirilen her iletide kimlik doğrulama hatası görür. Bu yüzden SPF tek başına yönlendirilmiş postada DMARC'ı da karşılamaz. Bu iletileri taşıması için DKIM'i planlayın. ## SPF hizalaması: geçmek, From alan adınızla eşleşmek demek değildir Bir ileti SPF'yi geçebilir ve yine de DMARC'ta başarısız olabilir. DMARC, SPF'yi geçen alan adının, yani Return-Path alan adının, görünen From alan adıyla eşleşmesini ister. Birçok paylaşımlı sağlayıcı varsayılan olarak kendi bounce alan adını kullanır. Bu durumda SPF `provider-mail.net` için geçer ve `example.com` hakkında hiçbir şey söylemez. Bunu ham başlıklarda kontrol edin. `Authentication-Results` satırında `smtp.mailfrom=` değerine bakın. Bu sizin alan adınız ya da onun bir alt alanı değilse, SPF geçiyor ama sizin için bir işe yaramıyor. Çözüm, kendi alt alanınızda özel bir Return-Path kullanmaktır. Ciddi göndericilerin çoğu bunu destekler. Postmark, Resend, Mailgun ve SendGrid bu kurulumu belgeler, ama her zaman varsayılan olarak açık gelmez. ## Gelen kutusu sağlayıcıları artık her göndericiden kimlik doğrulama bekliyor Şubat 2024'ten beri Google, tüm göndericilerin SPF ya da DKIM ile kimlik doğrulaması yapmasını istiyor. Gmail'e günde 5.000'den fazla ileti gönderen göndericilerin ise SPF, DKIM ve DMARC'a sahip olması gerekiyor. Ayrıntılar [Google'ın e-posta gönderici yönergelerinde](https://support.google.com/mail/answer/81126) yer alıyor. Yahoo da aynı dönemde benzer eşleştirme kuralları getirdi. Bu değişiklik SPF'yi "olsa iyi olur" olmaktan çıkarıp bir teslimat ön koşulu haline getirdi. Eksik ya da bozuk bir kayıt artık yalnızca düşük bir itibar puanı olarak değil, reddedilme ve spam klasörüne düşme olarak görünüyor. Birkaç yıllık hata ayıklama deneyimimize göre bu kurallar çoğunlukla hiç kimlik doğrulaması olmayan alan adlarını ve yüksek şikayet oranına sahip göndericileri yakalıyor. Doğru bir SPF kaydı tek başına sizi gelen kutusuna sokmaz, ama eksik bir kayıt sizi dışarıda tutar. ## Bir SPF kaydını dört adımda kontrol edip düzeltin Bu adımları sırayla uygulayın ve her DNS değişikliğinden sonra yeniden kontrol edin. - **Mevcut kaydı alın.** `dig +short TXT example.com` komutunu çalıştırın ve `v=spf1` ile başlayan girdiyi bulun. İki tane varsa birleştirin. - **Sorguları sayın.** `include`, `a`, `mx`, `exists`, `redirect` ve include'ların içindeki her şeyi toplayın. Toplam 8 ya da daha fazlaysa temizliği şimdi planlayın, 11. sorguda değil. - **Gerçek göndericileri listeleyin.** DMARC toplu raporlarını ya da test gönderimlerinin Authentication-Results başlıklarını kullanın. Yalnızca görünen kaynakları ekleyin. - **Bir test gönderin ve başlığı okuyun.** Sonuç `spf=pass` olmalı ve `smtp.mailfrom` sizin alan adınızda olmalı. DNS değişiklikleri yayılmak için zaman alır ve mevcut kaydınızın TTL değeri, eski yanıtların ne kadar yaşayacağını belirler. Planlı bir değişiklikten bir gün önce TTL değerini 300 saniyeye indirin. ## Üç göndericisi olan bir SaaS şirketi için örnek bir kayıt Google Workspace, bir transactional sağlayıcı ve bir destek masasıyla gönderim yapan bir ürünü düşünelim. Temiz bir kayıt şöyle görünebilir: `example.com. IN TXT "v=spf1 include:_spf.google.com include:spf.transactional.example include:spf.helpdesk.example -all"`Bu üç include, her birinin kendi iç sorgularını gizlediği anlamına gelir. Yayımlamadan önce sayın, çünkü görünen uzunluk gerçek bütçe hakkında hiçbir şey söylemez. Üç include'lu bir kayıt bile 7 ya da 8 sorguya ulaşabilir. Şimdi amaca göre ayırın. İnsan postasını kök alan adında tutun. Ürün bildirimlerini yalnızca transactional sağlayıcıyı listeleyen bir kayıtla `notify.example.com` üzerine taşıyın. Kök kayıt kısa kalır, alt alan kendi 10 sorgulık bütçesini alır ve bir akıştaki itibar sorunu diğerini sürüklemez. Bu ayrım DMARC raporlarını da okunur hale getirir. Her akışın kendi Return-Path alan adı olduğu için bir hata, bir yığın gönderici yerine tek bir göndericiye işaret eder. ## SPF neyi yapmaz SPF, From adresinizin taklit edilmesini durdurmaz, çünkü o başlığa hiç bakmaz. Hiçbir şeyi şifrelemez. Bir iletinin neden spam klasörüne düştüğünü söylemez. Sürekli bakım olmadan da 10 sorgulık bütçenin ötesine ölçeklenmez. Onu birlikte yayımladığınız üç kayıttan biri olarak düşünün: gönderim yolu için SPF, ileti bütünlüğü için DKIM, bu ikisini From alan adınıza bağlayan politika için DMARC. Yalnızca SPF'niz varsa, bir sonraki somut adım `p=none` politikasıyla bir DMARC kaydı yayımlamak ve iki hafta boyunca raporlarını okumaktır. ## FAQ ### SPF kaydı basitçe ne demek? Alan adınız adına posta gönderme yetkisi olan sunucuları listeleyen bir DNS TXT kaydıdır. Alıcı sunucular, gönderen IP adresini bu listeyle karşılaştırarak SPF kontrolünün geçip geçmediğine karar verir. ### Bir alan adının kaç SPF kaydı olabilir? Yalnızca bir tane. Her ikisi de v=spf1 ile başlayan iki kayıt yayımlamak permerror hatasına yol açar. Tüm yetkili göndericileri tek bir kayıtta birleştirin ve sonuna tek bir all terimi koyun. ### SPF'nin 10 DNS sorgusu sınırı nedir? RFC 7208, bir değerlendirmede DNS sorgusu yapan en fazla 10 terim tanımlar: include, a, mx, ptr, exists ve redirect. İç içe include'lar da sayılır. Sınır aşılırsa permerror döner ve SPF postanızı doğrulamayı bırakır. ### Kaydımda -all mı yoksa ~all mı kullanmalıyım? Göndericileri envanterlerken ~all kullanın. Tüm meşru kaynakların birkaç hafta boyunca DMARC raporlarında geçtiğini gördüğünüzde -all'a geçin. Her yere yetki veren +all asla kullanılmamalıdır. ### E-posta yönlendirildiğinde SPF neden başarısız olur? SPF, alıcı sunucuya bağlanan IP adresini kontrol eder. Yönlendirici kendi IP adresinden bağlanır ve bu adres kaydınızda yer almaz. DKIM imzası ileti ile birlikte gittiği için yönlendirmeden sağ çıkar. ### SPF tek başına sahteciliğe karşı koruma sağlar mı? Hayır. SPF, görünen From adresini değil zarf göndericisini doğrular. From alan adınızı korumak için SPF veya DKIM ile hizalanarak geçmesi gereken DMARC'a ihtiyacınız var.