SPF Record Optimization Tips: Fix Failures, Stay Under the 10-Lookup Limit

Yayımlanmış bir SPF kaydı, çalışan bir SPF kaydıyla aynı şey değildir. Pek çok kuruluş SPF'yi bir kez kurar, birkaç e-posta servis sağlayıcısı ekler ve bir daha üzerine gelmez. Zamanla kayıt eski girişler biriktirir, DNS arama sınırına yaklaşır ya da DMARC hatalarına sessizce yol açan hizalama uyumsuzlukları geliştirir. SPF kaydınızı optimize etmek tek seferlik bir görev değildir — e-posta teslim edilebilirliğinizi ve DMARC'ı uygulama kapasitenizi doğrudan etkileyen süregelen bir bakım işidir.

SPF Optimizasyonu Neden Önemlidir?

Etki alanınız her e-posta gönderdiğinde, alıcı posta sunucusu SPF kaydınızı arar ve gönderen IP'nin yetkili olup olmadığını değerlendirir. Bu değerlendirme, doğru hizalanmış bir etki alanıyla pass dışında bir sonuç döndürürse DMARC SPF başarısız olur. Bozuk bir SPF kaydı anında daha düşük DMARC geçme oranlarına yol açar; bu da DMARC politikanızı none'dan quarantine veya reject'e taşıma kapasitenizi etkiler.

SPF kaynaklı DMARC hatalarının yaygın nedenleri arasında DNS arama sınırını aşmak (permerror), kaydınızda listelenmeyen bir IP'den göndermek veya MAIL FROM alanında sizin etki alanınız yerine kendi etki alanını kullanan bir e-posta servis sağlayıcısı bulunmaktadır. Bu sorunların her birinin belirli bir çözümü vardır — ancak önce bunları bulmak için görünürlüğe ihtiyacınız vardır.

10 DNS Arama Sınırının Altında Kalın

RFC 7208 katı bir sınır tanımlar: tek bir SPF kaydını değerlendirmek 10'dan fazla DNS araması tetiklememelidir. Arama tüketen mekanizmalar şunlardır: include, a, mx, ptr ve exists. ip4 ve ip6 mekanizmaları DNS çözümlemesi gerektirmez ve bu nedenle sınıra dahil edilmez.

İşin zor kısmı, sınırın özyinelemeli olmasıdır. Her include bir arama sayılır; ancak başvurulan etki alanındaki include mekanizmaları da sayılır. Tek bir include:_spf.google.com, dahili olarak iki veya üç ek aramaya çözümlenebilir. Mailchimp, HubSpot, Salesforce ve bir işlemsel posta sağlayıcısı eklediğinizde farkına varmadan 10 aramayı aşabilirsiniz.

Sınır aşıldığında sonuç permerror'dur — DMARC için SPF başarısızlığı olarak sayılan kalıcı bir hata. Mevcut aramalarınızı saymak için kaydınızdaki her mekanizmayı denetleyin ve tetiklediği aramaları özyinelemeli olarak sayın. Sınıra yakın bir kaydın örneği şöyledir:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net include:_spf.salesforce.com include:mail.zendesk.com ~all

Bu kayıt, üst düzeyde zaten beş include mekanizması kullanmaktadır. Bunların her biri ek iç içe geçmiş aramalara başvurabilir ve toplamın 10'u aşması son derece olasıdır. Ekleyeceğiniz her yeni ESP sizi permerror bölgesine taşıma riski taşır.

SPF Kaydınızı Düzleştirin

SPF düzleştirme, include başvurularını çözümlendikleri gerçek IP adresleri veya CIDR aralıklarıyla değiştirir. İç içe aramalar yoluyla birçok IP aralığına çözümlenen include:_spf.google.com yerine ham IP bloklarını doğrudan listelersiniz:

v=spf1 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.233.160.0/19 ~all

ip4 ve ip6 mekanizmaları DNS çözümlemesi gerektirmediğinden, tamamen düzleştirilmiş bir kayıt sıfır arama tüketirken düzinelerce gönderim IP'si listeleyebilir. Bu, 10 arama sınırına ulaşma riskini tamamen ortadan kaldırır.

Dezavantajı bakımdır. E-posta servis sağlayıcıları IP aralıklarını periyodik olarak değiştirir. Statik düzleştirilmiş bir kaydınız varsa ve bir ESP yeni bir gönderim IP'si eklerse, siz kaydınızı güncelleyene kadar o IP'den gelen e-postalar SPF'de başarısız olur. ESP IP aralığı değişikliklerini takip etmek için güvenilir bir sürece ihtiyacınız vardır ya da düzleştirilmiş kaydınızı otomatik olarak güncel tutan yönetilen bir SPF hizmeti kullanmanız gerekir. Yönetilen SPF hizmetleri genellikle, sağlayıcının yukarı akış IP aralıkları her değiştiğinde sizin adınıza güncellediği sağlayıcı tarafından yönetilen bir alt alana işaret eden tek bir include kullanır.

Kullanılmayan Include'ları Kaldırın

SPF kayıtları zamanla birikir. Her yeni e-posta aracı, CRM entegrasyonu veya pazarlama platformu eklenir — ancak eski satıcılar nadiren kaldırılır. İki yıl önce kullanmayı bıraktığınız eski bir işlemsel e-posta sağlayıcısı hâlâ SPF kaydınızda olabilir; değerli 10 aramadan birini veya daha fazlasını tüketerek artık denetlemediğiniz bir IP aralığını yetkili kılıyor olabilir.

Include'larınızı denetlemek için:

1. Mevcut SPF kaydınızdaki her include'u listeleyin.
2. Her include için karşılık geldiği e-posta hizmetini belirleyin.
3. Kuruluşunuzun bu hizmet üzerinden bugün aktif olarak e-posta gönderip göndermediğini teyit edin.
4. Bir hizmet artık kullanımda değilse, include'unu kaydınızdan kaldırın.
5. Gerçekte hangi gönderim IP'lerinin göründüğünü görmek için DMARC toplu raporlarınızı inceleyin — mevcut araç yığınınızda olmayan her IP kaldırma adayıdır.

Yaygın eski girişler arasında eski pazarlama otomasyon platformları (Marketo, Pardot, Mailchimp'in eski sürümleri), değiştirilen işlemsel sağlayıcılar (SendGrid, Mandrill, SparkPost) ve artık yapılandırılmamış giden e-posta kapasitesine sahip CRM araçları bulunur. İki veya üç iç içe arama içeren tek bir kullanılmamış include bile, permerror'a ulaşmadan yeni meşru bir gönderici eklemek için yeterli alan açabilir.

Hizalama Sorunlarını Düzeltin

SPF geçişi otomatik olarak DMARC geçişi anlamına gelmez. DMARC, SPF tarafından kimlik doğrulaması yapılan etki alanının — MAIL FROM etki alanı, diğer adıyla zarf göndereni veya return-path — görünür Header-From adresindeki etki alanıyla hizalanmasını gerektirir. ESP'niz kendi etki alanını MAIL FROM olarak kullanırsa, SPF onların etki alanı için geçer, sizinki için değil; ve DMARC SPF hizalaması başarısız olur.

Bu, üçüncü taraf e-posta platformları kullanan kuruluşlar için en yaygın DMARC hatası kaynaklarından biridir. Çözüm, ESP'nizde bir özel return-path yapılandırmaktır — ESP'nin MAIL FROM adresi olarak kullandığı kendi etki alanınızın bir alt alanı. Örneğin MAIL FROM olarak bounce.sendgrid.net yerine em.yourdomain.com yapılandırırsınız. DMARC gevşek hizalaması (varsayılan) altında, em.yourdomain.com yourdomain.com ile hizalanır ve SPF hizalaması geçer.

Büyük ESP'lerin çoğu özel return-path etki alanlarını destekler:

• Mailchimp — Kitle ayarlarında özel bir etki alanı yapılandırın; kayıt şirketinizde CNAME gerektirir.
• SendGrid — Ayarlar → Gönderici Kimlik Doğrulaması bölümünde özel return path ile etki alanı kimlik doğrulamasını kurun.
• HubSpot — Özel MAIL FROM alt alanıyla bağlı bir e-posta gönderim etki alanı yapılandırın.
• Amazon SES — Doğrulanmış kimlik ayarlarınızda özel bir MAIL FROM etki alanı kullanın.
• Salesforce Marketing Cloud — Özel etki alanı ve özel geri dönme etki alanı aracılığıyla yapılandırma.

Özel bir return-path yapılandırdıktan sonra, MAIL FROM etki alanına yönelik SPF kontrolünün geçmesi için o alt alanın SPF kaydını da eklemeniz (veya kök etki alanınızın SPF'sine dahil etmeniz) gerekir. Bazı ESP'ler bunu otomatik olarak yapar; diğerleri alt alan için belirli bir include eklemenizi gerektirir.

~all Yerine -all Kullanın

SPF kayıtlarının çoğu ~all (softfail) ile biter; bu şu anlama gelir: kaydında listelenmeyen IP'lerden gelen e-postalar muhtemelen yetkili değildir, ancak alıcı sunucular bunları teslim etmeye devam edebilir. Bu, hâlâ tüm gönderim altyapınızı keşfettiğiniz başlangıç dağıtımı sırasında uygundur. Ancak ~all'da süresiz kalmak kaçırılmış bir fırsattır.

-all'a (fail) geçmek, alıcı posta sunucularına SPF kaydınızda açıkça listelenmeyen herhangi bir IP'nin etki alanınız için posta göndermeye kesinlikle yetkili olmadığını bildirir. DMARC reject politikasıyla birleştirildiğinde bu, sahte e-postalara karşı mümkün olan en güçlü sinyali sağlar.

Ne zaman geçiş yapmak güvenlidir? SPF kaydınızın kendi posta sunucularınız, tüm ESP'ler, işlemsel sağlayıcılar ve sizin adınıza gönderen otomatik sistemler dahil tüm meşru gönderim kaynaklarını kapsadığından emin olduğunuzda. DMARC izlemeniz varsa, geçiş yapmadan önce meşru kaynaklar için SPF geçme oranınızın tutarlı biçimde yüksek olduğunu (ideal olarak %95'in üzerinde) kontrol edin. Kalan hataların önce teşhis edilip çözülmesi gerekir.

Önemli bir ayrıntı: -all'a karşı ~all, DMARC uygulamasını doğrudan etkilemez. Alıcıların etki alanınız için kimlik doğrulama hatalarını nasıl ele aldığını yöneten DMARC politikasıdır (p=none, p=quarantine, p=reject). Ancak -all kullanmak belirsizliği ortadan kaldırır ve SPF duruşunuzu tam uygulama pozisyonuyla hizalar.

DMARCFlow Nasıl Yardımcı Olur?

Bir SPF kaydını yalıtılmış olarak optimize etmek ayrı bir şeydir. Bunu, birden fazla gönderim hizmetinde gerçek e-posta trafiği bağlamında doğru şekilde yapmak, gerçekte neler olduğuna dair görünürlük gerektirir. DMARCFlow bu görünürlüğü doğrudan DMARC toplu raporlarınızdan sağlar.

• Permerror tespiti. DMARCFlow, DMARC raporlarınızdaki tüm kayıtlarda her permerror sonucunu işaretler. 10 arama sınırı temel neden olduğunda, yalnızca SPF'nin başarısız olduğunu değil, kaydınızı düzleştirmeniz veya kullanılmayan include'ları kaldırmanız gerektiğini açıkça ortaya koyar.
• Kayıt başına SPF hizalama içgörüsü. Gelen her DMARC raporundaki her kayıt, DMARC politikanızın hizalama moduna göre ayrı ayrı analiz edilir. DMARCFlow yalnızca SPF'nin geçip geçmediğini değil, kimlik doğrulaması yapılmış MAIL FROM etki alanının Header-From adresinizle hizalanıp hizalanmadığını da belirler. Hangi gönderenlerin hizalama ile geçtiğini, hangilerinin hizalama olmadan geçtiğini (ve dolayısıyla DMARC'ta başarısız olduğunu) ve hangilerinin doğrudan başarısız olduğunu bir bakışta görebilirsiniz.
• Gönderim kaynağı dökümü. DMARCFlow sonuçları gönderim kaynağına göre — IP adresi ve raporlanan kaynak etki alanı — gruplandırır; böylece hizalama hatalarına hangi ESP veya sunucunun neden olduğunu tam olarak belirleyebilirsiniz. Bu, önce hangi return-path yapılandırmasını düzelteceğinizi kolayca anlamanızı sağlar.
• Öneri motoru. Gerçek verilerinize dayanarak DMARCFlow önceliklendirilmiş, eyleme dönüştürülebilir öneriler üretir. Belirli bir ESP'de hizalanmamış bir MAIL FROM DMARC hatalarına neden oluyorsa öneri size ne yapılandıracağınızı ve hangi sağlayıcıda yapacağınızı söyler. Arama sayınız sınıra yaklaşıyorsa, permerror'a ulaşmadan önce bunu işaretler.
• Olgunluk izleme. SPF hizalaması, etki alanınızın DMARC olgunluk düzeyine doğrudan katkıda bulunur. DMARCFlow size tam olarak hangi optimizasyonların daha yüksek olgunluk düzeylerine ulaşmak ve none'dan tam reject uygulamasına güvenli şekilde geçmek için gerekli olduğunu gösterir.

Mevcut SPF kaydınızı anında incelemek, DNS aramalarınızı saymak ve teslim edilebilirliği etkilemeden önce yanlış yapılandırmaları tespit etmek için DMARCFlow SPF Denetleyicisini kullanın.