Defaults.Exposed › Düzeltmeler › Guides

Yönlendirilen E-posta SPF'de Başarısız Oluyor — Neden Düzeltemezsiniz ve Gerçekte Ne İşe Yarar (2026)

Yayımlanma 2026-07-08

Veriler 2026-06-29 itibarıyla · metodoloji v7. 261 milyon derecelendirilmiş alan genelinde toplu sayım verileri. Bkz. nasıl derecelendiriyoruz.

Yönlendirilen e-posta için SPF’yi geçiremezsiniz — yönlendirme, SPF’yi tasarım gereği bozar ve dürüst düzeltme, yönlendirmeyi atlatan hizalı DKIM’dir. Ölçek sayım genelindedir: Defaults.Exposed’un 261 milyon alan sayımına göre SPF yayımlayan 138,927,207 alandan 7,355,985‘si yalnızca Namecheap’in yönlendirme include’ını yetkilendiriyor; katı SPF payı <0.1%.

Aşağıda: yazabileceğiniz hiçbir SPF kaydının yönlendirmeyi neden atlatamadığı, SRS ve ARC’nin neden kontrol edemediğiniz araçlar olduğu ve işe yarayan düzeltme — DMARC geçişiniz olarak kendi alanınızla DKIM imzalama — ve DKIM’i de bozan tek durum (iletileri yeniden yazan posta listeleri) ile bu kalıntıyla ne yapacağınız.

Yönlendirme neden SPF’yi bozar?

Alıcılar SPF’yi Return-Path (RFC5321.MailFrom) alanına karşı değerlendirir, From başlığına değil. Doğrudan gönderdiğinizde, sunucunuzun IP’si SPF kaydınızda bulunur ve kontrol geçer. Alıcınız iletiyi otomatik olarak yönlendirdiğinde — kişisel Gmail’e, üniversite takma adı üzerinden veya bir kayıt şirketinin yönlendirme ürünü aracılığıyla — yönlendiricinin sunucusu iletiyi yeniden iletir; genellikle Return-Path’te alanınızı tutar. Son alıcı şimdi sorar: bu yönlendirme sunucusu sizin SPF kaydınızda yetkilendirilmiş mi?

Değildir ve hiçbir zaman olmayacaktır: yönlendiriciyi siz seçmediniz, var olduğunu bilmiyorsunuz ve yarın farklı bir hizmet üzerinden yönlendirilen aynı ileti, farklı bir IP’den başarısız olur. SPF tek bir soruyu yanıtlar — “Bu IP, Return-Path alanının yetkilendirdiği bir sunucudan mı geldi?” — ve yönlendirilmiş posta için gerçek yanıt hayır. Başarısızlık, kaydınızın yanlış olmasından değil, belirtildiği gibi çalışan SPF’dendir.

Sayım bu yolun ne kadar ana akım olduğunu gösteriyor: 7,355,985 alan Namecheap’in e-posta yönlendirme include’ını (spf.efwd.registrar-servers.com) yetkilendiriyor — 139 milyon SPF yayıncısından tek bir sağlayıcının yönlendirme ürünü — katı SPF payı <0.1% ve yalnızca 0.2%‘si DMARC’ı zorluyor. O yumuşak şablon dikkatsizlik değildir: yönlendirme tam da katı -all’ın yanlış ateşlediği yerdir ve ürünü yönlendirme olan sağlayıcı buna göre sunar. Tam niteleyici hikâyesi ~all ile -all raporu’nda ve hangi e-posta sağlayıcısı en güçlü SPF’yi veriyor sayfasında sağlayıcı bazında karşılaştırma mevcut.

Yönlendiricinin sunucusunu SPF kaydıma ekleyemez miyim?

Hayır — ve nedeni bu makalenin tamamıdır:

1. Yönlendiricileri listeleyemezsiniz. Herhangi bir alıcı, herhangi bir yerde, postanızı herhangi bir hizmet üzerinden yönlendirebilir. SPF kaydınızın önceden bilemeyeceğiniz sunucuları listelmesi gerekir.
2. Onları listelemek amacı bozar. Büyük yönlendirme hizmetleri, milyonlarca müşteri için posta iletir. Kendi adreslerinizi kaydınıza koyarsanız, kullanıcılarından herhangi birinin ilettiği her ileti — sahtecirinki dahil — siz olarak SPF’den geçer.

Aynı mantık, “yönlendirmenin çalışmasını sağlamak” için niteleyicinizi gevşetmeyi de reddeder: niteleyici yönlendirilmiş postanın başarısız olmasının nedeni değildir ve DMARC devreye girdiğinde çoğu rehberin iddia ettiğinden daha az şey değişir — bkz. niteleyici verisi. Kayıt buradaki kaldıraç değildir. Onu çekmeyi bırakın.

SRS ve ARC’ye ne dersiniz — yönlendirmeyi düzeltmiyorlar mı?

Buna değinirler — ama ne biri ne de diğeri dağıtmanız için araçlardır:

Veriler ve mekanizma durumu 2026-06-29 itibarıyla.

SRS, yönlendiricinin SPF sorununu çözer, sizin değil: Return-Path’i yeniden yazmak kimin SPF’sinin kontrol edildiğini değiştirir; DMARC’ın savunduğu alan olan From başlığınız değişmez. ARC, altyapı operatörleri arasında bir güven kararıdır. Bir rehber size alan sahibi olarak “SRS’yi uygula” diyorsa, sizi yönlendirme sağlayıcısıyla karıştırmıştır.

E-postamın yönlendirmeden nasıl sağ çıkmasını sağlarım?

Alanınıza hizalı DKIM’i DMARC geçişiniz yapın. Bir DKIM imzası, ileti başlıklarında taşınan kriptografidir: imzalanan içerik değiştirilmediği sürece, ileti nereye varırsa varsın, kaç sunucu iletmiş olursa olsun, doğrulanır. DMARC yalnızca bir hizalı geçişe ihtiyaç duyar — SPF veya DKIM — dolayısıyla yönlendirme SPF bacağını öldürdüğünde, hizalı DKIM iletiyi kimlik doğrulanmış olarak tutar.

1. DNS’e dokunmadan önce defaults.exposed üzerinden ücretsiz taramayı çalıştırın. DKIM’e sahip olup olmadığınızı, kendi alanınızla imzalayıp imzalamadığınızı ve DMARC’ınızın nerede durduğunu gösterir — böylece gerçek açığı düzeltirsiniz, SPF kaydınızla savaşmak yerine.
2. Yönlendirmenin gerçekten sorununuz olduğunu doğrulayın. Etkilenen bir iletinin Authentication-Results başlığında, doğrudan posta SPF’den geçerken yönlendirilmiş kopya yönlendirme hizmetinin IP’sinden başarısız olur. SPF ve DKIM geçerken DMARC hâlâ başarısız oluyorsa, bunun yerine bir hizalama sorununuz var demektir — bkz. DMARC başarısız ama SPF ve DKIM geçiyor.
3. Her gönderme hizmetinde kendi alanınızla DKIM imzalamayı açın — önce posta kutusu sağlayıcısı, ardından ESP’ler ve işlemsel gönderenler. Sağlayıcı varsayılanları çoğunlukla sağlayıcının alanıyla imzalar; bu hizalanmaz; d=alanınız istiyorsunuz. DKIM nasıl düzeltilir’dan başlayın; Google Workspace ve Microsoft 365 için tıklama yollarıyla.
4. Yalnızca geçişi değil hizalamayı doğrulayın. İmzadaki d= alanı, From alanınızla eşleşmelidir; başkasının alanında dkim=pass, DMARC’ınız için hiçbir şey yapmaz.
5. SPF kaydınıza dokunmayın. Doğrudan posta için doğru tutun — trafiğinizin çoğunu hâlâ doğrular ve ikinci DMARC bacağınız olmaya devam eder. Yalnızca onu yönlendiricileri kapsatmak için kullanmayı bırakın.
6. Yeniden tarayın, ardından DMARC zorlamasını kasıtlı olarak aşamalı yapın — bir sonraki bölüm ve p=none’dan p=reject’e dağıtım rehberi.

Bu kombinasyon — SPF ile hizalı DKIM’e dayanan DMARC zorlaması — yönlendirmeye dayanıklı modeldir ve nadirdir: ~all yayımlayan 77.5 milyon alandan yalnızca 9.2% (7,116,774) zorlamalı DMARC politikasıyla destekliyor; sayıma göre 261 milyon derecelendirilmiş alanın (2026-06-29) yalnızca 3.87% (10,092,481) tam SPF + DKIM + zorlanan DMARC üçlüsünü tamamlar.

İletileri yeniden yazan posta listeleri hakkında ne yapmalı?

Hizalı DKIM’in atlatamadığı tek yönlendirme yolu: [liste-adı] konu etiketi, abonelik iptal altbilgisi, kaldırılan ek gibi iletiyi değiştiren posta listeleri. İmzalı içeriği değiştirin ve gövde karması artık eşleşmez; dolayısıyla DKIM da başarısız olur (dkim=fail: body hash did not verify bu başarısızlığın kendi rehberidir). Artık her iki DMARC bacağı da ölüdür ve yalnızca liste bunu hafifletebilir (From yeniden yazma, ARC mühürleme).

Bu kalıntı tam da aşamalı DMARC zorlamasının var olma nedenidir. Toplu raporları izlerken pct artışıyla p=quarantine üzerinden geçiş, p=reject politikası onu reddetmeye başlamadan önce gerçek postanızın ne kadarının yeniden yazan listelere aktığını gösterir. Kullanıcıları posta listelerinde yaşayan bir alanda reject’e atlamayın; ama sonsuza dek p=none’da da durmayın. Aşamalı dağıtım rehberi artışı anlatır.

Sık sorulan sorular

Yönlendirme DKIM’i de bozar mı? Düz yönlendirme, hayır: imza iletiyle birlikte yolculuk eder ve son alıcıda doğrular. DKIM yalnızca imzalanan içerik transit sırasında değiştirildiğinde bozulur — posta listesi konu etiketleri ve altbilgileri klasik durumdur — bu nedenle liste kalıntısı, DNS’teki herhangi bir şeyle değil DMARC politika aşamalandırmasıyla yönetilir.

Yönlendirmenin başarısız olmaktan vazgeçmesi için -all’dan ~all’a geçmeli miyim? Niteleyiciyi değiştirmek yönlendiricilerin geçmesini sağlamaz — başarısız olmalarının nedeni bu değildir. Çarpıcı olan, Namecheap’in yönlendirme include’ının (7,355,985 alan ve sayımın en büyük özel yönlendirme popülasyonu, 2026-06-29) katı SPF payının <0.1% olmasıdır: yumuşak SPF, yönlendirme ürünü için tartışmalı biçimde doğru şablondur. Niteleyicinin gerçekte neyi değiştirdiği için ~all ile -all raporu’na bakın.

Postam doğrudan gönderildiğinde SPF’den neden geçiyor ama birisi yönlendirdiğinde başarısız oluyor? Alıcı, son iletim sunucusunun IP’sinin Return-Path alanının SPF kaydı tarafından yetkilendirilip yetkilendirilmediğini kontrol eder. Doğrudan: sunucunuz, kaydınızda, geçiyor. Yönlendirilmiş: yönlendiricinin sunucusu, kaydınızda değil, başarısız. Kaydınız değişmedi — iletim IP’si değişti.

SRS kurarak bunu düzeltebilir miyim? Yalnızca yönlendirici sizseniz. SRS, yönlendirmeyi yapan sunucuda çalışır; ve çalıştığı yerde bile ortaya çıkan SPF geçişi yönlendiricinin alanına aittir; From’unuzla hizalanmaz — DMARC’ınız hâlâ DKIM bacağına ihtiyaç duyar.

Yönlendirme onu zaten bozuyorsa SPF anlamsız mı? Hayır. Postaların çoğu doğrudan teslim edilir; orada SPF tam olarak amaçlandığı gibi çalışır ve iki DMARC bacağınızdan biri olmaya devam eder. Sayımdaki (2026-06-29) 261,086,232 alandan 138,927,207‘si SPF yayımlar — SPF düzeltme sayfası aracılığıyla kaydınızı doğru tutun ve DKIM’in yönlendirilen kalıntıyı taşımasına izin verin.

Sahiplerine raporu gönderin

Bunu bir müşteri veya işvereniniz için düzeltiyorsanız, kanıtla döngüyü kapatın. Özel alan DKIM canlıya geçtikten ve DMARC aşamalandırıldıktan sonra ücretsiz taramayı yeniden çalıştırın ve derecelendirilmiş raporu iş sahibine iletin: tarihli, sade dilli, postası yönlendirildikten sonra bile kimlik doğrulamasının sürdüğünü gösteren. Bu, siber sigorta yenileme ve bir sonraki tedarikçi anketi için gerekli belgedir — “bir şeyi açtım” değil, öncesi ve sonrası belgelenmiş.

Alanınızı kontrol edin → · DMARC başarısız ama SPF ve DKIM geçiyor → · DKIM’i düzelt → · Nasıl derecelendiriyoruz → · Yalnızca toplu veriler. Veriler AB’de depolanır ve işlenir.