Teknik·
29 Mart 2026
Kurumsal e-posta altyapısının görünmez temeli olan MX (Mail Exchanger) kaydı, gönderilen her e-postanın doğru sunucuya ulaşmasını sağlar. Bu kaydın hatalı yapılandırılması; gelen e-postaların kaybolmasına, spam filtrelerine takılmasına veya teslim gecikmelerine yol açar. Özellikle pazarlama otomasyonu ve toplu gönderim kullanan işletmeler için MX kaydının doğru kurulumu, teslim edilebilirlik oranlarını doğrudan etkiler.
DNS (Alan Adı Sistemi) içindeki kayıt türlerinden biri olan MX kaydı, RFC 1035 ve daha ayrıntılı biçimde RFC 7505 ile standartlaştırılmıştır. Bir e-posta gönderildiğinde, gönderen SMTP sunucusu önce alıcının alan adına ait MX kayıtlarını sorgular; ardından bu kayıtlarda tanımlı posta sunucusuna bağlantı kurar. RFC 5321 standardına göre SMTP sunucuları, MX kaydı bulunamadığında alan adının A veya AAAA kaydına doğrudan bağlanma yolunu deneyebilir; ancak bu durum son derece nadir ve sorunlu bir geri dönüş mekanizmasıdır.
MX kaydının anatomisi üç temel bileşenden oluşur: alan adı (e-postanın teslim edileceği alan), öncelik değeri (0–65535 arası tam sayı, düşük değer daha yüksek öncelik anlamına gelir) ve hedef hostname (posta sunucusunun FQDN adresi). Önemli bir teknik detay olarak hedef hostname değerinin bir IP adresi değil, çözümlenebilir bir alan adı olması zorunludur; aksi hâlde RFC 2181'e aykırılık söz konusu olur.
Birden fazla MX kaydı tanımlandığında gönderen sunucu, önce en düşük öncelik değerine sahip sunucuya bağlanmayı dener. Bu sunucu yanıt vermezse sıradaki öncelik değerine geçilir. Google Workspace yönetici yardım merkezinin belgelediği üzere, Google'ın posta altyapısı varsayılan olarak beş farklı öncelik kademesiyle (1, 5, 5, 10, 10) yapılandırılmaktadır; bu sayede hem yük dağılımı hem de yüksek erişilebilirlik sağlanmaktadır. Microsoft 365 ise tek bir hedef hostname kullanmakla birlikte, söz konusu hostname'in arkasında yük dengeleme altyapısını kendi içinde yönetir.
Aynı öncelik değerine sahip birden fazla MX kaydı tanımlanması durumunda gönderen sunucu, RFC 5321'in 5.1. bölümünde belirtildiği üzere bu sunucular arasında rastgele seçim yapar. Bu yaklaşım basit bir yük dengeleme mekanizması sağlar, ancak sunucu başına farklı kapasite tanımlanamaz.
| Hizmet Sağlayıcı | Öncelik | Hedef Hostname | TTL (saniye) |
|---|---|---|---|
| Google Workspace | 1 | aspmx.l.google.com | 3600 |
| Google Workspace (yedek) | 5 | alt1.aspmx.l.google.com | 3600 |
| Microsoft 365 | 0 | firma-com.mail.protection.outlook.com | 3600 |
| Connect365 | 10 | mail.firma.com.tr | 3600 |
| Özel SMTP + Yedek | 10 / 20 | mx1.firma.com / mx2.firma.com | 1800 |
MX kaydının doğru yapılandırılması, e-posta teslim edilebilirliğinin yalnızca ilk adımıdır. SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) ve DMARC kayıtlarıyla birlikte çalışan MX kaydı, alıcı sunucunun mesajın meşruiyetini doğrulamasına olanak tanır. Google ve Yahoo'nun Şubat 2024'te yürürlüğe giren toplu gönderici yönergelerinde, günde 5.000'den fazla e-posta gönderen alan adlarının SPF, DKIM ve DMARC kayıtlarına sahip olması zorunlu kılınmıştır; MX kaydının bu kayıtlarla tutarlı olması ise bu zorunluluğun temel ön koşuludur.
Reverse DNS (PTR) kaydının MX kaydıyla uyumlu olması da kritiktir. Gönderen sunucunun IP adresi için tanımlı PTR kaydı, MX kaydındaki hostname ile örtüşmüyorsa pek çok alıcı sunucu mesajı spam olarak işaretleyebilir. IETF'nin RFC 7208 belgesine göre bu tutarsızlık, SPF soft fail veya hard fail sonuçlarına zemin hazırlayabilir.
Yalnızca e-posta gönderen ancak almayan alan adları için RFC 7505, "null MX" adı verilen özel bir yapılandırmayı tanımlamıştır. Bu yapılandırmada öncelik değeri 0, hedef ise tek bir nokta (.) olarak belirlenir:
firma.com. IN MX 0 .
Null MX kullanan alan adlarına e-posta göndermeye çalışan SMTP sunucuları, 5xx serisi kalıcı hata kodu alır ve mesajı tekrar denemez. Bu yapılandırma, işlem e-postalarının farklı bir alt alan adı (örneğin no-reply.firma.com) üzerinden yürütüldüğü kurumsal ortamlarda yaygın biçimde tercih edilmektedir.
MX kaydında yapılan değişikliklerin tüm DNS çözümleyicilere yayılması, mevcut TTL değerine bağlıdır. Kritik bir geçiş öncesinde TTL değerinin 300–600 saniyeye indirilmesi, olası hata durumlarında hızlı geri dönüş imkânı sağlar. ICANN'ın DNS operasyonları rehberinde, büyük altyapı değişiklikleri öncesinde TTL değerinin en az 48 saat önceden düşürülmesi tavsiye edilmektedir. Geçiş tamamlandıktan sonra TTL, 3600 (1 saat) veya 86400 (24 saat) gibi standart değerlere geri alınabilir.
Dikkat edilmesi gereken önemli bir nokta: MX kaydı değişikliği sırasında eski ve yeni posta sunucusunun aynı anda aktif tutulması gerekir. Eski sunucu kapatılmadan önce DNS yayılımının tamamlandığından emin olmak için dig MX firma.com @8.8.8.8 veya nslookup -type=MX firma.com komutlarıyla doğrulama yapılmalıdır.
MX kaydının doğruluğunu test etmek için birden fazla yöntem kullanılabilir. MXToolbox, dnschecker.org ve Google Admin Toolbox (G Suite Toolbox) gibi çevrimiçi araçlar, farklı coğrafi konumlardan eş zamanlı DNS sorguları yaparak yayılım durumunu görselleştirir. Komut satırı araçlarından dig, Unix/Linux sistemlerde standart olarak gelirken Windows'ta nslookup aynı işlevi görür. SMTP bağlantısının çalışıp çalışmadığını test etmek için ise telnet mx1.firma.com 25 komutuyla doğrudan sunucuya bağlantı denenebilir.
Teknik olarak bazı SMTP sunucuları, MX kaydı bulunamadığında RFC 5321'in geri dönüş mekanizmasıyla A kaydına bağlanmayı deneyebilir; ancak modern posta sunucularının büyük çoğunluğu bu davranışı gerçekleştirmez ve e-postayı teslim edilemez olarak işaretler. MX kaydı olmayan bir alan adına güvenilir biçimde e-posta alınması mümkün değildir.
Birden fazla MX kaydı tanımlandığında öncelik değeri belirleyicidir. Tek MX kaydı kullanan alan adlarında öncelik değerinin önemi yoktur; ancak genel kullanımda 10 veya 0 tercih edilir. İki sunucu arasında aktif-pasif yedeklilik istiyorsanız birincil sunucuya 10, yedek sunucuya 20 gibi daha yüksek bir değer verilmelidir.
Bu süre, mevcut TTL değerine bağlıdır. Eğer TTL 3600 saniye (1 saat) ise eski kaydın DNS önbelleklerinden temizlenmesi en fazla 1 saat sürer; TTL 86400 saniye ise 24 saate kadar çıkabilir. Geçiş öncesinde TTL'yi 300–600 saniyeye indirmek, değişikliklerin çok daha hızlı yayılmasını sağlar.
Hayır. Bir alan adı için tanımlanan tüm MX kayıtları aynı posta sistemine yönlenmelidir. Farklı MX kayıtlarının farklı posta servislerine işaret etmesi; e-postaların kısmen bir servise, kısmen diğerine teslim edilmesine neden olur. Birden fazla servis kullanmak istiyorsanız alt alan adları (marketing.firma.com, destek.firma.com) oluşturmanız gerekir.
Hayır. RFC 2181 ve RFC 5321'e göre MX kaydının hedef alanı mutlaka bir FQDN (Fully Qualified Domain Name) olmalıdır; IP adresi yazılamaz. IP adresi kullanılırsa gönderen SMTP sunucuları bu kaydı geçersiz sayar ve e-posta teslimini reddedebilir.
MX kaydı doğrulansa bile e-posta teslim sorunlarının başka nedenleri olabilir: posta sunucusunda 25. portun kapalı olması, SPF/DKIM uyumsuzluğu nedeniyle spam filtrelerine takılma, reverse DNS (PTR) kaydının eksikliği veya sunucunun kara listede (blacklist) yer alması. MXToolbox'ın kara liste sorgulama aracıyla IP adresinizin listede olup olmadığını kontrol edebilirsiniz.
Yalnızca e-posta gönderip almayan, aldığında ise bu e-postaların kaybolmasını ya da hata mesajı vermesini tercih eden alan adları için uygundur. Örneğin işlem e-postalarını no-reply@bildirim.firma.com adresinden gönderen ancak bu adrese gelen yanıtların otomatik reddedilmesini isteyen yapılar için RFC 7505 kapsamında null MX idealdir.
Geçiş süreci doğru planlanırsa e-posta kaybı yaşanmaz. Eski MX kaydını silmeden önce yeni MX kaydını ekleyin ve DNS yayılımının tamamlanmasını bekleyin. Her iki sunucuyu bir süre paralel çalıştırın; yeni sunucuya e-postalar gelmeye başladıktan sonra eski kaydı kaldırın. TTL değerini geçiş öncesinde düşürmek bu süreci önemli ölçüde kısaltır.
RFC 2181 ve RFC 5321'e göre MX kaydının hedefi olarak bir CNAME kullanılmamalıdır. CNAME hedefine sahip MX kayıtları teknik olarak işleyebilse de bu yaklaşım standart dışıdır ve beklenmedik davranışlara neden olabilir. Doğru yapılandırma, MX kaydının doğrudan bir A veya AAAA kaydına sahip hostname'e işaret etmesidir.
Toplu gönderim için MX kaydının kendisi değil, SPF, DKIM ve DMARC kayıtlarının eksiksiz yapılandırılması önceliklidir. Ancak gönderim altyapısı olarak Connect365 gibi özel bir servis kullanıyorsanız servis sağlayıcınızın talep ettiği CNAME veya TXT kayıtlarını DNS'e eklemeniz ve bazı durumlarda gönderim alt alan adı için ayrı MX kayıtları tanımlamanız gerekebilir.
Reklamsız, KVKK uyumlu; kurulum ve geçiş ücretsiz, mailleri biz taşırız.