cPanel MX Kaydı ve E-posta Teslimat Yönlendirmesi

Bir alan adına e-posta gönderdiğinizde, mesajın nereye teslim edileceğine karar veren tek bir şey vardır: MX kaydı. Alan adınızın hosting'i bir sunucuda dursa bile, postanız bambaşka bir yere, örneğin Google Workspace'e ya da harici bir mail servisine gidebilir. Bunu belirleyen web sunucusu değil, DNS bölgenizdeki MX (Mail Exchanger) kayıtlarıdır. MX kaydını yanlış kurmak, "e-postam neden gelmiyor", "bir kutuda görünüyor ama diğerinde yok" ya da "gönderdiğim mail kayboldu" gibi en can sıkıcı sorunların kaynağıdır. Üstelik bu sorunlar sunucu tarafında hiçbir hata log'u bırakmadan sessizce yaşanabilir; çünkü teknik olarak her şey "çalışıyordur", sadece posta yanlış kapıya teslim edilmektedir.

cPanel bu tabloya ikinci bir katman ekler. DNS'teki MX kaydının yanı sıra, sunucunun kendi içinde bir de Email Routing (E-posta Yönlendirme) ayarı vardır ve bu ayar, sunucunun "bu alan adının postasını ben mi teslim edeyim, yoksa dışarı mı çıkarayım" sorusuna verdiği cevaptır. MX kaydı ile Email Routing ayarının uyumsuz olduğu durumlar, hosting dünyasının en klasik e-posta arızasıdır. Bu rehberde MX kaydının nasıl çalıştığını, MX önceliğinin ne işe yaradığını, cPanel'in Local/Backup/Remote/Automatic yönlendirme seçeneklerini ve Google Workspace ile harici bir servise geçerken tam olarak neyi nasıl ayarlamanız gerektiğini uygulamalı biçimde göreceğiz. Amaç, MX'i "bir yere kopyalayıp yapıştırmak" değil, arkasındaki mantığı kavrayarak bir daha asla teslimat kaybı yaşamamak.

MX Kaydı Postanın Yolunu Nasıl Belirler#

MX kaydı, bir DNS kayıt türüdür ve tek bir işi vardır: "Bu alan adına gelen e-posta hangi sunucuya teslim edilsin?" sorusunu yanıtlamak. Biri size [email protected] adresine mail attığında, gönderen tarafın posta sunucusu şu adımları izler: önce sirketiniz.com alan adının MX kayıtlarını DNS üzerinden sorar, dönen MX kaydındaki sunucu adını (örneğin mail.sirketiniz.com) alır, sonra o ismin A kaydına bakıp IP adresini çözer ve mesajı o IP'deki SMTP sunucusuna teslim eder. Yani MX kaydı, e-posta trafiği için bir "yol tabelası"dır.

Burada sık yapılan bir kavram hatasını hemen düzeltelim: MX kaydı bir IP adresi göstermez, bir hostname (sunucu adı) gösterir. Bu hostname'in de mutlaka geçerli bir A kaydı olmalıdır. MX kaydını doğrudan bir IP'ye işaret ettirmek RFC standartlarına aykırıdır ve birçok gönderen sunucu bu maili reddeder. Doğru zincir şudur: MX → hostname → A kaydı → IP.

Tipik bir DNS bölgesinde MX ile ilgili kayıtlar şöyle görünür:

; Alan adının MX kaydı — postayı mail.sirketiniz.com sunucusuna yönlendirir
sirketiniz.com.        IN   MX   10   mail.sirketiniz.com.

; MX'in gösterdiği hostname'in A kaydı — IP'yi çözer
mail.sirketiniz.com.   IN   A    203.0.113.25

Dikkat edin: sirketiniz.com'un web sitesi başka bir IP'de dursa bile (örneğin bir CDN arkasında), postanın nereye gideceğini yalnızca MX kaydı belirler. Web trafiği (A kaydı) ile e-posta trafiği (MX kaydı) birbirinden tamamen bağımsızdır. Bu ayrım, "sitem çalışıyor ama mailim gelmiyor" durumunun temel açıklamasıdır. DNS kayıt türlerinin genel mantığını tazelemek isterseniz DNS nedir rehberimiz iyi bir başlangıç noktasıdır.

MX Önceliği ve Birden Fazla Mail Sunucusu#

Bir alan adı için birden fazla MX kaydı tanımlayabilirsiniz ve gerçek dünyada bu çok yaygındır. Her MX kaydının başında bir öncelik (priority/preference) değeri bulunur; bu, gönderen sunucunun hangi mail sunucusunu önce deneyeceğini belirleyen bir sayıdır. Buradaki en önemli ve en çok kafa karıştıran kural şudur: Sayı küçüldükçe öncelik artar. Yani 10 önceliği, 20 önceliğinden daha "yüksek"tir ve önce denenir.

Gönderen sunucu her zaman en düşük sayılı MX'i önce dener. O sunucuya ulaşamazsa, sıradaki daha yüksek sayılı MX'e geçer. Bu yüzden birden fazla MX kaydı, aslında bir yedeklilik (failover) mekanizmasıdır: birincil sunucu çökerse, posta ikincil sunucuda kuyruğa alınır ve birincil geri geldiğinde teslim edilir. Aşağıdaki örnek, birincil ve yedek sunuculu klasik bir yapıyı gösterir:

; En düşük sayı = birincil sunucu (önce denenir)
sirketiniz.com.   IN   MX   10   mail1.sirketiniz.com.

; Daha yüksek sayı = yedek sunucu (birincil erişilemezse)
sirketiniz.com.   IN   MX   20   mail2.sirketiniz.com.

Öncelik değerlerinin aynı olması da mümkündür; bu durumda gönderen sunucular yükü kabaca eşit dağıtır (round-robin benzeri davranış). Google Workspace'in klasik beş kayıtlı yapısı bunun tipik örneğidir; birkaç sunucu aynı önceliği paylaşırken bazıları daha yüksek sayıyla yedek konumundadır. Öncelik mantığını netleştirmek için şu tabloya bakabilirsiniz:

Pratik bir uyarı: Tek bir mail sunucunuz varsa tek bir MX kaydı yeterlidir, öncelik değeri (örneğin 10) sadece formalitedir. Ama harici bir servise geçtiğinizde, o servisin verdiği MX kayıtlarını öncelik değerleriyle birlikte birebir girmeniz gerekir; öncelikleri karıştırmak, postanın yanlış sunucuda kuyruğa girmesine yol açar.

cPanel Email Routing Seçenekleri#

İşte cPanel'i özel yapan ve MX kaydıyla birlikte çalışan ikinci katman: Email Routing (E-posta Yönlendirme). cPanel arayüzünde E-posta > E-posta Yönlendirmesi (Email Routing) sayfasında bulunur. Bu ayar, sunucunun bu alan adının postasını nasıl ele alacağını söyler ve dört seçeneği vardır. MX kaydı "dünyaya postayı nereye getir" derken, Email Routing "ben bu alan adının sahibi miyim, postayı ben mi teslim edeyim" sorusunu yanıtlar. İkisinin uyumlu olması şarttır.

Dört seçenek ve anlamları şöyledir:

Bu tablodaki en kritik iki satır Local ve Remote'tur, çünkü en sık yapılan hata bu ikisini karıştırmaktır. Local Mail Exchanger modunda cPanel şöyle düşünür: "Bu alan adının e-postası bende. Kime mail gelirse gelsin, ben kendi hesaplarımda teslim ederim." Remote Mail Exchanger modunda ise: "Bu alan adının e-postası bende değil, başka bir sunucuda. Bir kullanıcım bu alan adına mail atsa bile, ben yerelde teslim etmem, MX kaydının gösterdiği dış sunucuya gönderirim."

Automatic (otomatik algılama) çoğu senaryoda en güvenli seçimdir çünkü cPanel, MX kaydınızı okuyup doğru modu kendisi belirlemeye çalışır: MX bu sunucuyu gösteriyorsa Local, dışarıyı gösteriyorsa Remote seçer. Ancak "otomatik" her zaman doğru tahmin edemez, özellikle DNS henüz yayılmamışsa ya da bölge dışarıda yönetiliyorsa. Bu yüzden harici bir servise geçerken otomatiğe güvenmek yerine elle Remote seçmek en sağlam yoldur — birazdan tam olarak bu senaryoya geleceğiz.

cPanel MX Entry Düzenlemek#

MX kaydını cPanel içinden düzenlemenin iki farklı yeri vardır ve bu ikisini karıştırmamak önemlidir. Birincisi Zone Editor (Bölge Düzenleyici), doğrudan DNS bölgesindeki MX kayıtlarını yönetir. İkincisi eski cPanel sürümlerindeki MX Entry aracıdır ki bu araç hem MX kaydını hem de yukarıda anlattığımız Email Routing ayarını aynı ekranda birleştirir. Modern cPanel'de bu işlevler çoğunlukla Zone Editor + Email Routing olarak ikiye ayrılmıştır.

Zone Editor üzerinden bir MX kaydı eklemek veya düzenlemek için şu adımları izleyin:

1. cPanel'e giriş yapın ve Alan Adları (Domains) bölümünde Zone Editor simgesine tıklayın.
2. İlgili alan adının yanındaki Manage (Yönet) bağlantısına basın.
3. Filtreden MX türünü seçin; mevcut MX kayıtları listelenir.
4. Yeni bir kayıt için Add Record > Add MX Record deyin; önceliği ve hedef hostname'i girin.
5. Değişiklikleri kaydedin ve TTL süresinin dolmasını (yayılma) bekleyin.

SSH erişiminiz varsa değişikliğin gerçekten oturup oturmadığını sunucu tarafında da doğrulayabilirsiniz. WHM/cPanel sunucularında bölge dosyaları genellikle şu konumda tutulur:

# Alan adının DNS bölge dosyasındaki MX satırlarını göster
grep -i "MX" /var/named/sirketiniz.com.db

# Örnek çıktı:
# sirketiniz.com.   14400   IN   MX   10   mail.sirketiniz.com.

MX kaydını her değiştirdiğinizde iki şeyi kafanızda tutun. Birincisi TTL (Time To Live): kaydın DNS önbelleklerinde ne kadar tutulacağını saniye cinsinden belirtir. Yukarıdaki örnekteki 14400, dört saat demektir; yani değişikliğiniz dünyaya tam olarak yayılana kadar bu kadar beklemeniz gerekebilir. Geçiş planlarken TTL'i önceden düşürmek (örneğin 300 saniye) akıllıca bir taktiktir. İkincisi, MX'in gösterdiği hostname'in mutlaka geçerli bir A kaydına sahip olması gerektiğidir; aksi halde gönderen sunucular hostname'i çözemez ve mail geri döner. Yayılma sürelerinin neden bazen uzadığını DNS propagasyon süresi rehberimizde daha ayrıntılı bulabilirsiniz.

Google Workspace veya Harici Servise Geçiş#

Sıra en çok soruyu alan senaryoda: hosting'iniz Clou.TR'de (ya da herhangi bir cPanel sunucuda) dursun, ama e-postanızı Google Workspace, Microsoft 365 veya başka bir harici mail servisiyle almak istiyorsunuz. Bu tamamen mümkündür ve doğru yapıldığında sorunsuz çalışır. İşin sırrı iki ayarı birden değiştirmektir: MX kaydını harici servise yöneltmek ve cPanel Email Routing'i Remote'a çekmek. Sadece birini yapmak, klasik "mail hem Google'da hem sunucuda arıyor ama hiçbirinde bulamıyor" arızasını doğurur.

Adımlar sırasıyla şöyledir. Önce mevcut tüm MX kayıtlarınızı Zone Editor'dan silin (özellikle sunucunuzu gösteren eski mail.sirketiniz.com kaydını), sonra harici servisin verdiği MX kayıtlarını ekleyin. Google Workspace'in güncel önerdiği tek kayıtlı yapı şudur:

; Google Workspace'in güncel tek MX kaydı yapısı
sirketiniz.com.   IN   MX   1   smtp.google.com.

Daha eski (ama hâlâ geçerli) beş kayıtlı Google yapısıysa öncelik mantığını güzel örnekler:

; Google Workspace klasik beş kayıtlı yapı
sirketiniz.com.   IN   MX   1    ASPMX.L.GOOGLE.COM.
sirketiniz.com.   IN   MX   5    ALT1.ASPMX.L.GOOGLE.COM.
sirketiniz.com.   IN   MX   5    ALT2.ASPMX.L.GOOGLE.COM.
sirketiniz.com.   IN   MX   10   ALT3.ASPMX.L.GOOGLE.COM.
sirketiniz.com.   IN   MX   10   ALT4.ASPMX.L.GOOGLE.COM.

MX kayıtlarını girdikten sonra mutlaka ikinci adımı atın: cPanel > Email Routing sayfasına gidin, ilgili alan adını seçin ve Remote Mail Exchanger işaretleyin. Bu adım neden bu kadar kritik? Çünkü Email Routing hâlâ Local'de kalırsa, sunucunuzdaki bir kullanıcı (veya sunucudaki bir web formu/WordPress sitesi) bu alan adına mail attığında, cPanel MX kaydını hiç dikkate almadan postayı kendi içindeki yerel hesaba teslim eder. Sonuç: Google'a hiç ulaşmayan, sunucudaki hayalet bir kutuda biriken kayıp mailler.

Geçiş sırasında karşılaşacağınız iki ayarı özetleyelim:

Son olarak, harici servise geçince SPF kaydınızı da güncellemeyi unutmayın; artık postayı Google gönderdiği için SPF'e include:_spf.google.com eklemeniz gerekir, aksi halde giden mailleriniz spam'e düşer. Bu konunun tamamı için SPF, DKIM ve DMARC rehberimizi okumanızı özellikle öneririm — MX'i doğru kurup kimlik doğrulama kayıtlarını unutmak, yarım kalmış bir geçiştir. E-posta altyapınızı komple taşıyorsanız site taşıma ve e-posta çözümleri sayfalarımız süreci kolaylaştırır.

Yaygın MX ve Routing Hataları#

Yılların deneyimiyle söyleyebilirim ki MX/routing sorunlarının neredeyse tamamı birkaç tekrar eden hatadan doğar. Bunları önceden bilmek, saatlerce süren sorun giderme yükünden sizi kurtarır. En sık karşılaşılanları tek tek ele alalım.

Birinci ve en yaygın hata: MX kaydını harici servise yöneltip Email Routing'i Local'de unutmak. Bu tam olarak yukarıda anlattığımız senaryodur; dışarıdan gelen mailler Google'a düşer ama sunucunuzdaki kullanıcılardan/scriptlerden çıkan iç postalar yerelde kalır. Belirtisi tuhaftır: "Bazı mailler geliyor, bazıları kayıp" ya da "WordPress iletişim formu maili hiç ulaşmıyor". Çözüm her zaman Email Routing'i Remote yapmaktır.

İkinci hata: MX kaydını IP adresine işaret ettirmek. MX bir hostname göstermek zorundadır. sirketiniz.com. IN MX 10 203.0.113.25 gibi bir kayıt teknik olarak geçersizdir ve gönderen sunucuların çoğu bu maili reddeder. Doğrusu, IP'yi bir A kaydına bağlayıp MX'i o hostname'e yöneltmektir.

Üçüncü hata: Eski MX kayıtlarını silmeden yenisini eklemek. Google'a geçerken eski mail.sirketiniz.com MX kaydını silmezseniz, iki farklı sistemi gösteren MX kayıtlarınız olur. Gönderen sunucular önceliğe göre birini seçer ve postanız rastgele iki yere dağılır. Geçişte daima önce eskiyi silin.

Dördüncü hata: MX değişikliğinin hemen aktif olmasını beklemek. DNS bir önbellek sistemidir; TTL süresi dolana kadar dünyanın bir kısmı hâlâ eski MX'i görür. Bir müşteriden mail geliyor, diğerinden gelmiyorsa büyük olasılıkla yayılma henüz tamamlanmamıştır. Sabır ya da düşük TTL, tek çözümdür.

Aşağıdaki tablo bu hataları belirti ve çözümleriyle özetler:

MX Kaydını Doğrulama ve Sorun Giderme#

MX ile ilgili her sorunda ilk yapmanız gereken, tahmin yürütmek değil, kaydın gerçekte ne olduğunu görmektir. DNS sorgusu yapan komut satırı araçları bu iş için birebirdir ve size kaydın dünyaya nasıl göründüğünü tam olarak söyler. Linux veya macOS'ta dig ve host, Windows'ta nslookup kullanılır.

En temel sorgu, alan adının MX kayıtlarını listelemektir:

# Alan adının MX kayıtlarını öncelik değerleriyle sorgula
dig MX sirketiniz.com +short

# Örnek çıktı:
# 1 smtp.google.com.

# host komutuyla daha okunaklı biçimde
host -t MX sirketiniz.com

# Örnek çıktı:
# sirketiniz.com mail is handled by 1 smtp.google.com.

Belirli bir DNS sunucusuna karşı sorgulama yapmak, "değişikliğim yayıldı mı" sorusunu yanıtlamanın en iyi yoludur. Örneğin Google'ın herkese açık 8.8.8.8 çözümleyicisine sorarak, değişikliğin genel internete ulaşıp ulaşmadığını görebilirsiniz:

# Değişikliği Google'ın public DNS'ine karşı doğrula (yayılma kontrolü)
dig MX sirketiniz.com @8.8.8.8 +short

# MX'in gösterdiği hostname'in A kaydını da mutlaka kontrol et
dig A mail.sirketiniz.com +short
# Boş dönerse MX kırıktır — hostname çözülemiyor demektir

Bu sorgulardan çıkan sonucu şöyle yorumlayın: Beklediğiniz MX değerini görüyorsanız ve gösterdiği hostname bir IP'ye çözülüyorsa, DNS tarafı sağlamdır; sorun büyük olasılıkla cPanel Email Routing ayarındadır. Beklediğinizden farklı ya da eski bir MX görüyorsanız, ya değişikliği kaydetmemişsinizdir ya da yayılma sürmektedir. Hiç MX görmüyorsanız, alan adının o an aktif nameserver'larının beklediğiniz yer olup olmadığını kontrol edin — bölge yanlış yerde yönetiliyor olabilir.

Bir uç noktayı da hatırlatayım: Eğer alan adınızın nameserver'ları Cloudflare ya da başka bir harici DNS sağlayıcıdaysa, cPanel'in Zone Editor'ında yaptığınız MX değişikliği hiçbir işe yaramaz, çünkü o alan adının otoriter bölgesi artık cPanel'de değildir. Bu durumda MX kaydını nameserver'ın bulunduğu panelde düzenlemeniz gerekir. Nameserver'ın nerede olduğunu görmek için dig NS sirketiniz.com +short komutunu çalıştırın; DNS'in bütününü kavramak için DNS nedir rehberimize göz atabilirsiniz. Sunucu tarafı yönetimi bir yük gibi geliyorsa sunucu yönetimi hizmetimiz tüm bu kontrolleri sizin yerinize üstlenir.

Sıkça Sorulan Sorular#

MX kaydı ile A kaydı arasındaki fark nedir?#

A kaydı bir alan adını (veya alt alan adını) bir IP adresine bağlar ve genellikle web trafiği için kullanılır; tarayıcı sirketiniz.com'a girdiğinde A kaydındaki IP'ye ulaşır. MX kaydı ise yalnızca e-posta içindir ve postanın hangi mail sunucusuna teslim edileceğini belirler; bir IP değil, bir hostname gösterir ve o hostname'in kendi A kaydı vardır. İkisi tamamen bağımsızdır, bu yüzden web siteniz bir sunucuda dururken e-postanız bambaşka bir yerde, örneğin Google Workspace'te olabilir. "Sitem açılıyor ama mailim gelmiyor" durumunun açıklaması tam olarak budur.

MX önceliğinde küçük sayı mı yüksek sayı mı önce denenir?#

Küçük sayı önce denenir. MX önceliği ters mantıkla çalışır: sayı ne kadar küçükse öncelik o kadar yüksektir. Yani 10 önceliğine sahip bir MX, 20 önceliğine sahip olandan önce denenir ve birincil sunucu odur. Gönderen sunucu en düşük sayılı MX'e ulaşamazsa, sıradaki daha yüksek sayılı MX'e geçer; bu yüzden yüksek sayılar genellikle yedek (backup) sunucular içindir. Eşit öncelik değerleri ise yükün sunucular arasında rastgele dağıtılması anlamına gelir.

Google Workspace'e geçtim ama e-postalar hâlâ eski sunucuya gidiyor, neden?#

Bunun neredeyse kesin nedeni, cPanel'deki Email Routing ayarının hâlâ Local Mail Exchanger'da kalmış olmasıdır. MX kayıtlarını Google'a yöneltmek tek başına yeterli değildir; cPanel > Email Routing sayfasından ilgili alan adını Remote Mail Exchanger olarak da işaretlemeniz gerekir. Aksi halde sunucu, MX kaydını görmezden gelip postayı kendi içindeki yerel hesaba teslim eder ve mailler Google'a hiç ulaşmaz. İkinci bir ihtimal, eski MX kayıtlarını silmeden yenilerini eklemenizdir; bu durumda eski sunucuyu gösteren MX hâlâ devrede olur. Ayrıca DNS yayılması için TTL süresinin dolmasını beklemeniz gerekebilir.

MX kaydını doğrudan bir IP adresine yönlendirebilir miyim?#

Hayır, yönlendirmemelisiniz. MX kaydı standart gereği bir hostname (sunucu adı) göstermek zorundadır, IP adresi değil. MX 10 203.0.113.25 gibi bir kayıt geçersizdir ve gönderen posta sunucularının büyük çoğunluğu bu tür bir MX'e teslimatı reddeder. Doğru yol, o IP'yi bir A kaydıyla bir hostname'e (örneğin mail.sirketiniz.com) bağlamak ve MX kaydını o hostname'e yöneltmektir. Böylece zincir MX → hostname → A kaydı → IP şeklinde standarda uygun tamamlanır.

Email Routing'i Automatic bırakmak güvenli mi?#

Çoğu durumda evet, güvenlidir. Automatic (Automatically Detect Configuration) seçeneği, cPanel'in MX kaydınıza bakarak doğru modu kendisinin seçmesini sağlar; MX sunucuyu gösteriyorsa Local, dışarıyı gösteriyorsa Remote moduna geçer. Ancak DNS henüz yayılmadıysa ya da bölge harici bir yerde yönetiliyorsa otomatik algılama yanlış tahmin edebilir. Bu yüzden harici bir servise (Google, Microsoft 365 vb.) geçerken otomatiğe güvenmek yerine Email Routing'i elle Remote Mail Exchanger olarak işaretlemek en sağlam yaklaşımdır. Postayı bu sunucuda tutuyorsanız Automatic veya Local ikisi de sorunsuz çalışır.

MX kaydını değiştirdim, ne kadar sürede aktif olur?#

Bu süre büyük ölçüde kaydın TTL (Time To Live) değerine bağlıdır. TTL, kaydın DNS önbelleklerinde ne kadar saklanacağını saniye cinsinden belirtir; örneğin 14400 saniyelik bir TTL, dört saate kadar bir yayılma süresi anlamına gelir. Bu süre boyunca dünyanın bir kısmı yeni MX'i görürken bir kısmı hâlâ eskisini görebilir, bu yüzden geçiş sırasında "bazı mailler eski, bazıları yeni yere gidiyor" durumu normaldir. Planlı bir geçişte, değişiklikten birkaç saat önce TTL'i düşük bir değere (örneğin 300 saniye) çekmek yayılmayı hızlandırır ve kesinti penceresini daraltır.

Kapanış#

MX kaydı ve cPanel Email Routing, ilk bakışta iki ayrı ayarmış gibi görünse de aslında tek bir sorunun iki yarısıdır: "Bu alan adının postası nerede teslim edilecek?" DNS'teki MX kaydı postayı doğru sunucuya getirir, cPanel'deki Email Routing ise sunucunun o postayı yerelde mi teslim edeceğine yoksa dışarı mı çıkaracağına karar verir. İkisi uyumlu olduğunda e-posta akışı görünmez ve kusursuz çalışır; uyumsuz olduğunda ise sunucu tarafında hiç hata görünmeden mailler sessizce kaybolur. Bu rehberdeki üç altın kuralı aklınızda tutun: MX daima bir hostname göstersin, öncelikte küçük sayı önce denensin ve harici servise geçerken MX ile birlikte Email Routing'i mutlaka Remote yapın. Geçiş sonrasında dig MX ile doğrulamayı ve SPF kaydını güncellemeyi de ihmal etmeyin.

Clou.TR'nin cPanel tabanlı web hosting paketleri, Zone Editor ve Email Routing üzerinden MX yönetimini kutudan çıktığı gibi tam kontrolle sunar; ister postayı sunucuda tutun, ister Google Workspace veya harici bir servise yönlendirin, geçiş birkaç doğru tıklamayla tamamlanır. E-posta iş yükü yoğun projeler için kurumsal web hosting ve WordPress hosting çözümlerimiz, daha fazla kaynak isteyen ekipler içinse sanal sunucularımız ve uçtan uca yönetim sağlayan sunucu yönetimi hizmetimiz devrede. Alan adınızı, e-postanızı ve teslimat ayarlarınızı tek çatı altında doğru kurmaya bugün başlayın; MX geçişinde takılırsanız destek ekibimiz her adımda yanınızda.