Hiç SPF kaydını güncellemek için DNS’e girip “Bir daha ellemem” deyip sonra iki hafta sonra yine oraya düştünüz mü? Ben çok yaşadım. Bir müşteri, üç farklı e‑posta sağlayıcısı, üstüne bir de helpdesk sistemi eklenince SPF kaydı bir anda iplik yumağına dönüyor. O meşhur 10 DNS lookup sınırı da ansızın kapıda beliriveriyor; hop, teslim edilebilirlik düşüyor, uyarılar gelmeye başlıyor. İşte tam o gün, “Bunu otomatiğe bağlasak da kafamız rahat etse” diye düşündüm.
Bugün, SPF Flattening denen tatlı bir numarayı, üstelik CI/CD ya da Workers ile otomatik hale getirerek nasıl sorunsuz kullanabileceğini konuşacağız. Her şeyi en baştan, sakin sakin anlatacağım. Biraz hikaye, arada gerçek dünya örnekleri, derken sonunda çalışan, yaşayan bir SPF yönetimi kurmuş olacağız. E‑posta teslim edilebilirliği, DMARC hizalaması ve DNS bakım yükü derken hepsi usul usul yerine oturacak.
Yazının sonunda elinizde iki sağlam yol olacak: Kod deposuyla sürümlenen ve pipeline’da her değişiklikte kendini güncelleyen bir SPF; ve edge tarafında, yani Workers benzeri bir ortamda çalışan anlık flattening. Hangisi işinize gelirse, oradan yürürsünüz. Hadi başlıyoruz.
Nereden Çıktı Bu 10 Lookup Sınırı?
SPF, gönderici alan adının “Bu IP’lerden e‑posta göndermeme izin var” dediği basit bir TXT kayıt mantığı. Fakat o basitlik, include ve benzeri mekanizmalarda DNS’e bakma ihtiyacı doğuruyor. Her include, a, mx, exists ve redirect gibi mekanizmalar birer DNS sorgusu demek. İşte toplamda 10 sorgu sınırı var ve bunu aştığınız anda SPF değerlendirmesi başarısız olabiliyor.
Görünürde üç include kullanmışsınızdır ama onların içinde başka include’lar olabilir. Bir de MX üzerinden IP topluyorsanız, her biri ayrı bir sorgu olarak sayılabiliyor. Bir anda 10’u geçmek işten bile değil. “Ben sadece birkaç sağlayıcı kullanıyorum” diyen ekiplerin bile bu sınıra tosladığını çok gördüm, çünkü zincirleme include’lar işin rengini değiştiriyor.
Burada gizli bir başka ayrıntı daha var: Lookup sayısı çoğu zaman konfigürasyon dosyasında net görünmüyor. Bir sağlayıcı, kendi altındaki üçüncü bir include’u değiştirdiğinde, siz dokunmamış olsanız bile lookup sayınız artabiliyor. Bu da sizi beklenmedik SPF hatalarıyla baş başa bırakıyor.
Sonuç? Teslim edilebilirlik etkileniyor. Spam klasörü sürprizleri baş gösteriyor. Bir yandan DMARC’ı düzgün tutmaya çalışırken bir yandan SPF’de takılı kalmak sinir bozucu. Neyse ki çözüm var ve hoş da bir çözüm: flattening.
Bu arada, SMTP güvenliğini besleyen diğer parçaları da unutmamak lazım. Merak ederseniz, SMTP güvenliğini güçlendirme üzerine yazımız SPF’le yan yana güzel gider.
SPF Flattening Nedir, Neyi Çözer?
Flattening, kabaca “include’ları aç, IP’leri tek tek çıkar, SPF satırına doğrudan ip4/ip6 olarak yaz” demek. Yani zincirleme DNS bakışları yerine hepsini bir kerede düz bir listeye çeviriyorsun. Böylece değerlendirme sırasında ekstra lookup ihtiyacı kalmıyor, 10 sınırını takmadan ilerliyorsun.
Bu yaklaşımın tatlı yanı şu: Çalışma anında neredeyse lookup yok. SPF kaydınız, ip4:… ip6:… mekanizmalarıyla dolu düz bir yapı haline geliyor. Dışarıdaki değişimlerden daha az etkileniyorsunuz çünkü gerçekte “include” takip etmiyorsunuz. O günün gerçek IP’lerini alıp tek kayıt olarak yayınlıyorsunuz.
Dezavantaj kısmı da dürüstçe söyleyeyim: Sağlayıcı IP’leri değiştiğinde, sizin yayınladığınız düz liste eskimiş oluyor. Yani flattening tek başına statik kalırsa, bir sabah SPF’iniz gerçeği yansıtmayabilir. Çözümü basit: Otomasyon. Kayıtları düzenli aralıklarla yeniden üretip DNS’e basarsanız, sorun kökten çözülür.
Bir de pratik sınırlamalar var. TXT alanında tek parça 255 karakter sınırı gibi teknik detaylar ve toplam cevap boyutu gibi kaygılar çıkabilir. Bunun için kayıt segmentlemeyi akıllıca yapmak, gerekirse “v=spf1” satırını birden fazla tırnak parçasına bölmek işe yarar. Yani flattening sadece “IP yaz, bitsin” değil; temiz bir ambalaj da istiyor.
Özetle: Flattening, lookup derdini çözer ama güncelliği takip etme sorumluluğu getirir. O sorumluluğu da otomasyonla makineye devrettiğinizde, tek bir kayda bakıp rahat uyursunuz.
CI/CD ile Otomatik SPF Yönetimi Nasıl Kurulur?
Benim favorim, SPF’yi bir kod deposunun içine almak. Basit bir script düşünün: Alan adınızın planlanan include’larını okuyor, her birini recursive şekilde çözüp IP’leri topluyor, tekrarları ayıklıyor, sonra da “v=spf1 ip4:… ip6:… ~all” şeklinde tek bir satır üretiyor. Bu çıktı dosyasını pipeline’ın sonunda DNS’e yazdırıyorsunuz.
Script tarafı için dil seçimi özgürdür. Küçük bir Python betiği gayet yeterli. Mesela “include:” içeren TXT kayıtlarını çekip iç içe çözmek, “a” ve “mx” mekanizmalarını IP’ye indirgemek, ardından büyük bir set içinde birleştirmek. Sonrasında da karakter sınırını koruyacak şekilde uygun yerlerden boşluk ekleyip tırnakları bölmek. Çalışınca, günlük ya da saatlik tetikleyip güncel bir SPF üretirsiniz.
Pipeline tarafında ise bir Git push, belirli aralıkta cron tetiklemesi veya manuel onay akışı kullanılabilir. Depoya yeni bir sağlayıcı eklendiğinde script yeniden koşar, kayıt güncellenir, DNS API’sine bir çağrı gider. Cloudflare, Route 53 veya kendi DNS sunucunuza API üzerinden yazmak mümkün. Bu, hataları azaltıp süreçleri izlenebilir kılıyor.
Çalışan örnekleri görmek isterseniz, GitHub Actions belgeleri iyi bir başlangıç sunuyor. Basit bir workflow dosyasıyla, “her akşam 03:00’te çalış, çıktıyı üret, DNS’e koy” gibi kurallar yazabilirsiniz. Dahası, test aşamasında SPF metnini doğrulayan küçük kontroller ekleyip beklenmedik durumları pipeline’da yakalarsınız.
DNS altyapısını kodla yönetiyorsanız işiniz daha da kolay. Örneğin Terraform kullanıyorsanız, pipeline son çıktıyı Terraform değişkenine aktarıp apply adımında DNS kayıtlarını güncelleyebilirsiniz. Bu yaklaşımı adım adım görmek isterseniz, Terraform ile DNS otomasyonu yazımız size fikir verecektir.
Son dokunuş olarak gözlem katmanı eklemek güzel olur. Pipeline çıktısını Slack’e atmak, SPF boyutunu ve lookup tahmini ölçümlerini loglamak, gerekirse “fail‑safe” moduna düşmek gibi küçük lüksler, büyük geceleri kurtarır. Bozulduğunda haber veren sistem, bozulmayan sistemdir.
Workers ile Kenarda Akıllı SPF: Anlık, Hafif ve Hızlı
Bir başka yaklaşım da edge’de, yani kullanıcının en yakınında çalışan küçük bir uygulamaya işi devretmek. Cloudflare Workers gibi hafif ortamlar, SPF flattening’i anlık üretip yayınlamaya oldukça uygun. Basitçe anlatayım: Workers, belirlediğiniz bir endpoint’e gelen istekte SPF’yi dinamik üretip cevaplayabiliyor, sonra DNS tarafında TXT kaydınızı bu endpoint ile entegre edebiliyorsunuz.
Burada iki yol var. Birincisi, Workers tarafı belirli aralıklarla sağlayıcıların SPF’lerini çözüp ip’leri KV veya Durable Object içinde saklar; DNS ise bu üretilmiş düz listeyi TXT kaydı olarak servis eder. İkincisi, SPF istenirken anlık çözüm yapıp cevaplamak. İkincisi pratikte dikkat istiyor, çünkü lookup gecikmesini e‑posta değerlendirme yoluna sokmak istemezsiniz.
Genellikle “önceden üret, kenarda tut” yaklaşımı daha sağlıklı. Workers, arkada belirli periyotlarla günceller, üretir ve saklar. Böylece bir kesinti ya da sağlayıcı değişikliğinde en fazla bir kaç saatlik gecikmeyle yeni liste devreye girer. Gerekirse bir butonla elle tetikleme de ekleyebilirsiniz.
Bu tarz bir mimariyi kurcalamak isterseniz, Cloudflare Workers dokümantasyonu yapı taşlarını oldukça anlaşılır anlatıyor. Küçük bir fetch ile TXT kayıtlarını çekip iç içe çözmek, ardından KV’de tek anahtarda tutmak yeterli. DNS tarafında da TXT kaydını sık değiştirmeden aynı içeriğe işaret etmiş olursunuz.
Workers’ın güzelliği, düşük maliyetle yüksek esneklik sunması. Ayrıca beklenmedik büyümeleri akıllıca karşılar. Yine de unutmayın, e‑posta değerlendirme katmanına dinamik bileşen sokarken her zaman bir “statik yedek” bulundurmak iyi fikirdir. Bozulursa statik moda dönün, düzelince tekrar dinamik yayınlayın.
Kenar Köşe: Uzunluk Sınırı, TTL, Fail‑Safe ve Diğer Tuzaklar
SPF kaydı metin olarak uzun olabiliyor. DNS TXT alanında tek bir tırnak içinde 255 karakter sınırını unutmayın. Bu sınırı aşmak için kaydı birden fazla tırnak parçasına bölebilirsiniz. Çözücü taraf bunları birleştirir. Ama okunabilirlik ve yönetilebilirlik için satırı akıllıca segmentlemek büyük rahatlık sağlar.
Toplam DNS yanıt boyutu da bir başka pratik konu. Modern çözümler genelde büyük yanıtları idare ediyor ama risk iştahına göre, IP listesini çok şişirmemek iyi. Gereksiz aralıkları birleştirmek, CIDR kullanmak ve tekrar eden IP’leri temizlemek kayıt boyutunu doğal şekilde azaltır. Script’inize küçük bir “minify” adımı ekleyin.
TTL konusu kritik. Çok kısa TTL, her değişiklikte dünya kadar yeniden sorgu demek ve bazen gereksiz yük getirir. Çok uzun TTL ise sağlayıcı IP değişiminde yeni kaydın yayılmasını geciktirir. Ben genelde orta bir değerde kalıp, kritik güncellemeler öncesi TTL’i geçici olarak düşürmeyi seviyorum. Otomasyon varsa bu işlemi pipeline’a gömebilirsiniz.
Fail‑safe olmazsa olmaz. Otomatik üretimde beklenmedik bir hata olduğunda, mevcut çalışan SPF’yi koruyun. Script başarısız olursa “en son iyi bilinen” çıktıyı yeniden yazmayın. Bunun yerine hatayı bildirip güncellemeyi atlayın. Bu küçük prensip büyük arızaları önler.
“include” yerine “redirect” kullanımı da bazen karşımıza çıkar. Redirect, aslında “tüm politikayı başka yere taşırım” demek. Flattening dünyasında genellikle redirect’i minimal tutmak, hatta hiç kullanmamak daha temiz olur. Çünkü amaç lookup tüketmeyen, tek parça bir politika yayınlamak. Yine de bazı kurumsal şemalarda redirect işe yarayabilir; dikkatli planlamak gerekir.
SPF’in detaylarına bazen dönüp bakmak iyi olur. Standart, hangi mekanizmanın nasıl sayıldığını ve sınırları net tarif ediyor. Merak edenler için SPF standardının (RFC 7208) metni elinizin altında dursun. Okurken bile kıvılcımlar çakıyor; script’inizde neleri kapsamanız gerektiğini netleştiriyor.
İzleme, Raporlama ve Yaşayan Bir SPF
SPF tek başına bir kahraman değil. DMARC’la el ele yürüdüğünde esas gücünü gösteriyor. Raporlar, hizalama ve politikanın etkisi gibi konuları takip ettiğinizde, hataları erkenden yakalıyorsunuz. Bu konuda pratik ve yol gösterici bir kaynak arıyorsanız, Gelişmiş DMARC ve BIMI rehberi işin mutfağını güzel anlatır.
Ben izleme için küçük metrikler seviyorum: Üretilen IP sayısı, kayıt boyutu, pipeline süresi, son başarılı koşu zamanı ve DNS yayılım penceresi. Bu metrikleri panoya koyduğunuzda, bir şey ters gittiğinde gözünüz alışmış oluyor. Ayrıca mail akışında beklenmedik bir düşüş görürseniz, önce bu panoya bakıp “SPF tarafı sağlıklı mı?” diye sorun.
Altyapı olarak kendi e‑posta sunucunuzu işletiyorsanız, SPF’in etkisini yerinde görürsünüz. Kuyruk davranışı, geri dönüşler ve greylisting gibi detaylarda SPF’nin dokunuşu bariz olur. Bu tarafa ilgi duyuyorsanız, Postfix + Dovecot ile e‑posta sunucusu kurma rehberimiz pratik bakış sağlar.
Bir de ucu SMTP tarafına dokunan güvenlik katmanları var. En başta bahsetmiştim; MTA‑STS, TLS‑RPT ve DANE/TLSA gibi çözümler, SPF ve DMARC’ın yanına konunca posta akışı daha istikrarlı hale geliyor. Bu seti yavaş yavaş oturtmak, “bugün SPF düzeldi, yarın TLS raporlarına bakalım” gibi küçük adımlarla çok daha kolay.
Kapanış: Basit Başla, Otomatikle Büyüt
Toparlayalım. SPF Flattening, include labirentini düz bir yola çeviriyor. 10 lookup sınırıyla pazarlık etmiyor, onu kibarca devre dışı bırakıyor. Ama bunun sürdürülebilir olması için otomasyon şart. Ya CI/CD ile sürümlenen, test edilen ve DNS’e otomatik yazan bir akış kuracaksınız ya da Workers gibi bir kenar ortamında akıllı bir üret‑sakla modeli kullanacaksınız. İkisi de olur, önemli olan sizin ekibin ritmine uyması.
Başlarken küçük bir alan adında deneyin. Script’inizi yazın, bir iki sağlayıcıyı çözün, IP’leri düzleştirin, TXT uzunluğunu yönetin ve fail‑safe’i kurun. Her şey yolunda gidiyorsa, TTL ayarlarını düşünerek ana alanınıza taşırsınız. Bu arada DMARC raporlarına göz atmadan geçmeyin; sorunları en hızlı onlar fısıldar.
Daha derine dalmak isterseniz, SPF’nin sahada nasıl nefes aldığına dair parçaları birbirine bağlayın. SMTP şifreleme ve teslimat katmanını daha sağlam kurmak için güvenlik rehberimizi ve altyapı otomasyonu için de Terraform ile DNS otomasyonu yazımızı bırakıyorum. Umarım bu yazı, SPF tarafında “Of yine mi include!” dedirten günlerinizi keyifli bir otomasyonla geride bırakır. Bir sonraki yazıda görüşürüz.
