Exchange Online 550 5.7.708 Access Denied Hatası Çözümü (2026)

Xen Bilişim ekibi · Microsoft Bulut Çözüm Ortağı — CSP Direct Partner (2016+) · MS-100/MS-102/AZ-104 sertifikalı danışmanlar

Özet (TL;DR): Exchange Online'dan giden e-postalar geri dönüp 550 5.7.708 Access denied, traffic not accepted from this IP hatası veriyorsa, sorun posta kutunuzda veya alıcıda değil — kiracınızın (tenant) gönderdiği IP adresinin itibar puanının düşük çıkmasındadır. Bu neredeyse her zaman yeni kurulan, deneme (trial) sürümünde ya da az sayıda lisanslı kiracılarda görülür: Microsoft, itibarı henüz oturmamış kiracıları geçici olarak sınırlar. Kalıcı çözüm kendi başınıza bir ayarı değiştirmek değil — Exchange Online lisansını tam atamak ve Microsoft 365 yönetim merkezinden destek talebiyle IP istisnası istemektir. Bu yazıda tam hata mesajını, benzer üç hata koduyla farkını, Message Trace ile hızlı teşhisi, adım adım çözümü ve tekrarlamaması için alınacak önlemleri anlatıyoruz.

Kiracınızda e-posta teslimat sağlığını (SPF/DKIM/DMARC + IP itibarı) ücretsiz taratmak isterseniz bize yazın — sorunu siz fark etmeden önce yakalayalım.

Belirtiler ve tam hata mesajı

Bu sorunun en tipik görünümü şudur: kurumunuzda az önce lisans alınmış ya da deneme sürümünde açılmış bir Microsoft 365 kiracısından dışarıya e-posta gönderiyorsunuz — Outlook'tan, bir yazılımın SMTP entegrasyonundan ya da bir web sitesinin iletişim formundan. Gönderim başarısız oluyor ve gelen kutunuza şu içerikte bir geri dönüş (NDR — non-delivery report, yani "iletilemedi" bildirimi) düşüyor:

550 5.7.708 Service unavailable. Access denied, traffic not accepted from this IP. [Your organization's] messages haven't been accepted because sending IP has poor reputation.

Bazı sürümlerde mesaj kısaca 5.7.708 Access denied, traffic not accepted from this IP şeklinde de görünür. Bu hata; alıcının posta kutusu dolu olduğu için değil, alıcı sunucusu iletiyi reddettiği için değil — Exchange Online'ın kendisi iletiyi göndermeden önce durdurduğu için oluşur. Yani sorun her zaman gönderen tarafta, yani sizin kiracınızdadır.

Bu hata sık karıştırıldığı üç benzer NDR koduyla birlikte değerlendirilmelidir — kök nedenleri ve çözüm yolları tamamen farklıdır:

Bu yazı özellikle 550 5.7.708 senaryosunu — yani gerçek bir yapılandırma hatası olmadan, sırf kiracı yeni olduğu için oluşan itibar tabanlı engellemeyi — uçtan uca çözer. Dış alıcıya toplu gönderim sınırına takıldıysanız (5.7.232/5.7.233), bu farklı bir konudur; ayrıntısı için Exchange Online dış alıcı gönderim sınırı (TERRL) çözümü yazımıza bakabilirsiniz. Kimlik doğrulama kaynaklı gönderim hataları (535 5.7.139) için ise SMTP AUTH hatası çözümü yazımız geçerlidir.

Kök neden: IP itibarı ve "yüksek riskli teslimat havuzu"

Microsoft 365, milyonlarca kiracının e-postasını aynı paylaşılan IP adresi havuzlarından gönderir. Bu havuzların alıcı sunucular (Gmail, Yandex, kurumsal posta sistemleri vb.) nezdinde iyi bir "itibarı" olması, e-postalarınızın spam kutusuna düşmeden ulaşması için hayati önemdedir. Microsoft bu itibarı korumak için iki katmanlı bir sistem kullanır:

• Normal teslimat havuzu: Lisanslı, geçmişi olan, düzenli ve temiz e-posta gönderen kiracıların trafiği buradan akar.
• Yüksek riskli teslimat havuzu (high-risk delivery pool): Spam olarak işaretlenmiş iletiler, geri dönüş (NDR/bounce) mesajları ve — kritik olarak — henüz itibarı oturmamış yeni/deneme kiracıların bir kısım trafiği buraya yönlendirilir. Amaç, olası kötü niyetli kullanımın normal havuzun itibarını zedelememesidir.

Yeni açılan ya da deneme sürümünde olan bir kiracının henüz "iyi gönderici" olduğunu kanıtlayacak bir geçmişi yoktur. Microsoft bu belirsizlik döneminde ihtiyatlı davranır ve bazı yeni kiracıların outbound (giden) trafiğini 5.7.708 ile geçici olarak sınırlar — tam olarak kötüye kullanım tespit ettiği için değil, henüz güven inşa edilmediği için. Bu, gerçek bir yapılandırma hatanızın sonucu değildir; bu yüzden SPF/DKIM/DMARC kayıtlarınız kusursuz olsa bile hata devam edebilir.

Aynı kısıtlama, üçüncü taraf bir gönderim aracı (örneğin bir web sitesi formu, pazarlama otomasyonu veya eski bir SMTP relay entegrasyonu) kiracınız üzerinden gönderim yaptığında da görülebilir — özellikle o entegrasyon kiracı henüz yeniyken devreye alındıysa. Microsoft Q&A'da 2026 içinde bu hatayı bildiren onlarca yönetici, ortak noktanın "kiracı yeni açıldı" veya "deneme sürümündeyiz, lisans atanmadı" olduğunu doğruluyor.

Hızlı tanı: 4 kontrolle sorunu doğrulayın

Destek talebi açmadan önce, hatanın gerçekten 5.7.708 olduğunu ve başka bir nedenden kaynaklanmadığını doğrulayın:

1. NDR mesajının tam metnini okuyun. "Access denied, traffic not accepted from this IP" ve "poor reputation" ifadelerini arayın — bu ifade varsa neredeyse kesin 5.7.708'dir, "exceeded threshold" ifadesi varsa 5.7.705'tir, farklı bir konudur.
2. Exchange yönetim merkezinde Message Trace (mesaj izleme) çalıştırın. admin.exchange.microsoft.com > Mail flow > Message trace yolundan giden iletiyi arayın; durum sütununda "Failed" görünür ve ayrıntı panelinde tam NDR kodu okunur. Bu adım, sorunun gerçekten gönderim aşamasında mı yoksa alıcı tarafında mı olduğunu netleştirir.
3. Exchange Online lisansının tam atanıp atanmadığını kontrol edin. Microsoft 365 yönetim merkezi > Kullanıcılar > Etkin kullanıcılar'da ilgili posta kutusunun lisans durumuna bakın. Deneme (trial) lisansları ve henüz atanmamış lisanslar bu kısıtlamaya en açık gruptur.
4. Kiracının yaşını ve geçmişini değerlendirin. Kiracı son birkaç hafta içinde mi açıldı? Daha önce düzenli gönderim yapılmış mı? Yeni kiracılarda bu hatanın görülme olasılığı önemli ölçüde daha yüksektir.

Adım adım çözüm

Bu hata, diğer birçok Exchange Online hatasının aksine, kiracı tarafında bir ayar değiştirerek çözülemez — çünkü kısıtlama Microsoft'un paylaşılan altyapısında, kiracı dışında uygulanır. Doğru sıra:

1. Exchange Online lisansını tam atayın. Deneme sürümündeyseniz ve gerçek kullanıma geçiyorsanız, ilgili posta kutularına kalıcı Exchange Online / Microsoft 365 lisansını atayın. Lisanssız veya yalnızca deneme lisanslı gönderim, itibar değerlendirmesinde dezavantajlıdır.
2. Microsoft 365 yönetim merkezinden destek talebi açın. admin.microsoft.com > Destek > Yeni istek üzerinden "Exchange Online" kategorisinde bir talep oluşturun. Talebe şunları ekleyin: tam NDR metni, etkilenen gönderen posta kutusu adresi, gönderim yöntemi (Outlook / Outlook on the web / bağlayıcı / üçüncü taraf entegrasyon) ve yaklaşık gönderim tarih-saatleri.
3. IP istisnası talep edin. Destek ekibinden, kiracınız için geçici bir "IP address exception" (IP istisnası) uygulamasını isteyin. Microsoft, lisanslama tamamlandıktan ve gönderim geçmişi normalleştikten sonra bu istisnayı uygulayabilir.
4. Bekleme süresince gönderimi durdurmayın, izleyin. İstisna uygulanana kadar Message Trace ile gönderimleri izlemeye devam edin; bazı iletiler normal havuzdan geçmeye başlayabilir çünkü itibar değerlendirmesi mesaj bazında da değişkenlik gösterebilir.
5. Çözüldükten sonra izleme moduna geçin. İstisna sonrası birkaç hafta boyunca Message Trace'te "OutboundIpPoolName" alanını (aşağıda anlatıyoruz) kontrol ederek trafiğin normal havuzdan aktığını doğrulayın.

Destek talebinde kullanabileceğiniz örnek özet cümlesi: "Kiracımız <kiracı adı>, <tarih> itibarıyla giden e-postalarda 550 5.7.708 Access denied, traffic not accepted from this IP hatası alıyor. Exchange Online lisansı <durum>. IP itibarı/istisnası için destek rica ediyoruz." Böyle net bir özet, destek sürecini kısaltır.

Senaryoya özel dallar

Hatanın görüldüğü bağlama göre öncelik sırası değişir:

• Tamamen yeni kiracı, henüz lisans atanmamış: Önce lisansı tam atayın, sonra destek talebi açın. Lisanssız denemede gönderim geçmişi oluşmadığı için istisna talebi de zayıf kalır.
• Mevcut, lisanslı kiracı ama az sayıda kullanıcı: Muhtemelen kiracı yaşı hâlâ Microsoft'un "yeni" eşiğinin altında. Destek talebinde kiracının kuruluş tarihini ve önceki düzenli gönderim geçmişinizi (varsa) belirtin — bu, istisnayı hızlandırır.
• Üçüncü taraf entegrasyon üzerinden gönderim (form, ERP, pazarlama aracı): Hatanın entegrasyonun kendisinden mi (yanlış SMTP ayarı, hatalı bağlayıcı) yoksa kiracı itibarından mı kaynaklandığını ayırt edin. Message Trace'te "connector_id" alanı doğru bağlayıcının kullanıldığını gösteriyorsa ve NDR yine 5.7.708 ise, sorun entegrasyonda değil kiracı itibarındadır.
• Domain sağlayıcı (ör. GoDaddy, Türk hosting firmaları) üzerinden yönlendirilen posta: Bazı yönetim panelleri e-posta ayarlarını otomatik yapılandırırken kiracıyı yanlışlıkla deneme modunda bırakabilir. Panelden lisans/plan durumunu ayrıca doğrulayın.

Yönetici tarafı önleyici kontroller

Bu hatanın tekrarlamaması ve genel gönderim itibarınızın sağlıklı kalması için:

• SPF, DKIM ve DMARC kayıtlarını eksiksiz yapılandırın. Bu üç kayıt, alıcı sunuculara e-postanızın gerçekten sizin alan adınızdan geldiğini kriptografik olarak kanıtlar ve itibar puanınızı doğrudan etkiler. Adım adım kurulum için SPF/DKIM/DMARC nasıl yapılandırılır rehberimize bakabilirsiniz.
• Outbound (giden) e-posta politikalarını gözden geçirin. Microsoft Defender portalında istenmeyen e-posta (anti-spam) giden politikalarınızın gönderim limitlerini ve kısıtlama davranışını inceleyin; olağandışı ani hacim artışları da benzer engellemeler tetikleyebilir.
• Message Trace'i düzenli izleyin. Özellikle yeni kiracılarda ilk 60-90 gün boyunca giden trafiğin hangi havuzdan (OutboundIpPoolName alanı) geçtiğini haftalık kontrol edin; erken uyarı, kritik bir gönderim (fatura, sözleşme, bildirim) engellenmeden önce müdahale imkânı verir.
• Kritik gönderimleri tek bir kiracıya/entegrasyona yüklemeyin. Yeni bir kiracıyı devreye alırken, ilk haftalarda hacimli/kritik toplu gönderimleri (örneğin binlerce faturayı aynı anda e-postayla iletmek) planlamayın; itibar oturana kadar kademeli artırın.

Türkiye'de bu hatanın iş etkisi neden daha büyük

Türkiye'de faaliyet gösteren kurumlar için 5.7.708 hatası salt teknik bir rahatsızlıktan fazlasıdır — doğrudan yasal ve operasyonel yükümlülüklere dokunur:

• KVKK bildirim süreçleri: 6698 sayılı Kişisel Verilerin Korunması Kanunu'nun 12. maddesi, veri sorumlularının gerekli teknik tedbirleri almasını ve olay bildirimlerini zamanında yapmasını öngörür. E-posta gönderimi engellendiğinde, ilgili kişi başvurularına yanıt, KVKK Kurulu'na yapılması gereken bildirimler veya sözleşme taraflarına yapılacak yasal bildirimler gecikebilir — bu da ayrı bir uyum riski yaratır.
• Yerli ERP ve e-fatura entegrasyonları: Logo Tiger, Netsis, Mikro Fly gibi yerli ERP sistemleri sıklıkla fatura, sipariş onayı veya GİB e-fatura bildirimlerini e-posta üzerinden otomatik gönderir. Yeni kurulan bir Microsoft 365 kiracısında bu entegrasyon devreye alındığında, 5.7.708 hatası fark edilmeden haftalarca sessizce e-posta kaybına yol açabilir çünkü gönderen taraf genelde hatayı görmez, yalnızca alıcıya ulaşmadığı anlaşılır.
• Yeni kurulan şirketlerde risk daha yüksek: Türkiye'de yeni kurulan şirketlerin büyük kısmı Microsoft 365'e doğrudan yıllık lisansla değil, önce deneme sürümüyle başlar — bu da tam olarak Microsoft'un "yeni/az itibarlı kiracı" tanımına girer. Kuruluşun ilk haftalarında kritik iletişimi (banka, resmi kurum, tedarikçi yazışmaları) bu kiracı üzerinden yürütmek, riskin fark edilmeden büyümesine yol açar.

Saha vakası: 60 kişilik bir lojistik firması

Firma X — İstanbul merkezli, 60 kişilik bir lojistik ve nakliye firması — yeni bir Microsoft 365 kiracısına Google Workspace'ten geçiş yaptı ve aynı hafta içinde muhasebe yazılımından toplu e-fatura bildirim e-postaları göndermeye başladı. İlk üç gün sorun yoktu; dördüncü günden itibaren müşterilerden "faturanızı alamadık" geri bildirimleri gelmeye başladı.

İnceleme, muhasebe departmanının kendi gelen kutusunda hiçbir hata görmediğini ortaya çıkardı — çünkü Outlook arayüzü NDR'yi ayrı bir klasöre düşürmüştü ve kimse fark etmemişti. Message Trace çalıştırıldığında giden iletilerin büyük kısmının 550 5.7.708 ile reddedildiği görüldü.

Karar noktaları: (1) kiracının kuruluş tarihi henüz üç haftalıktı, (2) muhasebe entegrasyonu için ayrılan posta kutusuna henüz kalıcı lisans atanmamıştı — geçici bir deneme lisansı kullanılıyordu, (3) hiçbir SPF/DKIM sorunu yoktu, engelleme tamamen itibar kaynaklıydı. Kalıcı lisans atandı, Microsoft 365 yönetim merkezinden destek talebi açıldı ve IP istisnası talep edildi.

Sonuç: istisna beş iş günü içinde uygulandı, gönderim normale döndü. Firma bu süreçte yaklaşık 40 fatura e-postasının hiç ulaşmadığını, bir kısmının manuel olarak tekrar gönderilmesi gerektiğini tespit etti. Xen ekibinin rolü: teşhis (Message Trace analizi), destek talebi metninin hazırlanması ve sonrasında haftalık izleme sürecinin kurulmasıydı. Uyarı: bu vaka anonimleştirilmiştir; sayılar temsili sıklık ve süreleri yansıtır.

Benzer bir geçiş sürecindeyseniz, tecrübeli bir ekiple 15 dakikalık ücretsiz teknik görüşme planlayarak riski baştan kapatabilirsiniz.

Sıkça Sorulan Sorular (SSS)

"550 5.7.708 Access denied, traffic not accepted from this IP" hatası tam olarak ne anlama gelir?

Bu, Exchange Online'ın giden e-postanızı, gönderen IP adresinin (paylaşılan Microsoft 365 altyapısındaki) itibar puanı henüz düşük veya belirsiz olduğu için reddettiği anlamına gelir. Alıcı posta kutunuzda veya iletinin içeriğinde bir sorun yoktur; kısıtlama Microsoft'un kendi gönderim altyapısında uygulanır.

Bu hatayı kiracı yöneticisi olarak kendim düzeltebilir miyim?

Hayır, doğrudan düzeltemezsiniz. Sorun kiracı ayarlarında değil, Microsoft'un paylaşılan IP havuzunda oluşur. Yapabileceğiniz tek şey Exchange Online lisansını tam atamak ve Microsoft 365 yönetim merkezi üzerinden destek talebiyle IP istisnası istemektir.

Destek talebine ne kadar sürede yanıt gelir?

Süre kiracıdan kiracıya değişir, ancak genel eğilim birkaç iş günüdür. Talebe tam NDR metnini, etkilenen posta kutusunu ve gönderim yöntemini eksiksiz eklemek süreci hızlandırır.

SPF, DKIM ve DMARC kayıtlarımı düzeltirsem hata biter mi?

Tek başına hayır — çünkü bu hatanın kök nedeni kayıt eksikliği değil, kiracı itibarıdır. Ancak SPF/DKIM/DMARC'ın eksiksiz olması genel itibarınızı güçlendirir ve istisna sonrası kalıcı olarak temiz kalmanıza yardımcı olur; bu yüzden paralel olarak mutlaka tamamlanmalıdır.

Bu hata yalnızca deneme (trial) kiracılarında mı görülür?

En sık deneme ve yeni kurulan kiracılarda görülür, ancak az sayıda lisanslı veya kısa süre önce büyük bir geçiş yapmış (örneğin başka bir sağlayıcıdan Microsoft 365'e taşınmış) kiracılarda da ortaya çıkabilir. Ortak payda her zaman "henüz oturmamış gönderim geçmişi"dir.

Message Trace'te "OutboundIpPoolName" alanını nasıl görürüm?

Exchange yönetim merkezinde bir mesaj izleme (message trace) sorgusu çalıştırıp ilgili iletiye tıkladığınızda açılan ayrıntı panelinde bu alanı görebilirsiniz; ayrıca Get-MessageTraceDetailV2 PowerShell komutuyla da sorgulanabilir. Değer "HighRisk" ise iletiniz yüksek riskli havuzdan gönderilmiştir.

Bu sorunu yaşamamak için yeni bir kiracı açarken ne yapmalıyım?

Kiracıyı açar açmaz kalıcı Exchange Online lisansını atayın, SPF/DKIM/DMARC kayıtlarını ilk günden yapılandırın ve ilk haftalarda kritik/yüksek hacimli toplu gönderimleri (fatura, kampanya) planlamayın. İhtiyaç varsa kurulum sürecinde uzman desteği alın — kurulum öncesi doğru planlama, canlıya geçtikten sonra yaşanacak gönderim kesintilerini büyük ölçüde önler.

Sonuç: itibar sorunudur, yapılandırma sorunu değil

550 5.7.708 Access denied, traffic not accepted from this IP hatası, çoğu Exchange Online hatasının aksine bir ayar hatası değil, bir itibar ve güven inşası meselesidir. Doğru teşhis sırası: önce NDR metnini ve Message Trace sonucunu okuyup hatayı benzer kodlardan (5.7.703, 5.7.705, 5.7.750) ayırın; ardından lisans durumunu ve kiracı yaşını değerlendirin; son olarak Microsoft 365 yönetim merkezinden destek talebiyle IP istisnası isteyin.

Bu süreç kendi başınıza saatler alabilir — özellikle destek talebini doğru bilgilerle ilk seferde açmazsanız gidiş gelişler haftalara uzayabilir. Yeni bir Microsoft 365 kiracısı açıyorsanız veya böyle bir hata ile karşı karşıyaysanız, SPF/DKIM/DMARC yapılandırması ve destek süreci yönetimini birlikte planlamak, kritik e-postalarınızın (fatura, sözleşme, resmi bildirim) sessizce kaybolmasını önler.

Microsoft İstanbul — Xen Bilişim ekibi olarak, kurumunuzun Exchange Online e-posta teslimat sorunlarının teşhisi, destek talebi süreci ve SPF/DKIM/DMARC + itibar yönetiminde uçtan uca destek sağlıyoruz. İletişim sayfamızdan bize ulaşın.