DMARC Başarısız ama SPF ve DKIM Geçiyor? Hizalama Düzeltmesi (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.

DMARC bir geçişten fazlasını gerektirir — SPF veya DKIM’den geçen alan, From alanınızla eşleşmelidir. Çoğu “SPF geçiyor, DMARC başarısız” postası, SPF’den sizin geri dönüş alanınızda değil, satıcının geri dönüş alanında geçiyor. Defaults.Exposed sayımına göre (2026-06-29) 261,086,232 derecelendirilmiş alanın yalnızca 7.4%‘si zorlanan DMARC politikası altında hizalı SPF geçişine sahip.

Düzeltme, karışıklığın önerdiğinden daha hızlıdır. Authentication-Results başlığını okuyarak hangi bacağın — SPF veya DKIM — yanlış alanda geçtiğini görün; ardından gönderme hizmetinizin özel alan DKIM imzalamayı etkinleştirin (genellikle birkaç CNAME ve yönlendirmeyi atlatan düzeltme) ya da özel return-path’ini ayarlayın, böylece SPF kendi alanınızda geçer. DMARC’ın ihtiyaç duyduğu tek şey bir hizalı bacaktır.

SPF ve DKIM ikisi de geçerken DMARC nasıl başarısız olabilir?

Çünkü DMARC asla “SPF geçti mi?” diye sormaz. Şunu sorar: SPF ya da DKIM, alıcınızın gördüğü From adresindeki alanla eşleşen bir alan için geçti mi? Bu ek koşul hizalama olarak adlandırılır ve DMARC’ın tüm amacıdır — bu olmadan herhangi biri kendi sahip olduğu bir alanda SPF’den geçerken sizin alanınızı From başlığında görüntüleyebilir.

Her kontrol farklı bir alanı doğrular:

Kontrol	Gerçekte değerlendirdiği alan	Nerede görünür
SPF	Return-Path (RFC5321.MailFrom, geri dönüş/zarf-from adresi) — From başlığı değil	Authentication-Results’taki `smtp.mailfrom=`
DKIM	İmzanın `d=` etiketindeki alan — imzalayanın seçtiği alan	Authentication-Results’taki `header.d=`
DMARC	*From başlığı alanınız — ve SPF alanının veya* DKIM’in `d=` değerinin bununla eşleşmesini gerektirir**	Authentication-Results’taki `header.from=`

Parçaların genellikle nasıl yanlış gittiğine dair: bülten platformunuz veya CRM’niz [email protected] gibi bir Return-Path ile posta gönderir, SPF vendor.com üzerinde kontrol edilir ve geçer, DKIM d=vendor.com ile geçer — ve DMARC başarısız olur, çünkü geçen alanların hiçbiri sizinşirket.com ile eşleşmez. Her kontrol gerçeği söyledi; hiçbiri sizi doğrulamadı. Kendi SPF kaydınızı düzenlemek bunu düzeltemez — zaten danışılmadı. Bu, SaaS araçlarınız için SPF başarısız sayfasında ele alınan tuzakla aynıdır.

Sayım, kaç gönderenin bu son adımı tamamladığını gösteriyor: 261,086,232 derecelendirilmiş alanın 27,640,987‘si (%10.59) zorunlu DMARC politikasına sahip ve yalnızca 7.4% biri altında hizalı SPF geçişine sahip. SPF’si softfail (~all) ile biten 77.5 milyon alan arasında yalnızca 9.2%‘si zorlanan DMARC politikasının altında; hardfail (-all) yayıncıları arasında 12,142,351 zorlanmışken 42,514,532‘si zorlanmamış. Çoğu alan “SPF geçiyor”da durur — DMARC olmadan bu neredeyse hiçbir şeyi korumaz.

Hangi bacağın hizasız olduğunu görmek için Authentication-Results nasıl okunur?

Başarısız hizmet üzerinden kendinize bir ileti gönderin, ham kaynağı açın ve Authentication-Results başlığını bulun. Tipik hizasız bir sonuç şöyle görünür:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=bounces.espmail.net;
       dkim=pass header.d=espmail.net;
       dmarc=fail (p=NONE) header.from=yourcompany.com

Üç karşılaştırmayla okuyun:

SPF bacağı: smtp.mailfrom= kendi alanınızla mı bitiyor? Burada bounces.espmail.net — hizasız.
DKIM bacağı: header.d= kendi alanınızla mı bitiyor? Burada espmail.net — hizasız.
DMARC kararı: header.from=, DMARC’ın savunduğu alandır. Hiçbiri bununla eşleşmedi, dolayısıyla her iki bireysel kontrol pass dese de dmarc=fail.

Kendi alanınızı zaten içeren (veya içermesi sağlanabilecek) olan bacak düzeltilecek olandır. Yalnızca bir tanesine ihtiyacınız var.

Gevşek ve katı hizalama arasındaki fark nedir?

DMARC, DMARC kaydınızdaki aspf (SPF) ve adkim (DKIM) etiketleriyle ayarlanan iki eşleştirme modu sunar:

Gevşek (r, varsayılan): İki alan Genel Sonek Listesi’ne göre aynı kuruluş alanını paylaşmalıdır. bounce.yourcompany.com, yourcompany.com ile hizalanır; d=mail.yourcompany.com olan DKIM de öyle. Satıcının özel return-path’lerinin ve alt alanlarda yaşayan özel DKIM’in işe yaramasının nedeni budur.
Katı (s): Alanlar karakter karakter tam olarak eşleşmelidir. bounce.yourcompany.com artık yourcompany.com ile hizalanmaz.

Kaydınızda aspf veya adkim yoksa gevşek modasınız — ve büyük olasılıkla orada kalmak istersiniz. Katı mod çoğu gönderen için anlamlı güvenlik eklemez ve kurduğunuz her meşru alt alan göndericiyi sessizce bozar. DMARC başarısız oluyorsa ve kaydınız aspf=s veya adkim=s içeriyorsa, bu tek başına hata olabilir.

DMARC hizalamasını nasıl düzeltirim?

DNS’e dokunmadan önce defaults.exposed üzerinden ücretsiz taramayı çalıştırın. DMARC kaydınızı ve politikanızı, SPF ve DKIM’in hizalanmak üzere kurulmuş olup olmadığını ve başka neyin bozuk olduğunu gösterir — böylece önce doğru bacağı düzeltirsiniz.
Her gönderme hizmetini test edin ve Authentication-Results okuyun (yukarıdaki gibi). Her kaynağı listeleyin — posta kutusu sağlayıcısı, bülten aracı, CRM, faturalama uygulaması — ve kaynak başına smtp.mailfrom ile header.d değerlerinin kendi alanınız mı yoksa satıcının alanı mı olduğunu not alın.
Her satıcı için özel alan DKIM imzalamayı etkinleştirin — kalıcı düzeltme. Her ciddi gönderme hizmeti “alan kimlik doğrulaması” sunar: d=yourcompany.com (veya bir alt alan, gevşek modda hizalanır) olarak imzalamasına izin veren birkaç CNAME kaydı. Hizalı DKIM genellikle daha kolay düzeltmedir ve yönlendirme tasarım gereği SPF’yi bozduğundan yönlendirmeyi atlatan tek düzeltmedir.
SPF hizalaması için satıcının özel return-path’ini etkinleştirin (genellikle özel geri dönüş alanı denir) — genellikle satıcıya işaret eden bounce.yourcompany.com gibi bir CNAME. SPF bu durumda kendi kuruluş alanınızda geçer ve hizalanır. Sunulduğu yerde bunu yapın, ama ikinci bacak olarak değerlendirin, hizalı DKIM’in yerine geçmez.
Belirli, anlaşılmış bir nedeniniz olmadıkça hizalamayı gevşek modda bırakın (aspf=s/adkim=s kullanmayın).
Yeniden tarayın ve her iki bacağı doğrulayın, ardından zorlamaya doğru ilerleyin. p=none DMARC politikası rapor eder ama hiçbir şeyi engellemez; gerçek gönderenlerin hizalandığı zaman sizi koruyan politikaya giden tam yol DMARC düzeltme sayfasında ve IONOS’ta DMARC gibi sağlayıcı kılavuzları DNS panel tıklamalarını kapsar.

SPF hizalamasını mı yoksa DKIM hizalamasını mı düzeltmeliyim?

Gönderme kaynağı başına bir hizalı bacağa ihtiyacınız var. Yalnızca birini yapabiliyorsanız seçim neredeyse hiç yakın değildir:

Düzeltme	Ne gerektirir	Yönlendirmeyi atlatır mı?
Hizalı DKIM (özel alan imzalama)	Satıcının “alan kimlik doğrulaması” panelinde birkaç CNAME	Evet — imza iletiyle birlikte yolculuk eder
Hizalı SPF (özel return-path/geri dönüş alanı)	Satıcının sunduğu yerde bir CNAME	Hayır — herhangi bir yönlendiricinin IP’si satıcınınkinin yerini alır

Bilinmesi gereken özel durum: Google Workspace ve Microsoft 365, postanızı varsayılan olarak kendi geri dönüş alanlarıyla DKIM imzalayacaktır (gappssmtp.com, onmicrosoft.com) — bu nedenle DKIM pass gösterirken DMARC hâlâ başarısız olur. Bu tüm sorunun en yaygın spesifik örneğidir ve kendi rehberi vardır: DKIM geçiyor ama DMARC hâlâ başarısız: varsayılan imza tuzağı.

Sık sorulan sorular

DMARC geçmesi için hem SPF hem de DKIM’in hizalanması gerekiyor mu? Hayır — bir hizalı geçiş yeterlidir. En iyi uygulama yine de her ikisini de hizalamaktır; böylece yönlendirme SPF bacağını bozduğunda DKIM bacağı DMARC geçişini taşımaya devam eder. 2026-06-29 sayımında derecelendirilen 261,086,232 alanın yalnızca 3.87%‘si tam SPF + DMARC + DKIM üçlüsünü tamamlar.

ESP panom SPF ve DKIM’in “doğrulandı” olduğunu söylüyor — DMARC neden hâlâ başarısız oluyor? “Doğrulandı” genellikle satıcının kendi gönderimi satıcının alanlarında geçiyor demektir. Özel alan adımlarını (DKIM CNAME’leri, özel return-path) tamamlamadıkça, posta siz değil satıcı olarak kimliğini doğrular — ve DMARC From alanınıza karşı karşılaştırma yapar.

Hizalama olmadan katı -all SPF kaydı yeterli mi? Hayır. Katı niteleyici, Return-Path alanındaki SPF kararını güçlendirir ama DMARC hâlâ bu alanın sizin olmasını gerektirir. 2026-06-29 sayımı itibarıyla -all yayımlayan alanların yalnızca 12,142,351‘si zorlanan DMARC politikasının altında — diğer 42,514,532 hiçbir politikanın işlem yapmadığı katı kayda sahip.

Daha fazla güvenlik için katı hizalamaya (aspf=s/adkim=s) geçmeli miyim? Neredeyse hiçbir zaman. Gevşek hizalama zaten aynı kayıt edilebilir alanı gerektirir; bir sahtekar bunu kontrol etmez. Katı mod çoğunlukla kendi alt alan gönderilerinizi bozar — beklenmedik hizalama başarısızlıklarında kontrol edin.

DMARC yalnızca alıcıların yönlendirdiği postada başarısız oluyor — aynı düzeltme mi? Bu, transitte ölen SPF bacağıdır: yönlendiricinin sunucusu, return-path için kimsenin SPF kaydında değildir. Yönlendirilen postada SPF’yi düzeltemezsiniz; hizalı DKIM yanıttır, çünkü imza yönlendirmeyi sağlam geçer. Detaylar: yönlendirilen e-posta SPF’de başarısız olur.

Sahiplerine raporu gönderin

Bunu bir müşteri veya işvereniniz için düzeltiyorsanız, kanıtla döngüyü kapatın. CNAME’ler yerleştikten sonra ücretsiz taramayı yeniden çalıştırın ve derecelendirilmiş raporu iş sahibine iletin: tarihli, sade dilli, SPF, DKIM ve DMARC’ın hizalı ve geçtiğini gösteriyor. Bu, siber sigorta yenileme ve bir sonraki tedarikçi güvenlik anketi için ihtiyaç duyacakları belgedir — çalışan yapılandırmanın kanıtı, “bazı DNS kayıtları ekledim”den farklı olarak.

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