Kurumsal E-posta Taşıma Nasıl Yapılır? Mailler Kaybolmadan Geçiş

Kurumsal e-posta taşıma nasıl yapılır, hangi sırayla ilerlemelisiniz?

Kurumsal e-posta taşıma, alan adınızdaki posta kutularını, takma adları ve eski mailleri yeni sağlayıcıya kopyalayıp MX kaydını yeni sisteme çevirme işlemidir. Doğru sıra şudur: yeni hesapları açın, eski postaları kopyalayın, MX kaydını değiştirin, yayılma sırasında iki tarafı da izleyin, son farkı eşitleyin ve istemcileri yeniden kurun.

Bu sıranın nedeni basit, çünkü posta kutusu hareket eden bir hedeftir. Üstelik siz kopyalarken yeni mailler gelmeye devam eder. Bu yüzden önce yeni kutuları hazırlar, sonra geçmişi kopyalar, en son yönlendirmeyi çevirirsiniz. Ardından küçük bir son eşitleme yaparak kayıp riskini en aza indirirsiniz.

1. Envanter: İlk olarak hesapları, takma adları, yönlendirmeleri, istemcileri ve bağlı sistemleri listeleyin.
2. Yeni hesaplar: Ardından alan adını doğrulayın, kullanıcıları ve takma adları yeni sağlayıcıda oluşturun.
3. Kopyalama: Daha sonra resmi taşıma aracını ya da IMAP (mailin sunucuda kaldığı protokol) kopyalamasını kullanın, MX ise bu aşamada eski yerde kalsın.
4. MX kaydı: Postanın hangi sunucuya gideceğini söyleyen bu DNS (alan adı sistemi) kaydını değiştirmeden önce TTL değerini düşürün, böylece yayılma kısalır. Sonra yeni sağlayıcının verdiği değerleri girin.
5. İzleme: Yayılma sürerken eski kutulara yeni mail düşüp düşmediğine bakın, çünkü bir süre iki yerden de mail gelir.
6. Son eşitleme: Aracı yeniden çalıştırıp eski sunucuda kalan son iletileri alın.
7. İstemciler: Son olarak Outlook'u, telefonları ve diğer uygulamaları yeni hesaba bağlayıp test edin.

Aşağıdaki bölümler kurumsal e-posta taşıma sürecinin bu yedi adımını sırasıyla açıyor. Ayrıca her adımda sahada en sık çıkan sorunu ve önce neye bakmanız gerektiğini yazdık.

Hangi durumlarda kurumsal e-posta taşıma gerekir?

Kurumsal e-posta taşıma çoğunlukla dört durumda gündeme gelir. Her birinde riskli nokta farklıdır, bu yüzden hangisinde olduğunuzu baştan netleştirin.

• Hosting e-postasından Google Workspace ya da Microsoft 365'e geçiş: Kutular hosting sunucusunda durur, site ise genellikle orada kalır. Özellikle sitenin gönderdiği formların yeni sisteme ulaşmasına dikkat edin.
• Hosting değiştirme: Site ve e-posta birlikte yeni sunucuya gider. Genel süreci hosting değiştirme kontrol listemizde anlattık, burada yalnızca e-posta tarafına bakıyoruz.
• Sağlayıcıdan sağlayıcıya geçiş: Örneğin bir bulut e-posta hizmetinden diğerine geçersiniz. Takvim ve kişiler de işin içine girer.
• Ajanstan geri alma: E-posta, ajansa ait bir hostingte ya da ajans hesabındaki kutularda durur. Bu yüzden önce erişim hakkınızı netleştirirsiniz.

Hangi durumda olursanız olun mantık aynıdır: önce yeni yerde hazırlık, sonra kopyalama, en son yönlendirme. Hedef sağlayıcıyı henüz seçmediyseniz Google Workspace mi Microsoft 365 mi karşılaştırmamıza bakın.

Taşımaya başlamadan önce hangi envanteri çıkarmalısınız?

Envanter, taşımanın en ucuz sigortasıdır. Eksik bir takma ad ya da aklınızdan çıkmış bir yazıcı, geçişten sonra günlerce süren bir "mail gelmiyor" şikâyetine dönüşür. Bu yüzden basit bir liste açıp şunları yazın:

• Posta kutuları: adres, sahibi, son kullanım tarihi ve yaklaşık boyutu. Kullanılmayan kutular için taşıma, arşivleme ya da silme kararı verin.
• Takma adlar ve yönlendirmeler: Örneğin info@ ya da satis@ gibi adreslerin hangi kutuya gittiğini yazın.
• Otomatik yanıtlar ve filtreler: Sunucuda tanımlı otomatik yanıt, süzgeç ya da kural varsa not edin, çünkü IMAP kopyalama yalnızca iletileri taşır.
• Ortak kutular: Birden fazla kişi okuyorsa kimin erişeceğini belirleyin, çünkü yetki karmaşası ilk günlerde sık görülen bir şikâyettir.
• Toplam boyut: Kutuların toplamı hedef planın depolama alanına sığmalı. Ancak güncel planı sağlayıcının resmi sayfasından kontrol edin.
• İstemciler: Outlook, Apple Mail, Thunderbird, telefon uygulamaları ve web arayüzü. Hangisinin IMAP, hangisinin POP kullandığını not edin.
• Bağlı sistemler: Web sitesi formları, CRM, fatura programı, bülten aracı, yazıcı ve tarayıcılar sizin adresinizden mail gönderiyor olabilir.
• DNS kayıtları: MX, SPF, DKIM, DMARC ve e-postayla ilgili diğer kayıtlar. DNS'in nerede yönetildiğini de yazın.

Mevcut kayıtları görmek için ücretsiz DNS sorgulama aracımızı kullanabilirsiniz. Alan adının hangi kayıt firmasında ve kimin adına durduğunu Whois sorgulama aracımız gösterir. Son olarak başlamadan önce kutuların yedeğini alın. Hosting panelinden aldığınız bir yedek ya da istemciden dışa aktardığınız dosya, işler ters giderse geri dönüş yolunuzdur.

Postalarınız sunucuda mı yoksa cihazlarda mı duruyor?

Taşımada veri kaybının sık görülen nedenlerinden biri, mailin sunucuda sanılıp aslında bir bilgisayarda durmasıdır. Neyse ki bunu protokolden anlarsınız.

• IMAP: Mailin asıl kopyası sunucudadır. İstemci yalnızca bir pencere gibi çalışır, bu yüzden taşıma araçları da sunucudaki kopyayı alır.
• POP: İstemci mailleri indirir ve ayara göre sunucudan siler. Bu durumda tek kopya o bilgisayarda kalmış olabilir.
• Yerel klasörler ve arşiv dosyaları: Özellikle Outlook veri dosyaları, Thunderbird yerel klasörleri ya da Apple Mail'de bilgisayarınıza indirdiğiniz kutular sunucuda yer almaz.

Bunu netleştirmek için her kullanıcıya iki soru sorun. Hangi cihazda hangi uygulamayı kullanıyorsunuz? Maillerinizi bir dosyaya arşivlediniz ya da dışa aktardınız mı? Cevap "POP" ya da "arşiv dosyası" ise o veriyi ayrıca yeni hesaba aktarmanız gerekir, çünkü sunucudan kopyalayan araç onu görmez.

Üstelik ayrılan çalışanların eski bilgisayarları çoğu zaman en değerli arşivleri taşır. Bu bilgisayarları silmeden önce posta dosyalarını yedekleyin.

Takma adları, yönlendirmeleri ve ortak kutuları nasıl taşırsınız?

Takma ad (alias), aynı kutuya giden ikinci bir adrestir. Yönlendirme ise gelen maili başka bir adrese de gönderir. İkisi de taşıma araçlarıyla otomatik gelmez, bu yüzden yeni sağlayıcıda elle ya da toplu içe aktarma ile yeniden tanımlarsınız.

Envanterdeki her takma ad için yeni sağlayıcıda bir karşılık açın. Aksi halde MX değiştiği anda o adrese giden mail "adres bulunamadı" hatasıyla geri döner. Yani müşteri bu hatayı görür, siz görmezsiniz.

Yönlendirme kullanıyorsanız dikkatli olun, çünkü yönlendirilen mail SPF ve DMARC doğrulamasını bozabilir. Nedenini ve çözümünü e-posta yönlendirme rehberimizde anlattık. Yanlış yazılan adresleri tek kutuda toplayan catch-all ayarınız varsa, yeni sistemde karşılığı olup olmadığını ve riskini catch-all yazımızdan okuyun.

Kurumsal e-posta taşıma yöntemleri nelerdir, hangisini seçmelisiniz?

Tek bir doğru yöntem yok, çünkü kutu sayısı, kaynak sistem ve elinizdeki erişim seçimi belirler. Aşağıdaki tablo yöntemleri, uygun oldukları durumu ve riskleri karşılaştırır.

Kural basit: kutu çoksa araç, azsa istemci, cihazda kalan arşiv varsa dışa aktarma seçin. Yalnızca yönlendirmeyi taşıma saymayın, çünkü geçmiş mailleri götürmez. Hangisini seçerseniz seçin, önce tek bir kutuyla deneme yapın. Böylece süreyi ölçer, klasör eşleşmesini görür ve sürprizleri erkenden yakalarsınız.

Google Workspace'e geçerken resmi araç neyi taşır, neyi taşımaz?

Google, IMAP sunucularından Google Workspace'e e-posta almak için iki ürün tanıtıyor. Birincisi yönetici konsolundaki veri içe aktarma aracıdır; Google belgelerinde buna data import tool ya da data migration service denir. İkincisi Google Workspace Migration for Microsoft Exchange, kısa adıyla GWMME'dir.

Google'ın IMAP geçiş sayfasına göre hangi aracı seçeceğiniz sunucunuza bağlıdır. Örneğin sunucunun güvenilen bir TLS sertifikası varsa ve Google hizmetleri ona erişebiliyorsa veri içe aktarma aracını kullanırsınız. Sunucuda güvenilen bir sertifika yoksa, sunucu iç ağdaysa ya da girişte e-posta adresi yerine düz kullanıcı adı gerekiyorsa GWMME devreye girer. İki ürün için de süper yönetici olmanız gerekir.

Ancak bir sınır var: sayfa, iki aracın da yalnızca e-posta ve etiket verisini taşıdığını söyler. Takvim etkinlikleri, kişiler ve Drive dosyaları bu geçişe girmez. Yani klasör yapınız Gmail'de etiketlere dönüşür. Ayrıntılı adımlar için Google'ın IMAP sunucularından geçiş sayfasına bakın. Menü adları değişebildiği için bunları buraya yazmadık.

Microsoft 365'e IMAP geçişi nasıl işler?

Microsoft, IMAP destekleyen bir kaynaktan Microsoft 365'e kutu taşımak için IMAP geçişi yöntemini sunar. Microsoft Learn'deki genel akış şöyledir:

1. Microsoft 365'te kullanıcıları oluşturun ve lisans atayın, çünkü kutular önceden var olmalıdır.
2. Alan adının size ait olduğunu kayıt firmasında doğrulayın.
3. Kullanıcılara geçişin onları nasıl etkileyeceğini bildirin, böylece sürpriz yaşamazlar.
4. Yönetici kimlik bilgilerini ya da her kutunun parolasını hazırlayın ve kutuları bir CSV dosyasında listeleyin.
5. Microsoft 365'i kaynak sisteme bağlayan bir geçiş uç noktası oluşturun.
6. Bir geçiş grubu (migration batch) oluşturup başlatın, ardından sonucu doğrulayın.
7. MX kaydını Microsoft 365'e çevirin.
8. Yönlendirmenin doğru çalıştığını gördükten sonra geçiş grubunu silerek eşitlemeyi durdurun.

Belge üç ayrıntıyı özellikle vurgular. Yöntem yalnızca posta klasörlerindeki öğeleri taşır; kişiler, takvim öğeleri ve görevler gelmez. Araç iletileri yeniden eskiye doğru taşır, yani kullanıcılar önce en yeni postaları görür. Kutu başına öğe sayısı ile tek ileti boyutu için de üst sınırlar vardır; güncel değerleri Microsoft Learn'deki IMAP geçişi sayfasından kontrol edin.

Kaynağınız bir Exchange sunucusuysa Microsoft'un ayrı yöntemleri vardır. Bu yazı IMAP tabanlı genel durumu anlatıyor, bu yüzden Exchange kaynaklarının kapsamını resmi belgeden ayrıca okuyun.

Taşıma aracı için hangi erişimleri hazırlamalısınız, gizlilikte nelere dikkat etmelisiniz?

Her araç kaynak sunucuya bağlanmak için kimlik bilgisi ister. Yönetici erişiminiz varsa her kutunun parolasına gerek kalmayabilir. Yoksa kutu parolalarını sıfırlamanız gerekir. Microsoft'un belgesi bunu açıkça söyler ve yeni parolayı bilmeyen kullanıcının eski kutuya giremeyeceğini hatırlatır. Bu yüzden saati kullanıcılarla paylaşın.

• IMAP bilgileri: Sunucu adresini ve portu hosting sağlayıcınızın verdiği e-posta ayarlarından alın.
• Geçerli sertifika: Sertifika uyarısı veren sunucuya bazı araçlar bağlanamaz, bu nedenle Google böyle durumlarda GWMME'yi gösterir.
• Bağlantı sınırları: Microsoft, hız için kaynaktaki bağlantı sınırlarını gevşetmenizi önerir.
• Saklama politikaları: Microsoft, kayıt yönetimi ve arşiv politikalarını taşıma sırasında kapatmanızı önerir. Aksi halde silinen ya da arşive giden iletiler "eksik" çıkar.
• Yönetici hesabı: Hedef sağlayıcıdaki yönetici hesabını kurtarma e-postası ve iki adımlı doğrulamayla önceden hazırlayın.

Kutular kişisel veri içerir, bu nedenle parolaları e-postayla göndermeyin; geçici parola verin ve geçişten sonra değiştirtin. Yönetici yetkisini yalnızca işi yapan kişilere verin, iş bitince geri alın. Verinin hangi ülkede tutulacağını ve sağlayıcıyla yapacağınız sözleşmeyi KVKK kapsamında ayrıca değerlendirmeniz gerekir. Bu yazı hukuki danışmanlık değildir; sözleşme ve KVKK sorularınız için hukuk danışmanınıza başvurun.

TTL nedir ve MX değişikliğinden önce neden düşürmelisiniz?

TTL (time to live), bir DNS kaydının önbellekte ne kadar süre tutulacağını saniye cinsinden söyler. Değer yüksekse, kaydı değiştirseniz bile bazı mail sunucuları eski MX bilgisini süre dolana kadar kullanmaya devam eder.

Bu yüzden MX kaydını değiştirmeden önce TTL'i düşürürsünüz. Ancak zamanlama önemlidir. Düşürmenin etkisi, çözümleyicilerdeki eski değerin süresi dolunca başlar. Dolayısıyla mevcut TTL değerini not edin ve geçiş gününden en az o süre kadar önce düşürün. Burada sayı vermiyoruz, çünkü kayıt firmanızın izin verdiği en düşük değer ve mevcut ayarınız farklı olabilir.

Son olarak geçişten sonra işler birkaç gün sorunsuz yürüyünce TTL'i normal değerine döndürün, çünkü düşük değer DNS sunucunuza gereksiz sorgu yükler. Kurumsal e-posta taşıma planınıza bu iki tarihi, yani düşürme ve geri alma gününü, baştan yazın.

MX kaydını değiştirdiğiniz gün tam olarak ne olur?

MX kaydı, alan adınıza gelen maili hangi sunucunun alacağını söyler. Gönderen sunucu önce bu kayda bakar, sonra o adrese bağlantı kurar. Ayrıca RFC 5321'e göre MX değerinde küçük sayı daha yüksek önceliğe sahiptir.

Kaydı değiştirdiğiniz anda herkes aynı anda yeni sisteme geçmez. TTL süresi dolan göndericiler yeni adrese, süresi dolmayanlar eski adrese mail atar. Yani bir süre iki yerde de mail görürsünüz. Bu normaldir ve eski sistemi hemen kapatmamanızın nedeni budur.

Standart, geçici hatalarda gönderen sunucunun yeniden denemesini bekler ve vazgeçme süresinin genellikle en az 4-5 gün olması gerektiğini söyler. Yine de her sunucu buna uymaz. Bu yüzden geçişi mail trafiğinin sakin olduğu bir saate koyun. Ayrıntı için RFC 5321 belgesine bakın.

1. Mevcut DNS kayıtlarının tamamını dışa aktarın ya da ekran görüntüsünü alın, çünkü geri dönüş değerleriniz bunlardır.
2. Yeni sağlayıcının yönetici yardımındaki MX değerlerini açın ve birebir kopyalayın.
3. Eski MX kayıtlarını silin ya da yenileriyle değiştirin.
4. Kaydı kaydedip DNS aracıyla yeni değeri doğrulayın.
5. Kişisel bir Gmail ya da Outlook.com adresinden test postası gönderin.

Eski ve yeni kayıtları aynı öncelikle bırakırsanız gönderenler aralarında seçim yapar ve postanızın bir kısmı eski, bir kısmı yeni sisteme gider. Kayıt firmasında MX girmenin genel mantığını Microsoft'un DNS kaydı oluşturma belgesi anlatır.

Web sitesi formları neden kaybolur, cPanel Email Routing ayarı neden önemlidir?

Siteniz hostingte kalıp kutularınız Google Workspace ya da Microsoft 365'e giderse, kurumsal e-posta taşımanın en sinsi sorunu iletişim formu maillerinin kaybolmasıdır. Form, sitenizle aynı sunucudan info@example.com gibi bir adrese mail gönderir. Sunucu bu alan adını hâlâ kendi sayıyorsa mail dışarı çıkmaz, yani eski yerel kutuya düşer.

cPanel belgesine göre Email Routing ekranı dört seçenek sunar: Automatically Detect Configuration, Local Mail Exchanger, Backup Mail Exchanger ve Remote Mail Exchanger. Remote seçeneğinde sunucu alan adı için mail kabul etmez ve tüm postayı en düşük numaralı MX'e gönderir. Otomatik algılama ise yalnızca sunucudaki yerel bölge dosyasına bakar, gerçek bir DNS sorgusu yapmaz.

Dolayısıyla DNS'i hosting dışında yönetiyorsanız ya da yerel kayıt eski kaldıysa sunucu yanlış karar verebilir. Ayarı değiştirmeden önce hosting sağlayıcınızla konuşun, çünkü yanlış seçim alan adının mail almasını durdurabilir. Seçeneklerin tanımı için cPanel'in Email Routing belgesine bakın.

İkinci tuzak gönderim tarafıdır. Form maili hosting sunucusundan çıkarken SPF kaydınız bu sunucuyu içermiyorsa mail spam klasörüne düşebilir. Kalıcı çözüm, formları kutunuzun SMTP bilgileriyle ya da bir gönderim servisiyle göndermektir. Örneğin WordPress kullanıyorsanız WP Mail SMTP rehberimiz yol gösterir. Ayrıca yazıcı ve tarayıcıların mail ayarlarını da aynı şekilde güncelleyin.

Yayılma süresinde iki tarafı birden nasıl kontrol edersiniz?

Yayılma sürerken mail hem eski hem yeni kutuya düşebilir. Bu yüzden her iki tarafa da bakmanız gerekir. Küçük bir günlük rutin yeterlidir:

• Eski kutuları web arayüzünden ya da eski sunucunun IMAP bilgileriyle açıp yeni gelen mail olup olmadığına bakın.
• Yeni kutularda aynı adreslere gönderdiğiniz test postalarını görün.
• Eski kutuda yeni mail bulursanız not edin, çünkü bunları son eşitlemede yeni kutuya alacaksınız.
• Ayrıca önemli bir iş ortağınızdan yeni adrese kısa bir test postası göndermesini isteyin.

MX değerini komut satırından da görebilirsiniz:

dig +short MX example.com
nslookup -type=MX example.com

Komut kullanmak istemezseniz aynı sonucu daha önce andığımız DNS sorgulama aracıyla tarayıcıda da görürsünüz. Hem kendi ağınızdan hem farklı bir ağdan sorgulayın, böylece önbellek farklarını görürsünüz. Eski kutuları, yeni mail akışı tamamen kesilene kadar silmeyin.

Son fark eşitlemesini nasıl yaparsınız, eski kutuları ne zaman kapatırsınız?

Son fark eşitlemesi, MX değişikliğinden sonra eski sunucuya düşen son iletileri yeni kutuya almaktır. Birçok araç yeniden çalıştırdığınızda yalnızca yeni iletileri kopyalar. Microsoft'un IMAP geçişinde ise eşitleme, siz geçiş grubunu silene kadar sürer.

1. İlk olarak MX değerinin yayıldığını ve eski kutulara artık yeni mail gelmediğini doğrulayın.
2. Ardından kopyalama aracını son kez çalıştırın ya da çalışmasını bekleyin.
3. Birkaç kutuda klasör sayılarını ve en yeni ileti tarihlerini karşılaştırın.
4. Sonuç tamamsa eşitlemeyi durdurun. Microsoft'ta bu, geçiş grubunu silmek demektir.
5. Eski kutuları hemen silmeyin; yalnızca okumaya açık bırakın ya da yedekleyin.

Son eşitlemeden önce kullanıcılardan klasör adlarını değiştirmemelerini isteyin, çünkü çoğu araç klasörleri adına göre eşler. Yeniden adlandırılan bir klasör ikinci kez kopyalanabilir.

Eski sağlayıcıyı iptal etmek için acele etmeyin. Önce yedeği indirin ve açıp kontrol edin, ardından iptal edin. Kaç gün bekleyeceğinizi şirketinizin saklama ihtiyacı belirler. Özellikle siteniz aynı hostingteyse iptal ettiğiniz şey yalnızca e-posta olmasın, yoksa siteyi de kapatabilirsiniz.

Outlook, telefon ve Mac Mail istemcilerini nasıl yeniden kurarsınız?

Kullanıcıları önceden bilgilendirmek işin yarısıdır. Geçiş gününü, yeni giriş adresini ve cihazlarda ne yapacaklarını tek bir kısa mesajda yazın. Taşımadan sonra istemciler eski sunucuya bağlı kalır, parola sorar ya da bağlanamadığını söyler. Çözüm çoğu zaman eski hesabı onarmak değil, yeniden kurmaktır.

1. Yeni kutuya web arayüzünden girebildiğinizi doğrulayın.
2. İstemcideki eski hesabı kaldırın. Outlook'ta sorun sürerse yeni bir profil oluşturun, bozulan profili yamamaya uğraşmayın.
3. Yeni hesabı sağlayıcının verdiği ayarlarla ya da otomatik yapılandırmayla ekleyin.
4. İlk eşitlemenin bitmesini bekleyin. Büyük kutularda bu biraz sürer, bu yüzden acele etmeyin.
5. Gelen, gönderilen ve taslak klasörlerini kontrol edin, imzayı ve kuralları yeniden girin.
6. Telefonlarda eski hesabı silip yenisini ekleyin.

Outlook'un yerel önbellek dosyası yeni hesapta yeniden oluşur, bunu kayıp saymayın. Ayar ayrıntıları için Outlook kurulum rehberimize bakın. Ayrıca eski programda yerel arşiviniz varsa, istemciyi silmeden önce o dosyayı yeni hesaba aktarın.

Takvim ve kişiler neden eksik kalır, nasıl taşırsınız?

IMAP tabanlı geçişler yalnızca maili taşır. Hem Microsoft hem Google belgelerinde bunu açıkça yazar: kişiler, takvim öğeleri ve görevler gelmez. Dolayısıyla geçişten sonra kullanıcılar "toplantılarım nerede?" diye sorar.

• Takvim: Eski istemciden .ics dosyası olarak dışa aktarın ve yenisine aktarın. Örneğin yinelenen etkinlikleri ve saat dilimini birkaç örnekle kontrol edin.
• Kişiler: .vcf ya da CSV dosyasıyla taşıyın. Yinelenen kayıtlar çıkarsa birleştirin.
• Ortak takvimler: Yeni sağlayıcıda yeniden paylaşın ve izinleri baştan verin.
• Exchange kaynağı: Sağlayıcıların takvim ve kişileri de kapsayan ayrı yöntemleri vardır. Ancak kapsamı resmi belgeden kontrol edin.

Takvim ve kişileri geçiş gününden önce kopyalayın, geçişten sonra son bir kez kontrol edin. Böylece yeni davetler boş bir takvime düşmez.

SPF, DKIM ve DMARC kayıtlarını taşıma sonrası nasıl güncellersiniz?

Yeni sağlayıcıdan çıkan maillerin spam klasörüne düşmemesi için gönderici kimliği kayıtlarını güncelleyin. Ayrıntılı kurulum için SPF, DKIM ve DMARC rehberimize bakın. Burada yalnızca taşımaya özel noktaları yazıyoruz.

• SPF: Alan adı başına tek SPF kaydı olmalıdır. Yeni sağlayıcıyı mevcut kayda ekleyin, kullanmadığınız eski sağlayıcıyı çıkarın, çünkü ikinci bir SPF kaydı eklemek hataya yol açar.
• DKIM: Yeni sağlayıcının yönetim panelinden DKIM anahtarı üretin ve DNS'e ekleyin. Eski sağlayıcıdan artık göndermiyorsanız eski anahtarı sonra kaldırın.
• DMARC: Politikanız zaten sıkıysa, yani quarantine ya da reject ise, geçiş sırasında raporları yakından izleyin. Yeni gönderici hizalanmazsa alıcılar mailleri reddeder.
• Diğer göndericiler: Ayrıca bülten aracı, CRM ve fatura sistemi gibi servisleri de listeleyin ve kayıtlara ekleyin.

Sonucu SPF, DKIM ve DMARC kontrol aracımızla ücretsiz doğrulayın. Hata kodları görürseniz kayıtları yeniden kontrol edin, çünkü çoğu ret doğrulama eksiğinden doğar.

Kurumsal e-posta taşımada en sık hangi sorunlar çıkar, önce neye bakmalısınız?

Belirtiye göre sırayla bakarsanız çoğu sorunu hızlı çözersiniz. Önce şuna bakın: MX doğru mu ve hedef adres gerçekten var mı? Çünkü en sık sorun budur.

Bu sıra size zaman kazandırır: önce yönlendirme, sonra içerik, en son istemci. Çünkü yönlendirme bozuksa içerik ve istemci ayarı ne kadar doğru olsa da mail gelmez.

Ajansınızdan ya da eski sağlayıcınızdan e-postanızı geri alıyorsanız ne yapmalısınız?

E-postanız ajansa ait bir hostingteyse ya da ajans hesabındaki Google Workspace'teyse önce hesabın sahibini öğrenin. Alan adı, e-posta hizmeti ve site çoğu zaman farklı kişilerin adına kayıtlıdır. Alan adı kaydındaki bilgiyi daha önce andığımız Whois aracıyla görebilirsiniz. Tüm envanteri web sitesi ve alan adını ajanstan geri alma rehberimizde anlattık.

Kuralları açık tutun: ajansa ya da başkasına ait hesaba izinsiz girmeyin, eski çalışanın parolasını tahmin etmeyin, çünkü bu hem hukuken sorunludur hem de sağlayıcıların kullanım koşullarına aykırıdır. Doğru yol, yetkili kişiden yazılı olarak yönetici erişimi, kutuların dışa aktarımı ya da hesap devri istemektir.

1. İlk olarak alan adının ve DNS'in sizin kontrolünüzde olduğundan emin olun.
2. Yeni sağlayıcıyı kendi adınıza açın.
3. Ajanstan kutu listesini, takma adları ve mümkünse dışa aktarılan verileri isteyin.
4. Kopyalamayı bu verilerle yapın.
5. Son olarak MX kaydını çevirdikten sonra ajans erişimini kapatın.

Bu yazı hukuki danışmanlık değildir. Sözleşmenizde e-posta verisinin kime ait olduğu yazıyorsa hukuk danışmanınıza danışın.

Taşıma sonrası kontrol listesi neleri içermeli?

Aşağıdaki liste, kurumsal e-posta taşıma işini kapatmadan önceki son kontroldür. Yazdırıp maddeleri tek tek işaretlemenizi öneririz.

• Her kutuya dışarıdan bir test postası gönderin ve yanıtlayın.
• Takma adların ve grup adreslerinin her birini ayrı ayrı deneyin, çünkü eksik takma ad sık görülen bir sorundur.
• Gmail ve Outlook.com adreslerine mail gönderip başlıkta SPF, DKIM ve DMARC sonuçlarına bakın.
• Web sitesi formunu doldurup maili hedef kutuda görün.
• Birkaç kutuda klasör sayılarını ve en yeni ileti tarihlerini eski sistemle karşılaştırın.
• Outlook, telefon ve tarayıcı gibi cihazların yeni hesapla çalıştığını doğrulayın.
• Eski kutulara yeni mail gelmediğini bir süre izleyin.
• TTL'i normal değerine döndürün.
• Yeni DNS kayıtlarını, yönetici hesaplarını ve kurtarma bilgilerini bir yere yazın.
• Kullanıcılara yeni giriş adresini ve iki adımlı doğrulamayı anlatan kısa bir bilgi mesajı gönderin.
• Son olarak eski sağlayıcının iptal tarihini ve yedeği silme tarihini takvime ekleyin.

Bu listenin tamamı bitmeden taşımayı bitmiş saymayın. Eksik madde kalırsa onu önümüzdeki haftanın ilk işi yapın.

Kurumsal e-posta taşımayı kendiniz mi yapmalısınız, yoksa ekibe mi bırakmalısınız?

Birkaç kutunuz, basit bir DNS düzeniniz ve yönetici erişiminiz varsa resmi araçlarla işi kendiniz yapabilirsiniz. Ancak şu durumlarda destek almak daha güvenlidir:

• Çok sayıda kutu, takma ad ve grup adresi varsa.
• Mailler POP ile cihazlarda ya da yerel arşivlerde duruyorsa.
• Site, form ve e-posta aynı hostingteyse ve birlikte taşınacaksa.
• DNS'in kimde olduğu belli değilse ya da ajanstan devir yapıyorsanız.
• Kutularda hassas ya da düzenlemeye tabi veri varsa.

Biz bir hosting ya da e-posta sağlayıcısı değiliz. Web sitesini ve kurumsal e-postayı Google Workspace, Microsoft 365 ya da barındırma sağlayıcınızda kurar, taşır ve yönetiriz. Bu yüzden kapsamı netleştirmek için web sitesi ve kurumsal e-posta kurulumu ya da taşıması için teklif alın.