Defaults.Exposed › Düzeltmeler › Guides

Outlook E-postanızı Reddediyor: 550 5.7.515, 550 5.7.509 ve compauth=fail Açıklandı ve Düzeltildi (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.

İki farklı Microsoft sistemi postaları reddeder. Tüketici Outlook.com, kimlik doğrulamasında başarısız olan yüksek hacimli göndericileri reddeder (550 5.7.515, Mayıs 2025’ten beri uygulanmakta); Exchange Online, kendi DMARC reddetme politikanızda başarısız olan postaları reddeder (550 5.7.509). spf.protection.outlook.com’u yetkilendiren 10,205,070 alandan 85.0%‘si katı SPF’ye sahip ama Defaults.Exposed’un 261,086,232 alan sayımına göre yalnızca 21.7%‘si DMARC’ı zorluyor.

“Outlook e-postamı reddediyor” sorunlarının çoğu aslında red değildir — postalar, başlıklarda compauth=fail ile sessizce Gereksiz’e düşmektedir. Bu rehber Microsoft kodlarını çözümler, Authentication-Results başlığını nasıl okuyacağınızı gösterir ve düzeltmeyi sırasıyla yürütür: SPF’yi doğrulayın, özel alanınız için DKIM’i etkinleştirin, DMARC yayımlayın ve zorunlu kılın, yeniden test edin.

Gerçekte hangi Microsoft hatasına sahipsiniz?

Microsoft iki ayrı alım yüzeyi çalıştırır ve farklı nedenlerle reddeder. Önce semptomunuzu eşleştirin — yanlış tanı bir günü boşa harcatır.

Tam NDR ifadesi değişir; alıntıladığınız dizeleri güvenmeden önce canlı geri dönüşe karşı doğrulayın.

550 5.7.515 ne anlama gelir?

Bu, Microsoft 365 kiracı hatası değil tüketici Outlook.com/Hotmail gereksinimidir. Mayıs 2025’ten beri, tüketici Outlook adreslerine günde 5.000’den fazla ileti gönderenler SPF’yi geçirmeli, DKIM’i geçirmeli ve From alanıyla hizalı bir DMARC kaydı (en az p=none) yayımlamalıdır. Bu çıtayı kaçırın ve tüketici Outlook şunun gibi bir ifadeyle reddeder:

550 5.7.515 Access denied, sending domain [yourdomain.com] does not meet the required authentication level.

Bu iki şey değildir: 2026 zorunluluğu değildir (postaları yeni yeni geri dönmeye başladıysa, hacminiz veya DNS’iniz değişti, kural değil) ve alıcının M365 kiracı ayarlarıyla ilgili değildir. Düzeltme, aşağıdaki kimlik doğrulama merdivendir — günde 5.000’i geçen ara sıra kampanya günleri de sayılır.

550 5.7.509 ne anlama gelir?

Bu, kurumsal kiracılardaki Exchange Online Protection’dan gelir ve kendi DMARC politikanızın uygulandığı anlamına gelir:

550 5.7.509: Access denied, sending domain [yourdomain.com] does not pass DMARC verification and has a DMARC policy of reject.

Bunu dikkatle okuyun — bu Microsoft’un güçlük çıkarması değildir. Alanınız p=reject yayımlıyor, bu ileti DMARC’ta başarısız oldu ve alıcı tam istediğinizi yaptı. Geri dönen posta meşruysa, bir gönderme kaynağı (bülten aracı, CRM, tarama-e-posta cihazı) hizalı biçimde kimlik doğrulaması yapmıyor. Politikayı zayıflatmayın; o kaynağa hizalı SPF veya DKIM verin — bkz. DMARC düzeltme ve p=none’dan p=reject’e.

Outlook neden geri döndürmek yerine compauth=fail ile postaları gereksiz’e atıyor?

Microsoft teslim edilebilirlik ağrısının çoğu hiçbir zaman geri dönüş üretmez. İleti kabul edilir, puanlanır ve Gereksiz’e atılır — tek kanıt Authentication-Results başlığıdır. Alıcının posta kutusunda (veya kendi outlook.com test posta kutunuzda) iletiyi açın, İleti kaynağını görüntüle’yi seçin ve şu satırı bulun:

Authentication-Results: spf=pass ... dkim=fail ... dmarc=fail action=none ... compauth=fail reason=001

compauth, Microsoft’un bileşik kimlik doğrulama kararıdır: bir alan DMARC kaydı yayımlamıyor olsa bile Microsoft örtük, DMARC benzeri kontroller uygular. Yaygın olarak görülen değerler:

• compauth=fail reason=000 — ileti açık kimlik doğrulamada başarısız oldu: alanınızın DMARC politikası quarantine/reject ve ileti bunda başarısız oldu.
• compauth=fail reason=001 — ileti örtük kimlik doğrulamada başarısız oldu: alanınız kayıt yayımlamıyor (veya yeterli değil) ve ileti sizden gelmiş gibi görünmüyor. Klasik “hiç DKIM/DMARC kurmadık” imzası.
• compauth=fail reason=6xx — örtük kimlik doğrulama başarısızlığı varyantları; 601 özellikle gönderen alanın kendi kabul edilen alanlarınızdan biri olduğu anlamına gelir (kuruluş içi kimlik sahteciliği, kendine gönderme).

Ders: Microsoft’ta yalnızca NDR’yi değil, başlığı okuyun. Aynı satırdaki spf=, dkim= ve dmarc= kararları tam olarak hangi bacağı düzelteceğinizi söyler.

Outlook reddini ve gereksiz’e atmayı nasıl düzeltirsiniz?

1. Önce ücretsiz taramayı çalıştırın. SPF, DKIM ve DMARC’ı tek geçişte derecelendirir ve DNS’e dokunmadan önce hangi bacağın başarısız olduğunu gösterir.
2. SPF’yi doğrulayın — Microsoft 365’te genellikle zaten iyidir. Standart kayıt v=spf1 include:spf.protection.outlook.com -all’dır ve M365 kurulumu bunu oraya koyar: spf.protection.outlook.com’u yetkilendiren 10,205,070 alanın 85.0%‘si zaten katı -all ile bitiyor (2026-06-29 itibarıyla). Bir güvenlik rayı: alıcılar SPF’yi From başlığına değil, Return-Path (RFC5321.MailFrom) alanına karşı değerlendirir — dolayısıyla bir bülten aracı sizinkinde hiçbir şey yapmadan kendi geri dönüş alanında SPF’yi geçebilir. Bu nedenle adım 3 ve 4 daha önemlidir.
3. Özel alanınız için DKIM’i etkinleştirin — iki seçici CNAME. M365, özel alan imzalamayı açana kadar hizasız onmicrosoft.com varsayılanıyla imzalar: kiracınızın anahtarlarına işaret eden selector1._domainkey ve selector2._domainkey CNAME’lerini yayımlayın, ardından Defender portalında imzalamayı etkinleştirin. Tam tıklama yolu: Microsoft 365’te DKIM kurulumu. DKIM “geçiyor” gösterirken DMARC hâlâ başarısız oluyorsa varsayılan imza tuzağındasınız.
4. DMARC yayımlayın, ardından zorunlu kılın. Rapor almak için v=DMARC1; p=none; rua=mailto:... ile başlayın, ortaya çıkardığı her meşru kaynağı düzeltin, ardından p=quarantine ve p=reject’e kademe kademe geçin — aşamalı yol DMARC düzeltme sayfasındadır. Çoğu Microsoft kurumunun atladığı adım budur: M365 gönderen alanların yalnızca 21.7%‘si DMARC’ı zorluyor.
5. Başlığı okuyarak yeniden test edin. Bir tüketici outlook.com posta kutusuna gönderin, ileti kaynağını açın ve spf=pass, dkim=pass, dmarc=pass ve compauth=pass olduğunu doğrulayın.
6. Yüksek hacimli göndericiler: tüketici-Outlook çıtasını karşılayın. Günde 5.000’in üzerinde ayrıca geçerli, izlenen From/yanıtla adresi, çalışan abonelik iptali ve temiz listeler gereklidir — kimlik doğrulama 5.7.515’i temizler; şikâyet oranı S3140/S3150 IP bloklarından uzak tutar. IP zaten bloklandıysa SPF/DKIM/DMARC’ı düzeltmek bloğu kaldırmaz: Microsoft’un gönderici desteği üzerinden listenin kaldırılmasını isteyin ve kimlik doğrulamayı geri dönmeme nedeniniz olarak değerlendirin.

Bu kadar çok Microsoft 365 alanı neden hâlâ başarısız oluyor?

Çünkü varsayılan, ilk adımı sizin için yapar, geri kalanını yapmaz. spf.protection.outlook.com’u yetkilendiren 10,205,070 alan arasında 85.0%‘si kurulumda M365’in verdiği katı SPF kaydını taşıyor; ancak Defaults.Exposed’un 261,086,232 alan sayımına göre yalnızca 21.7%‘si DMARC’ı zorluyor. M365 varsayılan olarak katı SPF veriyor, ardından çoğu kiracı orada duruyor — tam da compauth’un yakalamak için inşa edildiği popülasyon (yine de tüm derecelendirilmiş alanlar genelinde 10.59%‘lik DMARC zorlamasının önünde). Tam sağlayıcı karşılaştırması: e-posta sağlayıcısı SPF lig tablomuz.

Sık sorulan sorular

550 5.7.515 bir Microsoft 365 hatası mı? Hayır. Tüketici Outlook.com/Hotmail’den gelir ve Mayıs 2025’ten beri uygulanmakta; günde >5.000 ileti gönderenleri hedefler. Kurumsal Exchange Online redleri farklı kodlar kullanır — en yaygın 550 5.7.509 (DMARC reddetme politikanız) veya 5.7.511 (yasaklı gönderici).

550 5.7.509 aldık ama posta meşruydu — p=reject’i düşürmeli miyiz? Hayır — politikanız kimlik doğrulamasız bir kaynağı yakaladı; bu onun çalışmasıdır. Kaynağı başlıkta veya DMARC raporlarınızda bulun ve ona hizalı DKIM (veya hizalı SPF) verin. p=none’a zayıflatmak herkes için tam alan adı kimlik sahteciliğini yeniden açar.

compauth=fail biri bizi taklit ettiği anlamına mı gelir? Mutlaka değil. reason=001 genellikle kendi postanızın sizden geldiğini kanıtlayamadığı anlamına gelir — hizalı DKIM yok, DMARC yok. 10,205,070 M365 gönderen alanın yalnızca 21.7%‘si DMARC’ı zorluyor (2026-06-29 itibarıyla); dolayısıyla Microsoft herkese örtük kontroller uygular ve kimlik doğrulamasız meşru postalar da bunlarda başarısız olur.

Günde 5.000’den az e-posta gönderiyorum — bunu görmezden gelebilir miyim? 550 5.7.515’i atlatırsınız; ama Gereksiz klasörünü değil: compauth herhangi bir hacimde uygulanır. Gmail aynı oyunu oynuyor — bkz. Gmail 550 5.7.26 rehberi. Düzeltmeler ücretsizdir; bariyer farkındalıktır, maliyet değil.

Sahiplerine raporu gönderin

E-postayı başkası için düzeltiyorsanız — bir müşteri, patronunuz, faturaları geri dönen firma — işi kanıtla bitirin. DNS yerleştikten sonra ücretsiz taramayı yeniden çalıştırın ve derecelendirilmiş raporu iletin. SPF, DKIM ve DMARC’ın iş sahibinin okuyabileceği sade İngilizce ile yeşile geçtiğini gösterir; bir sonraki siber sigorta yenileme veya müşteri güvenlik anketi “e-postanız kimlik doğruluyor mu?” diye sorduğunda ihtiyaç duyacakları belgedir. Düzeltmek iyidir; kanıtlanabilir biçimde düzeltilmiş olmak size ödeme alır ve onların güvencede olmasını sağlar.

Alanınızı ücretsiz kontrol edin

Microsoft’un sizi SPF, DKIM, DMARC’ın hangi bacağında başarısız bıraktığını — gizli ve yalnızca sahip olarak — görün.

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