Exchange Hibrit Ortamda Not Accepted Domain Exception Hatası

Exchange Server ortamlarında, özellikle Exchange Online ile On-Prem Exchange altyapısının birlikte çalıştığı Office 365 hibrit mimarilerde, e-posta adresi yönetimi kritik bir kontrol mekanizmasına dayanır.
Mailbox taşıma (on-prem → EXO) süreci doğrudan Email Address Policy ve Accepted Domain yapılandırmalarıyla ilişkilidir.

Email Address Policy güncellemeleri, mailbox taşıma işlemleri ve Azure AD (Entra ID) senkronizasyonu sırasında Exchange; kullanıcı objeleri üzerindeki tüm SMTP adreslerini detaylı şekilde doğrular ve bu adreslerin hem On-Prem hem de Exchange Online ortamında kabul edilen domain’lere ait olmasını zorunlu kılar.

Bu doğrulama sürecinde, organizasyon tarafından kabul edilmeyen (Accepted Domain olarak tanımlı olmayan) bir domain’e ait adres tespit edilirse, işlem güvenlik ve adres bütünlüğü gerekçesiyle durdurulur. Sonuç olarak Exchange Online migration süreci, mailbox taşıma işlemleri veya kullanıcı seviyesinde yapılan güncellemeler başarısız olur ve aşağıdaki hata ile karşılaşılır:

Yukarıdaki hata içeriğinde görüldüğü üzere, kullanıcı üzerinde pera.xyz domain’i bulunmaktadır. Bu domain Exchange On-Prem altyapısında hâlen kullanılıyor olsa bile, Exchange Online üzerinde tanımlı olmadığı için mailbox taşıma işlemi başarısız olmaktadır.

Bu makale içinde aşağıda ki bilgilere sahip olacaksınız.

1. Bu Hata Neden Olur?

NotAcceptedDomainException hatası, tek bir teknik sebebe dayanmaz. Temel neden; Exchange organizasyonunun kabul etmediği (Accepted Domain olmayan) bir e-posta domain’inin, hâlâ kullanıcı objeleri üzerinde yer almasıdır. Bu durum pratikte farklı senaryolarla karşımıza çıkar.

1.1 Geçmişte Kullanılan ancak artık Kullanılmayan Domain

Exchange organizasyonunda geçmişte pera.xyz gibi bir domain aktif olarak kullanılmış olabilir. Zamanla kurumsal e-posta standardı değişmiş, yeni bir ana domain belirlenmiş ve eski domain Exchange Online mimarisinde kullanılmayacak şekilde planlanmış olabilir.

Bu nedenle ilgili domain Accepted Domains listesinden kaldırılmıştır. Ancak bazı kullanıcılar üzerinde:

• Secondary SMTP adresi olarak
• Manuel eklenmiş proxyAddresses kalıntısı şeklinde

varlığını sürdürmeye devam edebilir. Exchange Online, bu kalıntıyı tespit ettiği anda işlemi durdurur.

1.2 Address Policy’den Çıkarıldı Ama Kullanıcıdan Temizlenmedi

Hatalı domain Address Policy kapsamından çıkarılmış olabilir. Ancak Email Address Policy, mevcut kullanıcılar üzerindeki adresleri otomatik olarak silmez; yalnızca yeni atamaların önüne geçer.

Bu senaryoda:

• Eski kullanıcılar, kaldırılan domain’i taşımaya devam eder
• Yeni kullanıcılar bu domain’i almaz
• Ortamda adres tutarsızlığı oluşur

Bu tutarsızlık, Office 365 hibrit mimari kurulmadan önce temizlenmezse mailbox taşıma veya senkronizasyon sırasında hataya sebep olur.

1.3 Senaryo 3 – On-Prem Active Directory Kalıntıları

On-Prem Active Directory tarafında, kullanıcı objesinin proxyAddresses alanında artık kullanılmayan domain kayıtları bulunabilir. Bu adresler geçmişte manuel olarak eklenmiş olabilir ve Address Policy kapsamı dışında kalmış olabilir.

Accepted Domain kaldırılmış olsa bile, Azure AD Connect bu adresleri olduğu gibi Entra ID’ye senkronize eder. Exchange Online bu domain’i kabul etmediği için mailbox taşıma işlemi hata ile sonuçlanır.

1.4 Domain Bilinçli Olarak Kullanım Dışı Bırakılmıştır

Bu hata her zaman yanlış yapılandırma anlamına gelmez. Bazı senaryolarda domain, bilinçli olarak Exchange Online mimarisinde kullanılmayacak şekilde çıkarılmıştır. Ancak geçmişten kalan kullanıcı verileri henüz temizlenmemiştir.

Bu noktada hata, Exchange’in yanlış çalıştığını değil; aksine mimariyi koruduğunu gösterir. Bu durumda organizasyonun karar vermesi gerekir:

• Hata üreten domain Exchange Online’a mı tanımlanacak?
• Yoksa bu domain’e sahip kullanıcılar Exchange Online’a taşınmayacak mı?

Office 365 hibrit mimarilerde, özellikle holding yapılarında bu senaryo oldukça sık görülür. Birden fazla alt şirketi barındıran Exchange organizasyonlarında, kullanıcılar üzerinde birden fazla şirket domain’i bulunabilir. Eğer bu domain’lerden biri Exchange Online mimarisinde yer almayacaksa iki seçenek vardır:

• Kullanıcı Exchange Online’a taşınmaz
• Ya da ilgili domain Exchange Online’a Accepted Domain olarak eklenir

2. Hata Tespit

2.1 Accepted Domain Kontrolleri

NotAcceptedDomainException hatasının tespit sürecinde ilk ve en temel adım, Exchange organizasyonunda aktif ve tanımlı Accepted Domain ’lerin hem On-Prem hem de Exchange Online tarafında doğrulanmasıdır.

Bu nedenle işe, her iki ortamda da Get-AcceptedDomain komutu çalıştırılarak organizasyonun kabul ettiği domain listesinin çıkarılması ile başlanır. Bu komut Exchange Server Onprem ortamlarında da Exchange Online ortamlarında da aynı şekilde yazılır fakat çalıştırılmış oldukları ara birim farklıdır.

Exchange Onprem ortamlarında Exchange Management Shell üzerinde çalıştırılırken Exchange Online üzerinde, Exchange Online ortamına Windows Power Shell ile bağlantı yaptıktan sonra çalıştırılır ve aynı domainlerin her iki tarafta da görmemiz gerekmektedir.

Bu kontrol sayesinde:

• Hangi domain’lerin organizasyon tarafından aktif olarak kabul edildiği,
• Varsayılan (Default) domain’in hangisi olduğu,
• Domain’lerin Authoritative veya Internal Relay olarak nasıl konumlandırıldığı net bir şekilde görülür.

On-Prem Exchange Server ve Exchange Online ortamlarında Accepted Domain listeleri uyumludur ve hata üreten domain bu listelerde yer almamaktadır. Bu durum, hatanın Accepted Domain eksikliğinden değil; kullanıcı objeleri üzerindeki eski e-posta adresi kalıntılarından kaynaklandığını açıkça göstermektedir.

Bizim senaryomuz “1.2 – Address Policy’den Çıkarıldı Ama Kullanıcıdan Temizlenmedi” başlığı ile birebir örtüşmektedir. İlgili domain, geçmişte Email Address Policy kapsamında kullanılmış, daha sonra politikadan çıkarılmış; ancak mevcut kullanıcı objeleri üzerindeki SMTP adresleri manuel olarak temizlenmediği için mailbox taşıma ve senkronizasyon süreçlerinde hata üretmeye devam etmiştir.

Accepted Domain listesinde bulunmayan tek bir SMTP adresi bile, Exchange Online taşıma sürecinin tamamen durmasına sebep olabilir.

📌 Önemli Not:

Yukarıdaki çıktılarda dikkat edilirse, aynı domain’ler hem Exchange On-Prem hem de Exchange Online ortamında tanımlı olmasına rağmen DomainType değerleri farklılık gösterebilmektedir. Bu durum bir yapılandırma hatası değildir ve Office 365 hibrit mimarilerde beklenen bir davranıştır.

Bu farkın temel nedeni, On-Prem Exchange ile Exchange Online’ın mail flow sorumluluklarının farklı olmasıdır.

• Exchange Online tarafında domain’ler genellikle Authoritative olarak tanımlanır.
  Bunun sebebi, ilgili domain’e ait mailbox’ların artık Exchange Online üzerinde barındırılıyor olması ve nihai teslim noktasının EXO olmasıdır.
• Exchange On-Prem tarafında ise aynı domain InternalRelay olarak tanımlanabilir.
  Bu yapılandırma, On-Prem Exchange’in bu domain’e gelen e-postaları nihai hedef olarak kabul etmeyip, gerekli durumlarda Exchange Online’a veya başka bir mail sistemine yönlendirmesine olanak tanır.

Özetle:

• Authoritative → “Bu domain’in nihai teslim noktası benim”
• InternalRelay → “Bu domain bende tanımlı ama nihai teslim noktası ben olmayabilirim”

DomainType farklılığı, NotAcceptedDomainException hatasının doğrudan sebebi değildir. Asıl hata, Accepted Domain listesinde yer almayan bir domain’in kullanıcı üzerinde bulunmasından kaynaklanır.

Bu nedenle, DomainType farklılıkları, hibrit mail flow tasarımının doğal bir parçasıdır ve NotAcceptedDomainException hatasının doğrudan sebebi değildir. Asıl problem, Accepted Domain listesinde yer almayan bir domain’in kullanıcı objeleri üzerinde bulunmasıdır.

2.2 Email Address Policy ve Kullanıcı Üzerindeki Domain Kalıntıları

Accepted Domain kontrolü ile organizasyonun hangi domain’leri “kabul ettiğini” doğruladıktan sonra, ikinci adımda hatanın kök nedenini Email Address Policy tarafında ararız. Çünkü bu senaryoda problem; domain’in geçmişte policy kapsamında dağıtılmış olması fakat sonradan policy’den çıkarılmasına rağmen, kullanıcı objeleri üzerindeki adreslerin otomatik temizlenmemesidir.

Bu nedenle önce “Default Policy” üzerinde hangi e-posta adresi şablonlarının etkin olduğunu kontrol ederiz. Böylece ilgili domain’in policy’den gerçekten çıkarılıp çıkarılmadığını netleştiririz:

Policy tarafı netleştikten sonra, organizasyon genelinde @pera.xyz domain’ine sahip kaç kullanıcı olduğunu hızlıca sayarız. Bu adım, problemin kapsamını görmek ve düzeltme planı yapmak için kritik önemdedir.

Çıktı sonucunda görüldüğü üzere, Accepted Domain listesinde yer almayan ve geçmişte kullanılmış ancak artık aktif olmayan pera.xyz domain’i, 158 farklı kullanıcı üzerinde tanımlı durumdadır. Taşınmak istenen kullanıcılar üzerinde bu domain bulunduğu için mailbox taşıma işlemleri hata ile sonuçlanmaktadır.

Son olarak, bu domain kalıntısının hangi kullanıcılar üzerinde bulunduğunu detaylı şekilde listeleriz. Bu listede hem kullanıcıların Primary SMTP adresini hem de kullanıcı objesi üzerinde yer alan pera.xyz  ile eşleşen tüm proxy address değerlerini tek satırda toplayarak görünür hale getiririz.

Bu çıktı sayesinde, hataya sebep olan domain’in:

• hangi kullanıcılar üzerinde kaldığı,
• Primary mi Secondary mi olduğu,
• tek adres mi yoksa birden fazla proxyAddress mı bıraktığı

net biçimde ortaya çıkar. Böylece senaryonun “1.2 – Address Policy’den Çıkarıldı Ama Kullanıcıdan Temizlenmedi” olduğu doğrulanır ve bir sonraki adımda temizlik/düzeltme işlemleri kontrollü şekilde planlanabilir.

3. Kullanıcı Üzerindeki Hatalı Domain’in Temizlenmesi

Hata tespit adımlarında görüldüğü üzere problem, Accepted Domain veya Email Address Policy eksikliğinden değil; Email Address Policy’den çıkarılmış olmasına rağmen kullanıcı objeleri üzerinde kalmış olan eski domain adreslerinden kaynaklanmaktadır.

Bu noktada yapılması gereken işlem, Exchange Online mimarisinde kullanılmayacak olan domain’e ait SMTP adreslerinin, kullanıcı objeleri üzerinden kontrollü şekilde temizlenmesidir. Aşağıdaki PowerShell komutu, organizasyon genelinde mailbox’ları tarar ve @pera.xyz domain’ine ait e-posta adreslerini kullanıcıların EmailAddresses alanından kaldırır.

Bu işlem geri alınamaz bir değişikliktir. Komut çalıştırılmadan önce:

• Etkilenecek kullanıcıların listesi mutlaka kontrol edilmeli
• Mümkünse test ortamında veya sınırlı bir kullanıcı grubunda denenmelidir.

Bu komut çalıştırıldıktan sonra kullanıcılar üzerinde tanımlı bulunan @pera.xyz domaini üzerinden e-posta trafiği sağlanamaycaktıt.

Bu komutun çalışma mantığı özetle şu şekildedir:

• Organizasyondaki tüm mailbox’lar taranır
• EmailAddresses alanında @pera.xyz domain’i bulunan adresler filtrelenir
• Kullanıcının diğer SMTP adreslerine dokunulmadan, yalnızca bu domain’e ait adresler kaldırılır

Komut çalıştırıldıktan sonra, ilgili kullanıcıların üzerindeki hatalı domain kalıntıları temizlenmiş olur. Böylece:

• Exchange Online mailbox taşıma işlemleri
• Azure AD / Entra ID senkronizasyonu
• Kullanıcı seviyesinde yapılan güncellemeler

artık NotAcceptedDomainException hatası üretmeden sorunsuz şekilde tamamlanabilir.

Kullanıcı objeleri üzerindeki hatalı SMTP adresleri temizlendikten sonra, bu değişikliklerin Exchange Online ve Entra ID tarafına yansıtılması gerekir. Hibrit mimarilerde yapılan adres güncellemeleri, varsayılan olarak bir sonraki zamanlanmış Azure AD Connect senkronizasyonunu bekler. Ancak mailbox taşıma veya kritik işlemler öncesinde beklemeden ilerlemek için manuel senkronizasyon tetiklenmesi önerilir.

Bu amaçla, Azure AD Connect (Entra Connect) sunucusu üzerinde aşağıdaki PowerShell komutu çalıştırılır

Bu komut, yalnızca son senkronizasyondan sonra değişen objeleri kapsayan Delta Sync işlemini başlatır. Böylece:

• Kullanıcı üzerindeki güncellenmiş proxyAddresses değerleri
• Temizlenen SMTP adresleri
• Exchange attribute değişiklikleri

kısa süre içinde Entra ID ve Exchange Online ortamına aktarılmış olur.

Azure AD Connect üzerinde başlatılan Delta Synchronization işleminin başarıyla tamamlandığını gösteren senkronizasyon çıktısı. Export ve Delta Synchronization adımlarında hata oluşmadığı ve değişikliklerin Exchange Online / Entra ID ortamına başarıyla aktarıldığı görülmektedir.

Delta senkronizasyon kapsamında işlenen kullanıcı objelerinin detaylı görünümü. Toplam 158 objenin başarıyla senkronize edildiği ve adres güncellemelerinin Entra ID tarafına aktarıldığı doğrulanmaktadır.

Kullanıcı objesi üzerinde bulunan proxyAddresses alanındaki değişiklikleri gösteren detay ekranı. Bu adımda, Exchange Online mimarisinde kullanılmayacak olan domain’e ait SMTP adreslerinin başarıyla silindiği ve yalnızca geçerli Accepted Domain adreslerinin bırakıldığı görülmektedir.

Bu makalede, Office 365 hibrit mimarilerde sık karşılaşılan NotAcceptedDomainException hatasının nedenlerini, tespit adımlarını ve kalıcı çözüm yöntemini uçtan uca ele aldık. Görüldüğü üzere bu hata, çoğu zaman Exchange Online veya Accepted Domain yapılandırmasındaki bir eksiklikten değil; Email Address Policy’den çıkarılmış ancak kullanıcı objeleri üzerinden temizlenmemiş eski e-posta domain kalıntılarından kaynaklanmaktadır.

Accepted Domain kontrolleri, Email Address Policy analizi, kullanıcı üzerindeki SMTP adreslerinin tespiti, kontrollü temizlik işlemleri ve ardından Azure AD / Entra ID senkronizasyonunun tetiklenmesi ile sorun kalıcı olarak giderilmiştir. Paylaşılan görseller de, yapılan işlemlerin hem On-Prem hem de Exchange Online tarafında başarıyla uygulandığını teknik olarak doğrulamaktadır.

Özellikle holding yapılarında ve uzun yıllardır kullanılan Exchange organizasyonlarında, geçmişten kalan domain kalıntıları hibrit geçiş süreçlerinde ciddi sorunlara yol açabilmektedir. Bu nedenle Exchange Online taşıma projeleri öncesinde:

• Accepted Domain listelerinin her iki ortamda da kontrol edilmesi,
• Email Address Policy geçmişinin analiz edilmesi,
• Kullanıcı objeleri üzerindeki proxyAddresses alanının detaylı incelenmesi

kritik öneme sahiptir.

Sonuç olarak, NotAcceptedDomainException hatası bir sorun değil; doğru okunup analiz edildiğinde, Exchange mimarisinin tutarlılığını ve güvenliğini koruyan bir uyarı mekanizmasıdır. Doğru adımlar izlendiğinde, hibrit Exchange ortamlarında mailbox taşıma ve senkronizasyon süreçleri sorunsuz şekilde tamamlanabilir.