SPF Kaydı Nedir, DNS'te Nasıl Görünür, Nasıl Kontrol Edilir

SPF kaydı, domain'inizin DNS'inde tek bir TXT satırı olarak durur ama arkasında birden fazla sunucuyu yetkilendiren, karmaşıklaşabilen bir zincir taşır. B2B ekiplerinde genelde kurumsal e-posta, CRM, pazarlama aracı ve fatura sistemi aynı domain'i kullandığından, bu zincir hızla büyür ve teknik bir limite (10 DNS lookup) çarpabilir — bu yazıda kaydın nasıl okunacağını, nasıl kontrol edileceğini ve en sık yapılan hataları adım adım ele alıyoruz.

SPF kaydı DNS'te tam olarak nasıl görünür

SPF, domain'in DNS'inde bir TXT kaydı olarak yayınlanır ve her zaman 'v=spf1' ile başlar. Bunu takiben bir veya birden fazla mekanizma gelir: ip4:/ip6: belirli bir IP veya IP bloğunu doğrudan yetkilendirir, include: başka bir domain'in SPF kaydını bu kayda dahil eder (genelde üçüncü taraf gönderim araçları için kullanılır), a ve mx ise domain'in kendi A veya MX kayıtlarındaki sunucuları yetkilendirir.

Kayıt bir niteleyiciyle (qualifier) biter: -all (fail — listede olmayan kaynaklar reddedilsin), ~all (soft fail — şüpheli işaretlensin ama kesin reddedilmesin), ?all (neutral — karar verilmesin) veya +all (herkese izin ver — pratikte önerilmez, SPF'i işlevsiz kılar). B2B gönderiminde genelde ~all ile başlayıp süreç oturduktan sonra -all'a geçmek tercih edilir.

SPF kaydı nasıl kontrol edilir

En basit kontrol, komut satırından bir DNS sorgu aracıyla yapılır: 'dig TXT domain.com' veya 'nslookup -type=TXT domain.com' komutu, domain'in tüm TXT kayıtlarını listeler; SPF kaydı 'v=spf1' ile başlayan satırdır. Bu yöntem, kaydın gerçekten yayınlanıp yayınlanmadığını ve DNS'in doğru propagate olup olmadığını doğrudan gösterir.

Online araçlar bu işi daha okunabilir hale getirir: MXToolbox gibi bilinen bir DNS kontrol aracı, SPF kaydının söz dizimini kontrol eder, include zincirini çözer ve lookup sayısını hesaplayarak 10 limitine ne kadar yaklaştığınızı gösterir. Bir kayıt teknik olarak var ama söz dizimi hatalıysa (örneğin fazladan boşluk, yanlış niteleyici sırası), bu araçlar hatayı işaret satırında gösterir.

Kontrolü sadece kayıt değişikliği yapıldığında değil, düzenli bir rutin olarak da tekrarlamak faydalıdır. DNS kayıtları kendiliğinden bozulmaz, ama zincire dahil olan bir include'un arkasındaki üçüncü taraf servis kendi SPF yapılandırmasını değiştirebilir — bu durumda sizin kaydınızda hiçbir değişiklik olmadan lookup sayınız veya yetkilendirilen IP'ler farklılaşabilir. Aylık bir kontrol, bu tür dolaylı değişiklikleri yakalamanın pratik yoludur.

• Komut satırı: dig TXT domain.com veya nslookup -type=TXT domain.com
• Online: MXToolbox SPF kayıt kontrolü — söz dizimi + lookup sayısı
• mail-tester.com gibi araçlarla gerçek bir test gönderimi üzerinden SPF sonucunu (pass/fail/softfail) doğrudan görme
• Birden fazla TXT 'v=spf1' kaydı olup olmadığını kontrol etme — varsa bu SPF'i geçersiz kılar

Birden fazla gönderim aracı olan B2B ekiplerinde SPF yönetimi

B2B şirketlerinde tek bir domain genelde birden fazla amaç için kullanılır: kurumsal e-posta (Google Workspace veya Microsoft 365), CRM üzerinden giden bildirimler, soğuk e-posta gönderim altyapısı, pazarlama otomasyon aracı, fatura/muhasebe sistemi. Her biri SPF kaydına bir include: satırı olarak eklenir — ve her include, kendi içinde başka include'lara sahip olabilir, bu da lookup sayısını hızla artırır.

Pratik yaklaşım, yeni bir araç eklerken sadece kaydın sonuna include eklemek değil, mevcut kaydı gözden geçirip artık kullanılmayan (örneğin iptal edilmiş bir eski ESP'nin) include satırlarını temizlemektir. Aksi halde kayıt zamanla şişer ve hiç kimsenin tam olarak takip etmediği bir yapıya dönüşür.

10 lookup limiti aşılırsa ne olur, nasıl azaltılır

10 lookup limiti aşıldığında SPF kaydı 'permerror' durumuna düşer ve alıcı sunucular kaydı geçersiz sayabilir — bu, SPF'in hiç olmamasıyla benzer bir sonuç doğurur, çünkü artık hiçbir kaynak güvenilir şekilde doğrulanamaz. Bu durum özellikle çok sayıda üçüncü taraf aracın eklendiği büyüyen B2B şirketlerinde sessizce oluşur; kimse fark etmeden limit aşılmış olabilir.

Azaltmanın iki yolu var: gereksiz veya artık kullanılmayan include'ları temizlemek, ya da 'SPF flattening' denen yöntemle include zincirlerini çözüp doğrudan IP adreslerine indirmek. Flattening lookup sayısını azaltır ama bir riski vardır — üçüncü taraf servis kendi IP'lerini değiştirirse, flattened kayıt elle güncellenmediği sürece güncelliğini yitirir. Bu yüzden flattening yapılıyorsa düzenli otomatik senkronizasyon şart.

En sık yapılan SPF hataları

Birden fazla 'v=spf1' TXT kaydı yayınlamak en sık ve en yıkıcı hatalardan biri — DNS standardı bir domain için yalnızca bir SPF kaydına izin verir, ikinci bir kayıt eklendiğinde (örneğin farklı bir ekip aynı anda başka bir araç için ayrı bir kayıt eklerse) SPF tamamen geçersiz hale gelir. İkinci sık hata, include zincirini hiç izlememek ve zamanla 10 lookup limitini aşmak.

Üçüncü hata, niteleyiciyi yanlış seçmek: +all kullanmak SPF'i işlevsiz bırakır çünkü herkese izin verir. Dördüncü hata, bir gönderim aracını SPF'ten kaldırmayı unutmak — artık kullanılmayan bir aracın IP'si SPF'te kalmaya devam ederse, o IP başka bir müşteriye tahsis edildiğinde teorik olarak sizin domain'iniz adına spam gönderebilir hale gelebilir.

Beşinci hata, SPF değişikliğini test etmeden canlıya almak. DNS önbelleğe alma (caching) süresi nedeniyle bir değişikliğin tüm alıcı sunuculara yayılması saatler alabilir; bu süre zarfında eski ve yeni kayıt karışık şekilde görülebilir. Büyük bir kampanya öncesi SPF'te değişiklik yapılıyorsa, değişikliği kampanyadan en az bir gün önce yapıp yayılmasını beklemek, gönderim gününde beklenmedik doğrulama hatalarının önüne geçer.

• Aynı domain'de birden fazla 'v=spf1' TXT kaydı bulunması
• 10 lookup limitinin fark edilmeden aşılması
• +all gibi SPF'i işlevsiz kılan bir niteleyici kullanılması
• Artık kullanılmayan bir aracın include/ip kaydının temizlenmemesi
• SPF'in DKIM ve DMARC olmadan 'tek başına yeterli' sanılması

SPF'in DKIM ve DMARC ile ilişkisi ne olmalı

SPF kaydını doğru kurmak, kimlik doğrulama zincirinin sadece bir halkasıdır. SPF, hangi sunucunun gönderime yetkili olduğunu söyler ama mesajın içeriğinin yolda değişmediğini kanıtlamaz — bunu DKIM imzası yapar. Ve SPF ile DKIM'in ikisi de teknik olarak 'geçse' bile, alıcının gördüğü From adresiyle bu kontrollerin gerçekte baktığı domain'in hizalı olup olmadığını DMARC belirler.

Bu yüzden bir B2B ekibi için doğru sıralama şudur: önce SPF kaydını temiz ve doğru kurmak, ardından DKIM imzalamasını aktif etmek, son olarak DMARC kaydını p=none ile başlatıp raporları izlemek. Üçünü aynı anda, test etmeden ve p=reject gibi katı bir politikayla kurmaya çalışmak, meşru gönderimlerin de etkilenmesi riskini artırır.

Checklist: SPF kaydı sağlık kontrolü

B2B soğuk e-posta göndermeden önce SPF kaydınızı bu maddelerle hızlıca gözden geçirin.

• dig TXT veya MXToolbox ile tek bir 'v=spf1' kaydının var olduğunu doğrulayın
• Lookup sayısının 10'a ne kadar yakın olduğunu kontrol edin
• Artık kullanılmayan araçların include/ip satırlarını temizleyin
• Niteleyicinin (~all veya -all) kasıtlı seçildiğinden emin olun, +all kullanılmadığını doğrulayın
• SPF'i DKIM ve DMARC ile birlikte değerlendirin, tek başına yeterli görmeyin

Sık sorulan sorular