Gelişmiş SPF Yönetimi: 10 DNS Lookup Limitine Takılmadan Çoklu E‑Posta Servisi Kullanmak

Alan adınızdan hem kendi sunucunuzdan, hem CRM sisteminizden, hem de pazarlama araçlarınızdan e‑posta gönderiyorsanız, bir noktada SPF kaydının sınırlarına toslamanız neredeyse kaçınılmazdır. Test araçlarında gördüğünüz ‘Too many DNS lookups’ veya ‘PermError: DNS lookup limit exceeded’ uyarıları, bir yandan teslim edilebilirliği düşürürken diğer yandan da nereden başlayacağınızı bilemediğiniz karmaşık bir tablo yaratır.

Bu yazıda, DCHost ekibi olarak sahada en çok gördüğümüz problemler üzerinden gideceğiz ve ’10 DNS lookup limitine takılmadan’ birden fazla e‑posta servisini aynı alan adında nasıl doğru tanımlayabileceğinizi adım adım anlatacağız. SPF’in temel mantığından çok, gerçek hayatta karşımıza çıkan senaryolara, tipik yanlış konfigürasyonlara, delegasyon ve ayrı alan adı kullanma stratejilerine, SPF flattening mimarisine ve IPv6 ile birlikte planlama detaylarına odaklanacağız. Eğer elinizde şu anda çalıştığından emin olamadığınız, birden fazla ‘include’ içeren karmaşık bir SPF kaydı varsa, yazının sonunda onu sade, okunabilir ve RFC’ye uygun hale getirebilecek net bir yol haritanız olacak.

SPF ve 10 DNS Lookup Sınırı Gerçekte Ne Anlama Geliyor?

SPF (Sender Policy Framework), alıcı mail sunucularına ‘Bu alan adı adına e‑posta göndermeye kimlerin yetkili olduğunu’ DNS üzerinden ilan etmenin standart yoludur. TXT kaydı olarak tanımlanan SPF kaydı, gelen e‑postanın kaynağını kontrol etmek için çeşitli mekanizmalar kullanır: ip4, ip6, a, mx, include, exists, ptr, redirect gibi.

RFC 7208’e göre SPF değerlendirmesi sırasında en fazla 10 DNS lookup yapılmasına izin verilir. Bu sınırı aşarsanız SPF sonucu PermError olur; yani kayıt ‘geçersiz’ kabul edilir. Çoğu alıcı sunucu PermError durumunda SPF’i yok sayar; dolayısıyla DMARC ile SPF’e güveniyorsanız, teslim edilebilirlik ciddi şekilde zarar görebilir.

Lookup sınırı, DNS sorgusu oluşturan mekanizmalar için geçerlidir. Sayılanlar:

• include: Başka bir alan adının SPF kaydını içe alır (1 lookup)
• a: Alan adının A/AAAA kaydını çözer (1 lookup)
• mx: MX kaydını ve ardından onun A/AAAA kayıtlarını çözer (en az 1, çoğu zaman daha fazla lookup)
• exists: Verilen domaini gerçekten çözüp çözülmediğini kontrol eder (1 lookup)
• ptr: Reverse DNS sorgusu yapar (1 lookup, fakat zaten önerilmiyor)
• redirect= Başka bir alanın SPF kaydına yönlendirir (1 lookup)

ip4, ip6, all gibi mekanizmalar ek DNS sorgusu üretmez, dolayısıyla lookup limitini etkilemez. Sınırı aşmanıza sebep olan genellikle çok sayıda include ve iç içe include zincirleridir. Bir servis sizden ‘include:spf.servisadi.com’ eklemenizi ister, o SPF kaydının içinde de 6–7 farklı include daha çıkar ve toplam sayıyı kolayca 10’un üzerine taşırsınız.

Birden Fazla E‑Posta Servisi Kullanan Şirketlerin Tipik SPF Sorunları

DCHost tarafında hem paylaşımlı hosting hem VPS hem de kendi MTA’sını yöneten kurumsal müşterilerle çalışırken en sık gördüğümüz SPF problemlerini özetleyelim:

• Kendi mail sunucusu + bir CRM + bir pazarlama aracı + bir yardım masası yazılımı gibi 3–5 farklı kaynaktan e‑posta gönderimi
• Her servisin dökümantasyonundaki ‘Şu include’u ekleyin’ önerilerine körü körüne uyup 8–10 farklı include kullanmak
• Her include içindeki SPF kaydının da birden fazla include içermesi ve iç içe zincirler oluşması
• Subdomain yerine her şeyi kök alan adında toplamak; hem gönderim domaini, hem Return‑Path, hem SPF için tek domain kullanmak
• Eski, artık kullanılmayan servislerin SPF’te unutulması; yani teknik borç birikmesi

Sonuç çoğunlukla şöyle oluyor:

• SPF test araçlarında ‘PermError: too many DNS lookups’ veya ‘Maximum hops exceeded’ uyarıları
• DMARC raporlarında ‘SPF temperror/permerror’ satırlarının artması
• Bazı alıcılara giden maillerin spam’e düşmesi, bazılarının ise SPF’i yok sayması nedeniyle tutarsız teslim edilebilirlik

Temel SPF mantığını öğrenmek için önce SPF, DKIM ve DMARC doğrulamasını sıfırdan kurma rehberimizi okumanız iyi bir başlangıç olur. Bu yazıda ise ileri seviye konfigürasyona ve optimizasyona odaklanacağız.

10 Lookup Limitine Takılmadan SPF Kaydı Tasarlama Adımları

1. Tüm Gönderim Kaynaklarını Envanterleyin

Önce hangi sistemlerin hangi alan adı adına e‑posta gönderdiğini netleştirmeniz gerekiyor. Sıklıkla atlanan kaynaklar şunlar:

• Web sitenizin iletişim formları (PHP mail, SMTP eklentileri)
• E‑ticaret sitenizin sipariş, fatura ve bildirim mailleri
• CRM ve pazarlama otomasyonu araçları
• Destek/ticket sistemleri
• Sunucu izleme araçları, backup bildirimleri, cron raporları

Her biri için şu bilgileri toplayın:

• Gönderen domain (From: alanındaki alan adı)
• Return‑Path / MAIL FROM alan adı (çoğu zaman farklıdır)
• Hizmet tarafından önerilen SPF include veya IP listesi
• Kendi kontrolünüzde olan IP’ler (örneğin DCHost üzerindeki VPS veya mail sunucunuz)

2. Include Yerine IP ve A/MX Kullanabileceğiniz Yerleri Ayıklayın

SPF lookup sayısını düşürmenin en etkili yöntemi, kendi kontrolünüzde olan IP adreslerini doğrudan SPF’e yazmaktır. Örneğin alan adınızın mail.sunucu.com gibi bir alt alanından, DCHost üzerindeki bir VPS’ten e‑posta gönderiyorsanız, çoğu zaman şu seçenekleriniz vardır:

v=spf1 ip4:1.2.3.4 -all

veya

v=spf1 a:mail.sunucu.com -all

Burada:

• ip4 mekanizması ek DNS lookup üretmez.
• a:mail.sunucu.com bir kez lookup yapar, fakat bu alanın IP’si sizin elinizdedir.

Klasik hata: Aynı IP’yi hem MX, hem A kaydı, hem de SPF include üzerinden dolaylı yoldan tanımlamak. Örneğin:

v=spf1 mx include:mail.dchost-musteri.com a -all

Bunun yerine, hangi IP’lerden gerçekten gönderim yapıldığını tespit edip SPF’i sadeleştirmek genellikle hem lookup sayısını hem de karışıklığı azaltır.

3. Gereksiz Include’ları Temizleyin

Envanterden sonra sıklıkla gördüğümüz manzara şu:

v=spf1 include:_spf1.servis.com include:_spf2.servis.com include:mail1.example.net include:mail2.example.net include:eu.mailhost.com ~all

Burada her bir include en az bir, çoğu zaman birkaç DNS lookup daha oluşturur. Servislerin dökümantasyonunu dikkatle inceleyin:

• Aynı servis için birden çok include gerekiyormuş gibi görünen ama aslında eski sürümler için bırakılmış kayıtlar olabilir.
• Bölgesel include’lar (eu, us, asia) arasından sadece gerçekten kullandığınızı bırakabilirsiniz.
• Bazı servisler hem ‘include:spf.servis.com’ hem de birkaç IP aralığı veriyorsa, sadece kullandığınız IP bloğunu seçip doğrudan ip4/ip6 ile yazabilirsiniz.

Hedefiniz, bütün servislere rağmen toplam 4–6 lookup civarında kalmak olsun. Geri kalanları flattening veya delegasyon gibi gelişmiş tekniklerle çözeceğiz.

4. ‘redirect’ ve ‘exists’ Mekanizmalarını Dikkatli Kullanın

‘redirect=’ parametresi SPF kaydını tamamen başka bir alana devreder. Örneğin:

example.com:   v=spf1 redirect=_spf.example.com
_spf.example.com: v=spf1 ip4:1.2.3.4 include:servis.com -all

Bu, yönetimi kolaylaştırabilir ama lookup sayısını azaltmaz; hatta yanlış kurulduğunda zinciri uzatıp arttırır. Benzer şekilde ‘exists’ mekanizması da ölçüsüz kullanıldığında gereksiz sorgu sebebi olabilir. Lookup limitine yakınsanız, redirect ve exists’ten kaçınmak çoğu zaman iyi bir fikirdir.

Delegasyon, Ayrı Alan Adları ve Subdomain Stratejileri

Gelişmiş SPF yönetiminde en güçlü araçlardan biri, aynı marka için birden fazla domain veya subdomain kullanmaktır. Burada kritik nokta, DMARC hizalamasını (alignment) bozmadan SPF’i sadeleştirmektir.

Transactional, Pazarlama ve Operasyonel Mailleri Ayırın

Genel bir iyi uygulama:

• Transactional mailler (şifre sıfırlama, sipariş onayı) için: mail.example.com veya notify.example.com
• Pazarlama/bülten mailleri için: news.example.com veya email.example.com
• Destek ve ticket mailleri için: support.example.com

Her bir subdomain için ayrı bir SPF kaydı tanımlayabilir ve ilgili servisi sadece oraya bağlayabilirsiniz. Örneğin:

example.com.        TXT "v=spf1 ip4:203.0.113.10 -all"
mail.example.com.   TXT "v=spf1 include:spf.transactionalservis.com -all"
news.example.com.   TXT "v=spf1 include:spf.marketingservis.com -all"

Burada önemli olan, kullandığınız servislerin Return‑Path / MAIL FROM domainini bu subdomain’lere göre ayarlayabilmenizdir. Çoğu kurumsal e‑posta ve pazarlama servisi, özel envelope‑from domain tanımına izin verir.

DMARC Hizalamasını Korumak

DMARC, SPF veya DKIM sonucunu değerlendirirken ‘alignment’ kavramını kullanır. SPF alignment, From başlığındaki alan adı ile SPF doğrulaması yapılan alan adının aynı kökten gelmesini ister. Örneğin:

• From: [email protected]
• SPF doğrulaması: mail.example.com

Bu durumda relaxed alignment altında geçerli sayılır, çünkü ikisi de aynı kök alan adı (example.com) altındadır. Yani transactional mailler için MAIL FROM’u mail.example.com, marketing mailler için MAIL FROM’u news.example.com yapmak DMARC açısından sorun yaratmaz; tam tersine SPF’i sadeleştirmeyi kolaylaştırır.

DMARC ve SPF hizalamasını daha derin anlamak için transactional ve pazarlama e‑postaları için ayrı gönderim alanı kullanma rehberimizi da mutlaka okumanızı öneririz.

Alt Domainleri Farklı SPF Politikalarına Yönlendirmek

Eğer çok sayıda alt alan adınız varsa ve hepsinin aynı SPF politikasını kullanmasını istiyorsanız, redirect kullanarak merkezi bir alan tanımlayabilirsiniz:

_spf.example.com.   TXT "v=spf1 ip4:203.0.113.10 include:spf.servis.com -all"
mail.example.com.   TXT "v=spf1 redirect=_spf.example.com"
news.example.com.   TXT "v=spf1 redirect=_spf.example.com"

Bu yaklaşım yönetimi kolaylaştırır; ama lookup sayısını düşürmez. Yine de çok sayıda subdomain’i tek bir merkezden yönetmek istiyorsanız işe yarar. Lookup optimizasyonunu, merkez kayıt olan _spf.example.com üzerinde yapmanız gerekir.

SPF Flattening: Lookup Sayısını Düşürmenin Otomatik Yolu

Delegasyon ve sadeleştirme sonrasında hâlâ 10 lookup sınırına yakınsanız, sıradaki adım SPF flattening yaklaşımıdır. Temel fikir, ‘include:spf.servis.com’ gibi kayıtların arkasındaki IP ve IP bloklarını önceden çözüp SPF kaydınıza doğrudan ip4/ip6 olarak yazmaktır.

Statik Flattening Ne Zaman Tehlikeli?

En basit ama riskli yöntem: DNS sorgu aracınızla include ettiğiniz domainlerin SPF kayıtlarını çözersiniz, tüm ip4/ip6 değerlerini alır ve kendi SPF kayıtlarınıza yapıştırırsınız. Örneğin:

orijinal:
  v=spf1 ip4:203.0.113.10 include:spf.marketingservis.com -all

flatten edilmiş:
  v=spf1 ip4:203.0.113.10 ip4:198.51.100.0/24 ip4:192.0.2.0/25 -all

Bunun iki önemli riski var:

• Servis, zaman içinde IP aralıklarını değiştirirse SPF kaydınız güncel kalmaz.
• Özellikle büyük sağlayıcıların IP aralıkları çok geniştir; SPF kaydınız gereksiz şişebilir.

Bu nedenle statik flattening ancak belirli koşullarda, IP aralıkları uzun süre değişmeyecek küçük veya kurumsal sağlayıcılarda tercih edilmelidir. Daha dinamik ortamlarda, flattening’i otomatikleştirmek çok daha sağlıklı bir stratejidir.

Otomatik / Dinamik SPF Flattening Mimarisinin Mantığı

Daha güvenli yaklaşım, SPF flattening’i bir otomasyon süreci haline getirmektir. Örneğin:

1. Bir betik (Python, Bash vb.) belirli aralıklarla (cron, CI/CD pipeline) çalışır.
2. Betik, include ettiğiniz alanların SPF kayıtlarını çözer.
3. Ortaya çıkan ip4/ip6 listelerini konsolide eder, gereksiz tekrarları atar.
4. Oluşan yeni SPF kaydını DNS sağlayıcınıza API üzerinden yazar.

Böylece SPF kaydınız ‘yaşayan’ bir kayıt haline gelir; servisler IP adreslerini değiştirdikçe siz de periyodik olarak güncellenmiş bir flatten edilmiş kayıt kullanırsınız. Biz DCHost tarafında, büyük hacimli gönderen bazı müşteriler için bu tarz otomatik flattening akışları kurgularken, DNS hızını ve TTL değerlerini de birlikte planlıyoruz.

Bu konuyu ayrıntılı okuma ve örnek bash/CI pipeline şablonları görmek isterseniz, SPF flattening ile 10 lookup duvarını aşma rehberimizi özellikle tavsiye ederim.

E‑Posta Yönlendirme, SRS/ARC ve SPF İlişkisi

SPF ile ilgili bir başka tuzak da e‑posta yönlendirme senaryolarıdır. Kullanıcı ‘[email protected]’ adresine gelen mailleri kişisel hesabına yönlendirdiğinde, yönlendiren sunucu orijinal gönderen adına maili tekrar gönderir. SPF, kaynak IP’ye baktığı için çoğu zaman bu yeniden gönderilen maili yetkisiz olarak görür.

Bunu çözmek için geliştirilen SRS (Sender Rewriting Scheme) ve ARC (Authenticated Received Chain) gibi mekanizmalar, yönlendiren sunucunun Mail‑From alanını kendine göre yeniden yazmasına veya doğrulama zincirini korumasına izin verir. Eğer kendi mail sunucunuzu DCHost üzerindeki bir VPS’te yönetiyorsanız, Postfix/Dovecot + SRS/ARC kurulumuyla SPF ve DMARC’ı bozmadan yönlendirme yapmanız mümkündür.

Detaylı senaryolar ve pratik kurulum adımları için e‑posta yönlendirmede SPF/DMARC neden kırılıyor, SRS ve ARC ile nasıl düzeltilir rehberimize göz atabilirsiniz. SPF’i optimize ederken yönlendirme trafiğinizi de hesaba katmayı unutmayın.

IPv6 ile SPF, Reverse DNS ve Yedeklilik

Giderek daha fazla mail sunucusu IPv6 üzerinden de teslimat yapmaya başlıyor. SPF tarafında IPv6’yı tanımlamak için ip6 mekanizmasını kullanıyoruz:

v=spf1 ip4:203.0.113.10 ip6:2001:db8::1234 -all

IPv6 adresleri için de lookup limitine takılmazsınız; önemli olan, bu adreslerin gerçekten sizin mail sunucunuza ait olması ve reverse DNS (PTR) kayıtlarının doğru tanımlanmış olmasıdır. Özellikle DCHost üzerindeki VPS ve dedicated sunucularda hem IPv4 hem IPv6 üzerinden e‑posta gönderecek yapı kuruyorsanız, şu adımları kontrol etmenizi öneririz:

• IPv6 PTR kaydı: ‘mail.example.com’ gibi tutarlı bir hostname’e işaret etmeli
• Bu hostname için A ve AAAA kayıtları tanımlı olmalı
• SPF kaydınızda ip6: veya a:mail.example.com üzerinden IPv6 da yetkilendirilmiş olmalı

IPv6 ile e‑posta gönderimi ve SPF/Reverse DNS detaylarını adım adım ele aldığımız IPv6 ile e‑posta gönderimi ve teslim edilebilirlik rehberimizi özellikle teknik ekipler için öneriyoruz.

DCHost Tarafında Gelişmiş SPF Yönetimini Nasıl Kurguluyoruz?

SPF teorisini bilmek bir yana, bunu canlı sistemlerde hatasız uygulamak ayrı bir uzmanlık. DCHost tarafında farklı ölçeklerde müşteriler için genellikle şu yaklaşımı izliyoruz:

• Paylaşımlı hosting müşterileri için: cPanel DNS editörü üzerinden sade, doğrudan ip4/ip6 veya a/mx tanımları ile gereksiz include’ları temizliyoruz.
• VPS ve dedicated müşteriler için: Kendi MTA’larını yönettikleri senaryolarda, mail.example.com gibi ayrı subdomain’ler ve mümkün olduğunca doğrudan IP yetkilendirmesi kullanıyoruz.
• Çoklu servis kullanan kurumsal yapılar için: Transactional / pazarlama / operasyonel mailleri farklı subdomain’lere dağıtıp, gerekiyorsa otomatik SPF flattening pipeline’ı tasarlıyoruz.
• DMARC ve raporlama tarafında: SPF’in DMARC ile hizalamasını, RUA/RUF raporlarından düzenli olarak takip edip yanlış yetkilendirilmiş IP’leri tespit ediyoruz.

Eğer alan adınız, DNS’iniz veya mail sunucunuz DCHost üzerinde barınıyorsa, destek ekibimizle birlikte SPF kaydınızı gözden geçirip hangi include’ların gerçekten gerekli olduğunu, nerede subdomain veya flattening kullanabileceğinizi birlikte planlayabiliriz.

Özet ve Sonraki Adımlar

Gelişmiş SPF yönetimi, sadece TXT kaydına birkaç include eklemekten çok daha fazlası. Bir yandan RFC 7208’in getirdiği 10 DNS lookup sınırına uymak zorundasınız; diğer yandan DMARC hizalamasını bozmadan birden fazla e‑posta servisini aynı marka çatısı altında yönetmeniz gerekiyor. Doğru strateji genellikle şu bileşenlerin birleşiminden oluşuyor:

• Tüm gönderim kaynaklarını envanterleyip gereksiz include’ları temizlemek
• Kendi kontrolünüzdeki IP’leri doğrudan ip4/ip6 veya a/mx ile yetkilendirmek
• Transactional, pazarlama ve operasyonel mailleri ayrı subdomain’lere taşımak
• Gerekiyorsa otomatik SPF flattening pipeline’ı kurmak
• Yönlendirme, SRS/ARC ve IPv6 gibi detayları SPF ile uyumlu hale getirmek

Bir sonraki adımda, mevcut SPF kaydınızı test araçlarıyla kontrol edip ‘DNS lookups’ sayısını not alın. Ardından bu yazıdaki adımları izleyerek sadeleştirme ve delegasyon denemeleri yapın. Daha sonra, DMARC raporlarınızı inceleyerek gerçek dünyada hangi IP’lerin sizin adınıza mail gönderdiğini doğrulayın. Bu süreçte rehbere ihtiyaç duyarsanız, e‑posta teslim edilebilirliğini SPF, DKIM, DMARC ve rDNS ile adım adım yükseltme yazımız da yol gösterici olacaktır.

Eğer alan adınızı, DNS’inizi veya mail altyapınızı DCHost’a taşımayı düşünüyorsanız, ekibimiz hem SPF/DMARC tasarımı hem de VPS, dedicated veya colocation tarafında ihtiyaç duyacağınız e‑posta mimarisini birlikte planlamaya hazır. Altyapı tarafını biz stabilize ederken siz de teslim edilebilirliği ve marka itibarınızı güvenle büyütebilirsiniz.