Bir müşteriye ornek.com.tr adresine gönderilen e-postanın nasıl olup da doğru gelen kutusuna düştüğünü anlatmam gerektiğinde hep aynı yerden başlarım: internetin hiçbir yerinde "e-postalar buraya gelsin" diye yazan sihirli bir etiket yoktur. Gönderen sunucu, alıcının alan adına baktığında yalnızca DNS bölgesindeki kayıtları görür. İşte bu kayıtlar arasından, "bu alan adına gelen postayı hangi makine teslim alacak" sorusunun cevabını veren tek kayıt türü MX kaydıdır. Açılımı Mail Exchanger'dır ve adı üstünde, alan adı ile posta sunucusu arasındaki köprüyü kurar.
MX kaydını yanlış yapılandırmak, kurumsal bir e-posta hesabının başına gelebilecek en sinsi sorundur; çünkü web siteniz sorunsuz açılmaya devam ederken postalar sessizce kaybolur ya da geri döner. Onlarca kez şu senaryoyu gördüm: firma Google Workspace'e ya da Microsoft 365'e geçiyor, panelde her şey yeşil görünüyor, ama gelen postaların bir kısmı hâlâ eski hosting sunucusuna düşüyor. Sebep neredeyse her seferinde aynı: eski MX kayıtları silinmemiş, öncelik değerleri karışmış ya da DNS yayılması beklenmeden test edilmiş. Bu rehberde MX kaydının nasıl çalıştığını, öncelik mantığını, birden fazla sunucuyla yedeklemeyi ve Google Workspace ile Microsoft 365 için doğru yapılandırmayı adım adım anlatacağım.
MX Kaydı Tam Olarak Ne İşe Yarar#
Bir e-posta sunucusu (örneğin Gmail'in giden sunucusu) [email protected] adresine posta göndereceği zaman, @ işaretinden sonraki alan adını alır ve o alan adının DNS bölgesine MX sorgusu yapar. DNS de bu alan adına gelen postaları teslim alacak sunucunun ana makine adını (hostname) döner. Gönderen sunucu bu hostname'i bir A veya AAAA kaydıyla IP adresine çevirir, ardından o IP'nin 25 numaralı SMTP portuna bağlanıp postayı teslim eder. Kısacası MX kaydı, alan adı ile fiziksel posta sunucusu arasındaki yönlendirme tablosudur.
Burada çok kritik ve sık atlanan bir kural var: MX kaydı asla bir IP adresini değil, her zaman bir alan adını (hostname) işaret etmelidir. RFC standartları IP'ye işaret eden MX kaydını geçersiz sayar ve birçok gönderen sunucu böyle bir kaydı olan alan adlarından gelen postaları reddeder. Doğru sıralama şudur: MX kaydı bir hostname'e, o hostname de ayrı bir A/AAAA kaydıyla IP'ye işaret eder.
; DOĞRU kullanım
ornek.com.tr. IN MX 10 mail.ornek.com.tr.
mail.ornek.com.tr. IN A 203.0.113.25
; YANLIŞ kullanım — MX asla doğrudan IP göstermez
ornek.com.tr. IN MX 10 203.0.113.25
MX kaydının bir başka önemli özelliği, web trafiğinden tamamen bağımsız çalışmasıdır. www.ornek.com.tr sitenizi bir sunucuda barındırıp e-postalarınızı bambaşka bir sağlayıcıda tutabilirsiniz. A kaydı web sunucusunu, MX kaydı posta sunucusunu gösterir ve ikisi birbirine karışmaz. Bu ayrım, "hosting firmamı değiştirdim ama e-postalarım Google'da kalsın" gibi ihtiyaçların neden sorunsuz karşılanabildiğini de açıklar. DNS'in genel mantığını daha derinlemesine görmek isterseniz DNS nedir yazısı temel oluşturur.
Öncelik (Priority) Değeri Nasıl Çalışır#
Her MX kaydının önünde bir sayı bulunur; buna öncelik ya da tercih (preference) değeri denir. Bu sayının çalışma mantığı sezgiye ters gelebilir çünkü düşük sayı daha yüksek önceliği ifade eder. Yani 10 öncelikli bir sunucu, 20 öncelikli sunuçtan önce denenir. Gönderen sunucu, alan adının tüm MX kayıtlarını toplar, en düşük öncelik değerine sahip olanı seçer ve postayı önce ona teslim etmeye çalışır.
Öncelik değerinin mutlak büyüklüğünün bir anlamı yoktur; önemli olan kayıtlar arasındaki göreceli sıralamadır. 1 ve 2 ile 10 ve 20 aynı davranışı üretir. Ben genelde 10, 20, 30 gibi onarlı adımlar kullanmayı tercih ederim, çünkü ileride araya yeni bir sunucu eklemek gerekirse 15 gibi bir ara değere yer kalır. Aşağıdaki tablo öncelik mantığını özetliyor.
| Öncelik değeri | Anlamı | Ne zaman kullanılır |
|---|---|---|
| 0 - 10 | En yüksek öncelik, ilk denenen | Birincil (primary) posta sunucusu |
| 20 - 30 | İkincil, ancak birincil erişilemezse | Yedek (backup) MX sunucusu |
| 40 ve üzeri | Son çare | Nadir; çok katmanlı yedeklemede |
| Aynı değer (eşit) | Yük dağıtımı, rastgele seçim | Birden fazla eşdeğer sunucu |
Eğer iki MX kaydı aynı öncelik değerine sahipse, gönderen sunucu ikisi arasından rastgele birini seçer. Bu davranış, gelen posta yükünü birden fazla sunucuya dağıtmak (load balancing) için kullanılır. Google Workspace'in eski yapılandırmalarında beş adet eşit öncelikli sunucu görmenizin sebebi tam olarak buydu; gelen postalar bu beş kapı arasında dengeli biçimde dağılırdı.
Birden Fazla MX Kaydı ve Yedekleme#
Bir alan adına tek MX kaydı tanımlamak teknik olarak yeterlidir, ancak ciddi bir kurumsal kurulumda tek başına yeterli değildir. Birincil posta sunucunuz bakıma girer, çöker ya da geçici olarak ağdan düşerse, o an gönderilen postalara ne olur? İşte burada ikincil (backup) MX kaydı devreye girer. Daha yüksek öncelik değeriyle (yani daha düşük öncelikli olarak) tanımlanan bir yedek sunucu, birincil sunucu erişilemez olduğunda postaları geçici olarak teslim alır ve kuyruğa (queue) koyar.
ornek.com.tr. IN MX 10 mail1.ornek.com.tr. ; birincil
ornek.com.tr. IN MX 20 mail2.ornek.com.tr. ; birincil erişilemezse
ornek.com.tr. IN MX 30 backup.saglayici.com. ; son çare, sadece kuyruğa alır
Yedek MX'in çalışma mantığını doğru anlamak önemlidir. Birincil sunucu geri geldiğinde, yedek sunucu kuyruğunda bekleyen postaları birincil sunucuya iletir; posta hiçbir zaman doğrudan kullanıcının kutusuna yedek sunucu tarafından yazılmaz. Bu yüzden yedek MX sunucusunun, sizin alan adınıza ait geçerli kullanıcı listesini tanıması gerekir. Aksi halde spam gönderenler, var olmayan adreslere yönelik postaları yedek sunucuya bırakır, yedek sunucu bunları birincile iletmeye çalışır ve "backscatter" denen geri sekmeli spam sorunu ortaya çıkar.
Modern bulut e-posta sağlayıcıları (Google, Microsoft) zaten kendi altyapılarında coğrafi olarak dağıtılmış, yüksek erişilebilirlikli sunucular çalıştırdığı için ayrıca yedek MX tanımlamanıza gerek kalmaz. Yedek MX ihtiyacı daha çok kendi posta sunucunuzu (Postfix, Exim, Mailcow gibi) işlettiğinizde ortaya çıkar. Kendi sunucunuzu barındırmak için sağlam bir alt yapıya ihtiyacınız varsa VDS sunucu veya yönetimini bize bırakabileceğiniz sunucu yönetimi hizmetlerimiz iş yükünü hafifletir.
Google Workspace İçin MX Yapılandırması#
Google Workspace (eski adıyla G Suite), alan adınızın e-postalarını Google'ın altyapısında barındırmanızı sağlar. Kurulumun kalbi, alan adınızın DNS bölgesindeki eski MX kayıtlarını silip Google'ın tek MX kaydını eklemektir. Google, birkaç yıldır beş ayrı sunucu yerine tek ve basit bir MX hedefi öneriyor. Aşağıdaki tablo güncel yapılandırmayı gösterir.
| Kayıt türü | Ana makine (host) | Öncelik | Hedef |
|---|---|---|---|
| MX | @ | 1 | smtp.google.com |
DNS bölge dosyası biçiminde ise şöyle görünür:
ornek.com.tr. IN MX 1 smtp.google.com.
Yapılandırma adımları pratikte şöyle işler. Önce alan adınızın DNS yönetim paneline girip mevcut tüm MX kayıtlarını temizlemelisiniz; eski hosting sağlayıcınızdan kalma mail.ornek.com.tr gibi kayıtlar burada kalırsa postalar bölünür. Ardından yukarıdaki tek MX kaydını eklersiniz. Google Workspace panelinde "Etkinleştir" butonuna bastığınızda Google, MX kaydını doğrulamak için bir tarama yapar. Doğrulama başarılı olduktan sonra postalar Google'a akmaya başlar.
MX kaydını eklemekle iş bitmez; e-postalarınızın karşı tarafta spam'e düşmemesi için SPF, DKIM ve DMARC kayıtlarını da tanımlamanız şarttır. Google Workspace için tipik SPF kaydı aşağıdaki gibidir.
ornek.com.tr. IN TXT "v=spf1 include:_spf.google.com ~all"
Bu kimlik doğrulama kayıtlarının her birinin ne işe yaradığını ve nasıl kurulduğunu SPF, DKIM ve DMARC yazısında ayrıntılı biçimde ele aldım; MX kaydını doğru kurup bu üçlüyü atlarsanız postalarınızın önemli bir kısmı hedefin spam kutusuna düşer.
Microsoft 365 İçin MX Yapılandırması#
Microsoft 365 (eski adıyla Office 365), MX yapılandırmasında Google'a benzer bir yol izler ancak hedef sunucu adı alan adınıza özeldir. Microsoft, her müşteri alan adı için alanadi-com-tr.mail.protection.outlook.com biçiminde otomatik üretilmiş bir hedef atar. Buradaki nokta ile ayrılan alan adı bölümü, sizin alan adınızdaki noktalar tireye çevrilerek oluşturulur; yani ornek.com.tr için hedef ornek-com-tr.mail.protection.outlook.com olur.
| Kayıt türü | Ana makine (host) | Öncelik | Hedef |
|---|---|---|---|
| MX | @ | 0 | ornek-com-tr.mail.protection.outlook.com |
DNS bölge dosyasında şu şekilde ifade edilir:
ornek.com.tr. IN MX 0 ornek-com-tr.mail.protection.outlook.com.
Microsoft 365 için doğru hedef adını her zaman kendi yönetim merkezinizden (Microsoft 365 admin center → Setup → Domains) teyit etmelisiniz, çünkü hedef adı alan adınıza göre değişir ve elle tahmin etmek hataya açıktır. Microsoft'un öncelik değeri olarak 0 kullanması, "bu en yüksek öncelikli ve tek sunucu" demektir. Google'da olduğu gibi burada da eski MX kayıtlarını mutlaka silmeniz gerekir.
Microsoft 365 kurulumunu tamamlamak için MX'in yanında birkaç kayıt daha eklersiniz. Otomatik keşif (autodiscover) için bir CNAME, SPF için bir TXT ve DKIM için iki CNAME kaydı standart settir. SPF kaydı şu biçimdedir.
ornek.com.tr. IN TXT "v=spf1 include:spf.protection.outlook.com -all"
autodiscover IN CNAME autodiscover.outlook.com.
autodiscover kaydı, Outlook istemcilerinin sunucu ayarlarını otomatik bulmasını sağlar ve kurumsal kullanımda kullanıcıların manuel ayar yapmadan hesaplarını bağlamasına imkân verir. SPF kaydındaki -all (sert ret) ile ~all (yumuşak ret) arasındaki farkı bilinçli seçmelisiniz; Microsoft kendi kurulumunda -all önerir.
MX Kaydını Doğrulama ve Test Etme#
MX kaydını değiştirdikten sonra hemen test etmek isteyeceksiniz, ancak DNS yayılmasının (propagation) tamamlanmasını beklemeniz gerekir. TTL değeriniz düşükse (örneğin 300 saniye) değişiklik dakikalar içinde yayılır; yüksekse (86400 saniye, yani 24 saat) bir gün sürebilir. Bu yüzden büyük bir MX değişikliğinden birkaç gün önce TTL değerini düşürmek profesyonel bir alışkanlıktır. Komut satırından MX kaydını sorgulamanın en pratik yolu dig aracıdır.
# MX kayıtlarını öncelik değerleriyle listeler
dig +short MX ornek.com.tr
# Belirli bir DNS sunucusundan sorgulamak için (örneğin Google'ın 8.8.8.8'i)
dig @8.8.8.8 MX ornek.com.tr
# Windows kullanıyorsanız nslookup ile
nslookup -type=MX ornek.com.tr
dig +short MX çıktısı size öncelik değeri ve hedef sunucu çiftlerini verir; örneğin 10 mail.ornek.com.tr. gibi. Bu çıktıda eski, silmeyi unuttuğunuz bir sunucu görüyorsanız hemen temizleyin. Gerçek bir teslimat testi için ise alan adınıza dışarıdan bir posta gönderip gelip gelmediğini kontrol etmek en kesin yöntemdir. SMTP bağlantısını manuel test etmek isterseniz, hedef portun (25) açık olup olmadığını da doğrulayabilirsiniz.
# Posta sunucusunun 25 portuna bağlanabiliyor musunuz kontrol edin
nc -zv mail.ornek.com.tr 25
# SMTP karşılama banner'ını görmek için
openssl s_client -connect mail.ornek.com.tr:25 -starttls smtp
Sık karşılaşılan bir hata da MX hedefinin bir CNAME kaydına işaret etmesidir. RFC standartları, MX kaydının hedefinin doğrudan A/AAAA kaydına çözülmesini şart koşar; hedef bir CNAME ise bu standart dışıdır ve bazı gönderen sunucular teslimatı reddeder. Bu yüzden MX hedefi olarak her zaman doğrudan A kaydına sahip bir hostname kullanın. Alan adınızın DNS yönetimini Clou.TR panelinden yapıyorsanız bu tür hataları arayüz üzerinden görsel olarak fark etmek çok daha kolaydır; kendi alan adınızı domain sayfamızdan yönetebilirsiniz.
Sık Yapılan MX Hataları ve Çözümleri#
Yıllar içinde MX kaynaklı sorunların büyük çoğunluğunun birkaç tekrarlayan hatadan kaynaklandığını gördüm. Bunların başında eski kayıtların silinmemesi gelir. Yeni sağlayıcıya geçerken önceki MX kayıtlarını bırakırsanız, gönderen sunucular öncelik değerine göre bazen eskiye bazen yeniye teslim yapar ve postalarınız iki sunucu arasında bölünür. Kural basittir: yalnızca aktif sağlayıcınızın MX kaydı DNS bölgenizde bulunmalıdır.
İkinci sık hata, MX hedefinde IP adresi kullanmaktır. Yukarıda değindiğim gibi, MX kaydı bir hostname göstermelidir. Üçüncüsü, öncelik mantığının tersine anlaşılmasıdır; birileri yedek sunucuya birincilden daha düşük bir sayı verip yanlışlıkla tüm postaları yedek sunucuya yönlendirir. Aşağıdaki tablo bu tipik hataları ve doğru yaklaşımı bir arada gösterir.
| Hata | Belirti | Çözüm |
|---|---|---|
| Eski MX kaydı silinmemiş | Postaların bir kısmı kayboluyor | Sadece aktif sağlayıcının MX'i kalsın |
| MX hedefi IP adresi | Bazı sunucular postayı reddediyor | Hostname kullan, ayrı A kaydı ekle |
| Öncelik değerleri ters | Postalar yanlış sunucuya gidiyor | Birincile düşük sayı ver |
| MX hedefi CNAME'e işaret ediyor | Aralıklı teslim hataları | Doğrudan A kaydına işaret et |
| SPF/DKIM eksik | Postalar spam'e düşüyor | Kimlik doğrulama kayıtlarını ekle |
Dördüncü sinsi hata, MX değişikliğinin ardından posta hesaplarının karşı tarafta oluşturulmamasıdır. MX'i Google'a yönelttiğiniz halde Google Workspace panelinde ilgili kullanıcıyı henüz oluşturmadıysanız, o adrese gelen postalar "kullanıcı bulunamadı" hatasıyla geri döner. Doğru sıralama, önce yeni sağlayıcıda kullanıcıları oluşturmak, sonra MX'i geçirmektir. Kurumsal e-posta altyapınızı sıfırdan kurarken sunucu ve alan adı tarafını tek elden yönetmek işleri kolaylaştırır; e-posta çözümlerimiz ve hosting paketlerimiz bu bütünlüğü sağlar.
Sıkça Sorulan Sorular#
MX kaydı olmadan e-posta alabilir miyim?#
Teknik olarak bir alan adında MX kaydı yoksa, gönderen sunucular RFC kuralları gereği o alan adının A kaydını yedek olarak dener ve postayı web sunucusunun IP'sine teslim etmeye çalışır. Ancak bu davranış her sunucuda garantili değildir ve modern spam filtreleri MX'siz alan adlarını şüpheyle karşılar. Güvenilir e-posta alımı için mutlaka açık ve doğru bir MX kaydı tanımlamalısınız.
Birden fazla MX kaydı aynı önceliğe sahip olursa ne olur?#
Aynı öncelik değerine sahip MX kayıtları arasından gönderen sunucu rastgele birini seçer ve gelen posta yükünü bu sunuçlara dağıtır. Bu, yük dengeleme (load balancing) amacıyla kullanılan geçerli ve yaygın bir yöntemdir. Sunuçlardan biri erişilemezse, gönderen aynı öncelikteki diğerini dener; hepsi erişilemezse bir üst öncelik değerine geçer.
MX kaydı değişikliği ne kadar sürede aktif olur?#
Değişikliğin yayılma süresi tamamen kaydın TTL değerine bağlıdır. TTL 300 saniye ise değişiklik birkaç dakika içinde dünya genelinde geçerli olur; 86400 saniye (24 saat) ise bir güne kadar sürebilir. Bu yüzden büyük bir MX geçişinden bir iki gün önce TTL değerini düşürmek, geçiş anında kesinti süresini en aza indiren profesyonel bir uygulamadır.
MX kaydı web sitemi etkiler mi?#
Hayır, MX kaydı yalnızca gelen e-postaların yönlendirilmesini kontrol eder ve web sitenizin çalışmasıyla hiçbir ilişkisi yoktur. Web trafiği A ve AAAA kayıtlarıyla, e-posta ise MX kaydıyla yönetilir. Bu ayrım sayesinde sitenizi bir sunucuda, e-postalarınızı ise Google Workspace ya da Microsoft 365 gibi tamamen farklı bir sağlayıcıda tutabilirsiniz.
MX kaydını doğrudan IP adresine yönlendirebilir miyim?#
Hayır, MX kaydı standart gereği bir IP adresine değil, her zaman bir alan adına (hostname) işaret etmelidir. IP'ye işaret eden bir MX kaydı geçersiz sayılır ve birçok gönderen sunucu bu tür alan adlarından gelen postaları reddeder. Doğru yöntem, MX kaydını bir hostname'e yöneltmek ve o hostname için ayrı bir A veya AAAA kaydıyla IP adresini tanımlamaktır.
Yedek MX kaydına gerçekten ihtiyacım var mı?#
Google Workspace veya Microsoft 365 gibi bulut sağlayıcıları kullanıyorsanız, bu servisler zaten coğrafi olarak dağıtılmış yüksek erişilebilirlikli altyapı sunduğu için ayrıca yedek MX tanımlamanıza gerek yoktur. Yedek MX ihtiyacı daha çok Postfix veya Mailcow gibi kendi posta sunucunuzu işlettiğinizde ortaya çıkar; birincil sunucunuz kısa süreli kesintilere maruz kalabiliyorsa yedek MX postaların kaybolmadan kuyruğa alınmasını sağlar.
Kapanış#
MX kaydı, e-posta altyapınızın görünmez ama en kritik parçasıdır; doğru yapılandırıldığında hiç fark etmezsiniz, yanlış olduğunda ise postalarınız sessizce kaybolur. Özetlersek: MX kaydı her zaman bir hostname'e işaret eder, düşük öncelik değeri önce denenir, yeni sağlayıcıya geçerken eski kayıtları mutlaka silmeniz gerekir ve MX'in yanına SPF, DKIM, DMARC eklemeden e-posta güvenliğiniz eksik kalır. Google Workspace ve Microsoft 365 kurulumları basit görünse de, eski kayıtların temizlenmesi ve doğrulama adımları atlanmadan yapılmalıdır.
Clou.TR olarak alan adı yönetiminden kurumsal e-posta çözümlerine, hosting paketlerinden sunucu yönetimine kadar tüm e-posta altyapınızı tek çatı altında sunuyoruz. Alan adınızın DNS kayıtlarını sezgisel panelimizden yönetebilir, e-posta hizmetlerimizle güvenilir bir gelen kutusuna kavuşabilir ya da kendi posta sunucunuzu barındırmak için VDS sunucu ve sunucu yönetimi çözümlerimizden yararlanabilirsiniz. MX kaydınızı doğru kurmak için desteğe ihtiyacınız olursa ekibimiz her adımda yanınızda.