MX kayıtlarını yönetirken en çok kafa karıştıran şey, yanlarındaki o küçük sayıdır. 10 mail.firmaniz.com yazarken 10 neyi ifade ediyor, 20 daha mı iyi yoksa daha mı kötü, iki sunucuya aynı sayıyı verirsem ne olur? MX önceliği mantığı aslında tek bir cümleyle özetlenebilir — küçük sayı daha yüksek önceliktir — ama bu cümlenin pratikteki sonuçları, özellikle yedek MX kurarken, çoğu kişinin beklediğinden farklı davranır.
Bu rehberde önce öncelik değerlerinin gönderen sunucular tarafından nasıl yorumlandığını anlatacağım, sonra en yaygın yanlış anlamayı düzelteceğim: yedek MX sunucusu, sandığın kadar çok işe yaramaz ve yanlış kurulduğunda altyapına spam kapısı açar. Ardından yedek MX'i doğru kurmak isteyenler için gerçekten güvenli bir yapılandırma vereceğim ve modern alternatifleri karşılaştıracağım. Sonunda da kayıtları nasıl test edeceğini göstereceğim, çünkü MX yapılandırmasının en tehlikeli yanı sessizce yanlış olabilmesidir; postalar gelmediğinde kimse sana haber vermez.
MX Kaydı ve Öncelik Değeri Nasıl Okunur#
Bir MX kaydı iki bilgi taşır: bir öncelik sayısı ve bir sunucu adı. DNS bölge dosyasında şöyle görünür:
; firmaniz.com bölge dosyası
firmaniz.com. 3600 IN MX 10 mail.firmaniz.com.
firmaniz.com. 3600 IN MX 20 mail2.firmaniz.com.
firmaniz.com. 3600 IN MX 30 yedek.saglayici.com.
; MX'in gösterdiği isimlerin A kaydı OLMAK ZORUNDA
mail.firmaniz.com. 3600 IN A 185.12.34.56
mail2.firmaniz.com. 3600 IN A 185.12.34.57
Gönderen bir mail sunucusu [email protected] adresine posta teslim edeceğinde şunu yapar: alan adının MX kayıtlarını sorgular, gelen listeyi öncelik değerine göre küçükten büyüğe sıralar ve en küçük değerli sunucudan başlayarak bağlanmayı dener. Bağlantı kurulamazsa ya da sunucu geçici hata dönerse bir sonrakine geçer. Yani buradaki 10, "önce beni dene" demektir; 30 ise "diğerleri cevap vermezse beni dene".
Sayıların mutlak değeri hiçbir anlam taşımaz, yalnızca birbirlerine göre sıralamaları önemlidir. 10, 20, 30 ile 1, 2, 3 ya da 5, 50, 500 tamamen aynı davranışı üretir. Yaygın gelenek onar onar artırmaktır ve bunun pratik bir sebebi vardır: araya sonradan bir sunucu eklemek istediğinde 15 diyebilirsin, hiçbir kaydı yeniden numaralamak zorunda kalmazsın.
| Öncelik yapısı | Davranış | Ne zaman kullanılır |
|---|---|---|
Tek MX (10) | Tüm posta tek sunucuya | Basit kurulum, çoğu durum |
Farklı değerler (10, 20) | İkincisi yalnızca birincisi cevap vermezse | Aktif/yedek kurgusu |
Aynı değer (10, 10) | Trafik iki sunucuya dağıtılır | Yük paylaşımı, aktif/aktif |
Karışık (10, 10, 20) | İlk ikisi paylaşır, üçüncüsü yedek | Büyük kurulumlar |
Aynı önceliğe sahip birden fazla kayıt yazdığında, gönderen sunucular aralarında rastgele seçim yapar. Bu, DNS düzeyinde basit bir yük dağıtımıdır ve iki posta sunucusunun aynı posta kutusu deposuna eriştiği kurulumlarda işe yarar. İki sunucunun ayrı depolar kullandığı bir kurguda aynı önceliği vermek ise felakettir: postalarının yarısı bir sunucuda, yarısı diğerinde birikir.
Yedek MX Aslında Ne Yapar, Ne Yapmaz#
Burası en çok yanlış anlaşılan konu. "Yedek MX kurayım ki ana sunucum çökerse postalarım kaybolmasın" cümlesi kulağa mantıklı gelir ama içindeki varsayım hatalıdır. Çünkü yedek MX olmasa bile postaların kaybolmaz.
Gönderen sunucu, alıcı sunucuya bağlanamazsa mesajı çöpe atmaz; kendi kuyruğunda tutar ve genellikle birkaç gün boyunca artan aralıklarla yeniden dener. Yani ana sunucun altı saat kapalı kalsa bile, altıncı saatin sonunda ayağa kalktığında bekleyen postalar teslim edilmeye başlar. Bu davranış SMTP'nin temel tasarımıdır ve senin hiçbir şey yapmana gerek yoktur.
O halde yedek MX ne sağlar? Tek bir şey: postanın daha erken kabul edilmesini. Gönderen taraf mesajı senin yedek sunucuna teslim eder, onun kuyruğunda bekler ve ana sunucu döndüğünde oradan aktarılır. Bunun pratikteki faydası dardır ama sıfır değildir:
- Bazı gönderen sistemler kuyruk tutmaz ve ilk denemede teslim edemezse hata verir; yedek MX bunları kurtarır.
- Karşı taraf, mesajın kabul edildiğini gördüğü için "gönderilemedi" uyarısı almaz.
- Uzun kesintilerde (günlerce sürecek bir taşıma gibi) gönderen kuyruk ömürlerinin dolmasını engeller.
Buna karşılık yedek MX'in ciddi bir bedeli vardır: spam gönderenler kasıtlı olarak en düşük öncelikli MX'i hedefler. Mantıkları basittir — yedek sunucular genellikle daha zayıf filtrelenir, alıcı listesini bilmez ve varsayılan olarak her adrese posta kabul eder. Bu da yedek MX'i hem spam kapısı hem de "backscatter" kaynağı yapar.
Yanlış Kurulmuş Yedek MX Neden Tehlikelidir#
Backscatter'ı biraz açayım, çünkü bu, yanlış yedek MX kurulumunun en somut zararıdır. Yedek sunucun firmaniz.com için gelen postaları kabul ediyor ama hangi adreslerin gerçekten var olduğunu bilmiyorsa, [email protected] gibi bir alıcı için gelen mesajı da kabul eder. Sonra bunu ana sunucuya aktarmaya çalışır, ana sunucu "böyle bir kutu yok" diyerek reddeder ve yedek sunucun bir bounce mesajı üretir.
Sorun şu ki spam mesajlarındaki gönderici adresi sahtedir; genellikle masum bir üçüncü kişinin adresi yazılmıştır. Yani senin sunucun, hiç tanımadığı birine "mesajınız teslim edilemedi" diye spam gönderir. Bunu yeterince yaparsan IP'n kara listelere düşer ve asıl ana sunucunun teslimatı da bozulur. Yedek MX kurmak, doğru yapılmadığında altyapını iyileştirmez, bozar.
İkinci risk, filtre asimetrisidir. Ana sunucunda titizlikle kurduğun spam kuralları, DNSBL kontrolleri ve içerik taraması yedek sunucuda yoksa, spam gönderen basitçe yedek MX'e bağlanarak tüm filtrelerini atlar. Kayıtlarını 10 ve 20 diye yazmak bir öncelik bildirir ama kimseyi zorlamaz; bir gönderen istediği MX'e bağlanmakta serbesttir.
Bu iki risk yüzünden benim genel tavsiyem şu: küçük ve orta ölçekli kurulumlarda yedek MX kurma. Tek bir MX kaydı yaz, sunucunun ayakta kalmasına yatırım yap. Yedek MX'i yalnızca gerçekten uzun kesintiler bekliyorsan ve aşağıdaki iki şartı karşılayabiliyorsan kur.
Yedek MX'i Doğru Kurmak#
Yedek MX kuracaksan iki şart pazarlık konusu değildir. Birincisi, yedek sunucu geçerli alıcı listesini bilmeli ve olmayan adreslere gelen postayı bağlantı sırasında (SMTP oturumu daha kapanmadan) reddetmelidir. İkincisi, yedek sunucuda ana sunucudakiyle aynı spam filtreleri çalışmalıdır. Postfix'te bu yapılandırma şöyle kurulur:
# /etc/postfix/main.cf - YEDEK MX sunucusunda
# Bu alan adı için relay yap, ama yerel teslim etme
relay_domains = firmaniz.com
mydestination =
# Postayı ana sunucuya ilet (köşeli parantez MX aramasını atlar)
transport_maps = hash:/etc/postfix/transport
# KRİTİK: geçerli alıcıları bil, olmayanı oturum sırasında reddet
relay_recipient_maps = hash:/etc/postfix/relay_recipients
# Bilinmeyen alıcıyı kalıcı olarak reddet (bounce üretme)
unknown_relay_recipient_reject_code = 550
# Filtreleri ana sunucudakiyle aynı tut
smtpd_recipient_restrictions =
permit_mynetworks,
reject_unauth_destination,
reject_rbl_client zen.spamhaus.org,
reject_unknown_reverse_client_hostname
Yardımcı dosyaları oluştur:
# Postayı hangi sunucuya aktaracağını yaz
echo 'firmaniz.com smtp:[mail.firmaniz.com]:25' | sudo tee /etc/postfix/transport
sudo postmap /etc/postfix/transport
# Geçerli alıcı listesi - her satır bir adres
sudo tee /etc/postfix/relay_recipients > /dev/null <<'LIST'
[email protected] OK
[email protected] OK
[email protected] OK
LIST
sudo postmap /etc/postfix/relay_recipients
sudo systemctl reload postfix
relay_recipient_maps bu yapılandırmanın kalbidir. Bu dosya olmadan sunucun her adrese posta kabul eder ve az önce anlattığım backscatter üreticisine dönüşür. Listeyi elle güncellemek zahmetliyse, ana sunucudan periyodik olarak çekip yeniden postmap çalıştıran bir cron kurabilirsin. Adres listesi değiştikçe bu dosyayı güncellemeyi unutursan, yeni açtığın posta kutuları kesinti anında reddedilir.
DNS tarafında yedek sunucunun kaydını ekle ve önceliği ana sunucudan yüksek bir sayı ver:
firmaniz.com. 3600 IN MX 10 mail.firmaniz.com.
firmaniz.com. 3600 IN MX 50 yedek.firmaniz.com.
yedek.firmaniz.com. 3600 IN A 185.12.34.99
Son olarak yedek sunucunun IP'sini SPF kaydına eklemeyi unutma; yoksa oradan aktarılan postalar SPF doğrulamasında takılır. Tüm DNS kayıtlarının doğru biçimleri için mail sunucusu DNS kayıtları yazısına bakabilirsin.
Yedek MX Yerine Değerlendirebileceğin Alternatifler#
Günümüzde yedek MX'in çözdüğü problem, çoğu durumda başka yollarla daha temiz çözülüyor. Seçenekleri karşılaştıralım:
| Yaklaşım | Kesinti koruması | Spam riski | Yönetim yükü |
|---|---|---|---|
| Tek MX, gönderen kuyruğuna güven | Birkaç gün | Yok | Yok |
| Klasik yedek MX | Uzun kesintiler | Yüksek (yanlış kurulursa) | Alıcı listesi bakımı |
| Aynı öncelikli iki sunucu, ortak depo | Anlık devralma | Düşük | Orta-yüksek |
| Yönetilen posta hizmeti | Sağlayıcı garantisi | Yok | Düşük |
Aynı öncelikli iki sunucu kurgusu, iki MTA'nın aynı posta kutusu deposuna (paylaşımlı depolama ya da eşlenmiş veritabanı) eriştiği yapıdır. Bu, gerçek yüksek erişilebilirlik sağlar çünkü hangi sunucuya teslim edilirse edilsin posta aynı kutuya düşer. Kurulumu ve bakımı ciddi anlamda zordur, o yüzden yalnızca gerçekten ihtiyacın varsa girişilmeli.
Yönetilen posta hizmeti ise kesinti sorumluluğunu tamamen sağlayıcıya devretmektir; MX kayıtların sağlayıcıya bakar, yedeklilik onların altyapısında halledilir. Küçük ve orta ölçekli işletmeler için çoğu zaman en makul seçenek budur. Sağlayıcı değiştirirken MX geçişini kesintisiz yapmanın yolları için e-posta sağlayıcısı değiştirme yazısı adım adım bir plan sunar.
MX Kayıtlarını Test Etmek#
Yapılandırmayı bitirdikten sonra mutlaka dışarıdan doğrula. Kendi sunucundan yaptığın testler önbellek yüzünden yanıltıcı olabilir:
# MX listesini öncelik sırasıyla gör
dig +short MX firmaniz.com
# 10 mail.firmaniz.com.
# 50 yedek.firmaniz.com.
# MX'in gösterdiği isimlerin A kaydı var mı (olmazsa teslimat çöker)
dig +short A mail.firmaniz.com
dig +short A yedek.firmaniz.com
# Yedek sunucu olmayan bir adresi reddediyor mu (KRİTİK TEST)
printf 'EHLO test.ornek.com\r\nMAIL FROM:<[email protected]>\r\n' \
'RCPT TO:<[email protected]>\r\nQUIT\r\n' \
| nc -w 10 yedek.firmaniz.com 25
# Beklenen cevap: 550 5.1.1 ... User unknown
Son test yedek MX kurulumunun tek gerçek sınavıdır. Sunucu 250 OK dönüyorsa relay_recipient_maps çalışmıyor demektir ve o sunucu backscatter üretmeye hazır durumdadır; düzeltmeden DNS kaydını yayına alma. Gelen postada sorun yaşıyorsan teşhis adımları için postalarım gelmiyor MX sorunu yazısına da göz atabilirsin.
Sık Yapılan Hatalar#
En sık yapılan hata, MX kaydını doğrudan bir IP adresine yazmaya çalışmaktır. MX kaydı bir isim göstermek zorundadır; firmaniz.com. IN MX 10 185.12.34.56 geçersizdir ve gönderen sunucular bunu çözemez. Önce mail.firmaniz.com için bir A kaydı oluştur, sonra MX'i o isme yönlendir.
İkinci hata, MX'in gösterdiği ismi CNAME olarak tanımlamaktır. Standartlar MX hedefinin CNAME olmamasını söyler ve bazı sunucular bu durumda teslimatı reddeder; hedef mutlaka doğrudan bir A ya da AAAA kaydına sahip olmalıdır. Üçüncü hata, ayrı depolara sahip iki sunucuya aynı önceliği vermektir — postaların ikiye bölünür ve kullanıcılar mesajlarının yarısını göremez.
Dördüncü hata, yedek MX'i relay_recipient_maps olmadan kurmaktır ki yukarıda ayrıntısıyla anlattım. Beşinci hata, yedek sunucuyu SPF kaydına eklemeyi unutmaktır; aktarılan postalar SPF'te başarısız olur ve spam'e düşer. Altıncı ve en sinsi hata, sağlayıcı değiştirirken eski MX kaydını silmeyi unutmaktır: eski sunucu hâlâ ayaktaysa ve daha düşük öncelikliyse, postaların bir kısmı sessizce oraya gitmeye devam eder ve kimse fark etmez.
Sıkça Sorulan Sorular#
MX önceliğinde küçük sayı mı yoksa büyük sayı mı önce denenir#
Küçük sayı önce denenir. Öncelik değeri "tercih sırası"dır, kalite değil; 10 değerli sunucu 20 değerli sunucudan önce denenir. Sayıların mutlak değerinin hiçbir önemi yoktur, yalnızca birbirlerine göre sıraları belirleyicidir. Bu yüzden 1, 2, 3 ile 10, 20, 30 tamamen aynı davranışı üretir.
Yedek MX kurmazsam kesinti sırasında postalarım kaybolur mu#
Hayır. Gönderen mail sunucusu sana ulaşamazsa mesajı kendi kuyruğunda tutar ve genellikle birkaç gün boyunca yeniden dener. Sunucun döndüğünde bekleyen postalar teslim edilir. Yedek MX yalnızca postanın daha erken kabul edilmesini sağlar; kayıp riskini ortadan kaldırma işini zaten SMTP'nin kendi yeniden deneme mekanizması yapıyor.
Aynı önceliğe sahip iki MX kaydı yazarsam ne olur#
Gönderen sunucular ikisi arasında rastgele seçim yapar, yani trafik kabaca eşit dağılır. Bu, iki sunucunun aynı posta kutusu deposuna eriştiği kurulumlarda işe yarayan basit bir yük dağıtımıdır. Ancak sunucuların ayrı depoları varsa postaların ikiye bölünür ve kullanıcılar mesajlarının bir kısmına ulaşamaz; bu durumda mutlaka farklı öncelikler kullan.
MX kaydı değişikliği ne kadar sürede yayılır#
Yayılma süresi kaydın TTL değerine bağlıdır. TTL 3600 ise bir saat içinde çoğu çözümleyici yeni değeri görür; TTL 86400 ise bu bir güne kadar uzayabilir. Planlı bir MX değişikliğinden en az 24 saat önce TTL'i 300 seviyesine indirirsen geçiş dakikalar içinde tamamlanır. Değişiklik sonrası TTL'i tekrar yükseltmeyi unutma.
Yedek MX sunucusu spam almama sebep olur mu#
Yanlış kurulursa evet. Spam gönderenler kasıtlı olarak en düşük öncelikli MX'i hedefler, çünkü yedek sunucular genellikle daha zayıf filtrelenir. Yedek sunucun geçerli alıcı listesini bilmiyorsa olmayan adreslere gelen postayı kabul eder ve sonra sahte göndericilere bounce üreterek kendi IP'ni kara listeye düşürür. relay_recipient_maps ve ana sunucuyla aynı filtreler bu riski ortadan kaldırır.
MX kaydım doğru mu, nasıl kontrol ederim#
dig +short MX firmaniz.com komutu tüm MX kayıtlarını öncelik değerleriyle listeler. Ardından her hedef ismin A kaydı olduğunu dig +short A mail.firmaniz.com ile doğrula; MX bir CNAME'i göstermemeli. Yedek MX kurduysan asıl testi de yap: olmayan bir adrese SMTP oturumu açıp 550 cevabı aldığını gör. 250 OK dönüyorsa yapılandırman eksiktir.
Kapanış#
MX önceliği kavram olarak basit ama uygulamadaki sonuçları çoğu kişinin beklediğinden farklı. Aklında kalması gereken dört şey: küçük sayı önce denenir ve mutlak değerin hiçbir anlamı yoktur; yedek MX olmadan da postaların kaybolmaz, çünkü gönderen taraf zaten kuyruk tutar; yedek MX kuracaksan relay_recipient_maps ve aynı spam filtreleri pazarlık konusu değildir; ve MX hedefi daima bir A kaydına sahip isim olmalı, asla IP ya da CNAME değil. Çoğu kurulumda en doğru cevap, tek bir MX kaydı ve sağlam bir sunucudur.
Posta altyapının yedekliliğiyle uğraşmak istemiyorsan Clou.TR tarafında hazır seçenekler var. Kurumsal posta kutuları için e-posta paketlerimiz MX yönetimini tamamen üstlenir; kendi sunucunu kurmak istersen VDS ve bulut sunucu çözümlerimiz tam kontrol sağlar. DNS ve MX ayarlarını devretmek istersen sunucu yönetimi hizmetimize, alan adı tarafı için de alan adı sayfamıza göz atabilirsin.