Exchange Online Posta Akışı Sorunları: Message Trace ve NDR Analizi

“Postam gitmedi” şikâyetinde ilk soru şudur: mesaj Exchange Online’a hiç ulaştı mı? Bu soruya cevap vermeden kural, filtre ya da DNS kurcalamak saatleri boşa harcar. Teşhis, mesajın hangi noktada durduğunu bulmakla başlar; message trace, Exchange Online PowerShell ve teslim edilemedi raporları (NDR) bunun araçlarıdır. Aşağıda posta akışı sorunlarını hangi sırayla ayrıştırdığımızı veriyoruz. SPF, DKIM ve DMARC tasarımı kapsam dışında; odak, teslim edilmeyen postanın operasyonel teşhisi.

İlk sınıflandırma: sorun hangi grupta

Teşhise başlamadan sorunu dört gruptan birine yerleştirin. Bakacağınız aracı bu belirler:

Kullanıcıdan şunları alın: gönderen ve alıcı adresi, yaklaşık gönderim zamanı (saat dilimiyle), konu satırı ve varsa NDR’nin tam metni. Ekran görüntüsü değil, metin isteyin. Ekran görüntüsünde sunucu adları ve durum kodları kesilir; teşhis bilgisi kaybolur.

Message trace ile mesajın yolunu bulma

Exchange yönetim merkezinde Mail flow > Message trace bölümü, belirli bir zaman aralığında gönderen, alıcı, mesaj kimliği veya teslim durumuna göre arama yapar. Her sonuçta mesajın durumu görülür:

• Delivered: Mesaj alıcı posta kutusuna veya dış sunucuya teslim edildi.
• Failed: Teslim başarısız; ayrıntıda NDR nedeni görülür.
• Pending: Teslim deneniyor veya yeniden denenecek; genellikle hedef sunucuya erişim sorunu vardır.
• Quarantined: Mesaj karantinaya alındı.
• FilteredAsSpam: Mesaj spam olarak işaretlendi.
• Expanded: Dağıtım grubu üyelerine genişletildi; üyelerin durumu ayrıca izlenir.

Mesajın ayrıntısında olaylar sırasıyla listelenir: RECEIVE, TRANSPORT RULE, SPAM, SEND, DELIVER, DEFER, FAIL gibi. Posta bir kural tarafından yönlendirilmiş, silinmiş veya karantinaya alınmışsa, olay satırında hangi kuralın veya politikanın devreye girdiği yazar. “Delivered” görünen ama kullanıcının bulamadığı postada sahada en sık çıkan sonuç, kullanıcının kendi Outlook gelen kutusu kuralıdır; o, sunucu tarafında iz bırakmaz.

PowerShell ile mesaj izleme

Toplu sorgu ve filtre için Exchange Online PowerShell daha hızlıdır. Microsoft, eski Get-MessageTrace ve Get-MessageTraceDetail cmdlet’lerinin yerine Get-MessageTraceV2 ve Get-MessageTraceDetailV2 cmdlet’lerini getirmiştir; tenant’ınızda hangisinin kullanılabildiğini modül sürümünüzle doğrulayın. Get-MessageTraceV2 90 günlük veriyi sorgulayabilir, ancak tek sorgudaki başlangıç–bitiş aralığı 10 günü aşamaz. Uzun dönemleri parçalara bölün.

Connect-ExchangeOnline

# Son 2 günde belirli alıcıya gelen ve başarısız olan mesajlar
Get-MessageTraceV2 -RecipientAddress "satis@ornek.com.tr" `
  -StartDate (Get-Date).AddDays(-2) -EndDate (Get-Date) -Status Failed |
  Select-Object Received, SenderAddress, Subject, Status, MessageTraceId

# Bir mesajın olay ayrıntısı
Get-MessageTraceDetailV2 -MessageTraceId "<MessageTraceId>" `
  -RecipientAddress "satis@ornek.com.tr" |
  Select-Object Date, Event, Action, Detail

Kullanıcının elinde mesaj varsa en kesin arama ölçütü Message-ID başlığıdır; -MessageId parametresiyle doğrudan aranır. Konu satırı yanıltır. Aynı konu onlarca mesajda tekrar edebilir.

Sık NDR kodları ve anlamları

NDR’deki genişletilmiş durum kodu (X.Y.Z) sorunun sınıfını verir. İlk hane 4 ise geçici hatadır ve yeniden denenir; 5 ise kalıcıdır. Exchange Online’da sık görülen kodlar:

NDR’nin altındaki “Diagnostic information for administrators” bölümü, hatayı üreten sunucunun adını gösterir. Konsolda ilk bakılacak yer burasıdır. Hata Exchange Online sunucusundan (*.prod.outlook.com veya *.protection.outlook.com) geliyorsa sorun tenant yapılandırmasındadır; karşı tarafın sunucusundan geliyorsa alıcı tarafın politikası veya filtresi devrededir. Kodların tam listesi ve önerilen çözümler Microsoft’un Exchange Online NDR ve SMTP hataları dokümanındadır. Şüpheli bir postanın başlık zincirini okumanız gerekirse başlık analizi ve Received zinciri rehberi yol gösterir.

Bağlayıcılar ve hibrit posta akışı hataları

Bağlayıcılar (connector), Exchange Online ile şirket içi sunucu altyapısı, iş ortakları veya üçüncü taraf filtreleme hizmetleri arasındaki posta akışını tanımlar. Hibrit Exchange ortamlarında Hybrid Configuration Wizard, “Inbound from…” ve “Outbound to…” adlı bağlayıcıları oluşturur. Hibrit posta akışı genellikle bir sertifika yenilemesinin ertesi sabahı bozulur. Sık sorunlar:

• Sertifika uyuşmazlığı: Gelen bağlayıcı, şirket içi sunucuyu TLS sertifikasındaki ada göre tanır (TlsSenderCertificateName). Yenilenen sertifikanın konu adı değiştiyse posta tenant’a ilişkilendirilemez.
• Süresi dolmuş sertifika: Şirket içi Exchange’in giden TLS sertifikasının süresi dolunca hibrit posta akışı durur; mesajlar şirket içi kuyrukta bekler.
• Yanlış akıllı ana bilgisayar: Giden bağlayıcının hedef sunucu adı veya IP’si değiştiyse mesajlar “Pending” durumunda kalır ve sonunda 4.4.7 ile döner.
• Yazıcı ve uygulama gönderimi: Çok işlevli yazıcılar ve iş uygulamaları için IP tabanlı gelen bağlayıcı tanımlanmadıysa veya gönderim kimlik doğrulamasız yapılıyorsa 5.7.57 ya da 5.7.64 hataları görülür.

Get-InboundConnector | Format-List Name, Enabled, ConnectorType, SenderIPAddresses, TlsSenderCertificateName, RequireTls
Get-OutboundConnector | Format-List Name, Enabled, SmartHosts, RecipientDomains, TlsSettings, UseMXRecord

# Giden bağlayıcıyı test alıcısıyla doğrulama
Validate-OutboundConnector -Identity "Outbound to Sube" -Recipients "test@sube.ornek.com.tr"

Yönetim merkezindeki bağlayıcı doğrulama sihirbazı aynı testi yapar ve başarısız adımı gösterir. Hibrit kurulumun geçiş sırasındaki ayrıntıları için Exchange Online geçiş yöntemleri rehberine bakabilirsiniz.

Kabul edilen alan adları ve MX doğrulama

Kabul edilen alan adının (accepted domain) türü, dizinde bulunmayan alıcıya gelen postanın ne olacağını belirler:

• Authoritative: Tüm alıcılar Exchange Online’dadır. Dizinde olmayan alıcıya gelen posta, dizin tabanlı sınır engelleme (DBEB) ile 5.4.1 koduyla reddedilir.
• InternalRelay: Alıcıların bir kısmı başka bir sistemdedir. Dizinde bulunmayan alıcılar için posta giden bağlayıcı üzerinden diğer sisteme aktarılır.

Hibrit geçişte şirket içinde kalan ve dizine senkronize edilmemiş posta kutuları varsa alan adı InternalRelay olmalıdır. Geçiş bitince Authoritative’e çevirmek, olmayan adreslere gelen istenmeyen postayı sınırda keser. Bu çevirmeyi unutmak da, erken yapmak da posta kaybettirir.

Get-AcceptedDomain | Select-Object DomainName, DomainType, Default

# DNS tarafı: MX kaydını kontrol etme
Resolve-DnsName -Name ornek.com.tr -Type MX

MX kaydı, Microsoft 365 yönetim merkezindeki alan adı kurulum sayfasında gösterilen değere işaret etmelidir. Araya bir üçüncü taraf filtreleme hizmeti konduysa MX o hizmete gider; bu durumda Exchange Online’da o hizmetten gelen postayı tanıyan bir gelen bağlayıcı ve gerekiyorsa gelişmiş filtreleme (enhanced filtering for connectors) yapılandırılmalıdır. Dışarıdan bakış için Microsoft Remote Connectivity Analyzer’daki gelen SMTP testi, MX’in ve tenant’ın dış dünyadan nasıl göründüğünü doğrular.

Posta akış kuralları: sessiz kayıpların kaynağı

Posta akış kuralları (transport rule) mesajı yönlendirebilir, reddedebilir, karantinaya alabilir veya sessizce silebilir. Kullanıcı “NDR yok ama posta da yok” diyorsa ilk şüpheli bir kuraldır. Mesaj izleme ayrıntısında TRANSPORT RULE olayı ve kural kimliği görülür.

Get-TransportRule | Sort-Object Priority |
  Select-Object Priority, Name, State, Mode, Comments

• Kuralların öncelik sırası belirleyicidir; “diğer kuralları işlemeyi durdur” seçeneği alttaki kuralları devre dışı bırakır.
• Mode değeri Audit veya AuditAndNotify olan kural test modundadır ve eylem uygulamaz; yalnız Enforce modundaki kurallar mesajı değiştirir.
• Ek boyutu, dış alıcı veya anahtar kelime koşullu kurallar, iş birimlerinin habersiz eklediği istisnalarla çakışabilir. Her kurala açıklama ve sahip bilgisi yazın; altı ay sonra kuralı kimin, neden eklediğini kimse hatırlamaz.

Sorun giderme kontrol listesi

• Gönderen, alıcı, zaman ve NDR metni toplandı.
• Mesaj izlemede mesaj bulundu; bulunmadıysa gönderen taraf ve MX incelendi.
• Mesajın durumu ve olay ayrıntısı okundu; karantina, spam veya kural eylemi kontrol edildi.
• NDR kodu ve hatayı üreten sunucu belirlendi.
• Bağlayıcıların sertifika, IP ve hedef ayarları doğrulandı.
• Kabul edilen alan adının türü ve MX kaydı kontrol edildi.
• Kalıcı bir yapılandırma değişikliği yapıldıysa değişiklik kaydı tutuldu ve test postasıyla doğrulandı.

Sıra önemlidir. Önce iz, sonra yapılandırma.

Tenant birleşmesi veya alan adı taşıma sonrasında görülen posta akışı sorunları için tenant-to-tenant geçiş planı yazısındaki kesim adımlarını da gözden geçirin. Exchange Online işletimi ve periyodik kontroller için Microsoft 365 ve bulut hizmetleri ile teknik destek ve periyodik bakım sayfalarımıza bakabilirsiniz.

Sık sorulan sorular

Message trace sonuçları ne kadar geriye gider?

Exchange Online mesaj izleme verisi 90 gün geriye kadar sorgulanabilir. Yakın tarihli mesajlar yönetim merkezinde ve PowerShell’de doğrudan görüntülenir; daha eski veya çok sayıda mesaj içeren sorgular için indirilebilir rapor kullanılır. Güncel süre ve sorgu sınırları için Microsoft dokümantasyonunu kontrol edin.

Mesaj izlemede görünmeyen bir posta ne anlama gelir?

Mesaj Exchange Online’a hiç ulaşmamıştır. Gönderenin sunucusu, MX kaydı, araya giren bir filtreleme hizmeti veya gönderenin kendi kuyruğu incelenmelidir. En hızlı yol, gönderenden aldığı NDR’yi veya sunucu günlüğünü istemektir.

550 5.4.1 Recipient address rejected hatası neden alınır?

Alan adı Exchange Online’da yetkili (authoritative) olarak tanımlıysa, dizinde bulunmayan alıcılara gelen posta sınırda reddedilir. Alıcı gerçekten yoksa bu beklenen davranıştır. Alıcı şirket içinde veya başka bir sistemde barındırılıyorsa alan adı iç aktarma (internal relay) olarak ayarlanmalı ya da alıcı dizine eklenmelidir.

Gönderilen posta karşı tarafta spam klasörüne düşüyorsa message trace yardımcı olur mu?

Kısmen. Message trace, mesajın Exchange Online’dan çıkıp karşı sunucuya teslim edildiğini gösterir. Teslimden sonra mesajın nereye konduğu alıcı sistemin filtreleme kararıdır; bunun için karşı tarafın günlükleri ve gönderen alan adının kimlik doğrulama yapılandırması incelenmelidir.