E‑Posta Altyapısında Yedeklilik: Birden Fazla MX Kaydı, Backup MX ve Split Delivery Kurulumu

E‑posta altyapınız, şirket içi iletişimden faturalara, destek taleplerinden kritik güvenlik uyarılarına kadar neredeyse her sürecin omurgası. Web sitesinin bir süre yavaşlaması genelde tolere edilebilir; ancak e‑postanın birkaç saat bile tamamen gitmemesi çoğu işletme için operasyonel kriz demek. Bu yüzden mimari tasarım, kapasite planlama ve güvenlik denetimi yaparken, e‑posta tarafındaki yedeklilik stratejisini ayrı bir başlık olarak ele almak şart.

Bu yazıda, sahada sık kullandığımız üç temel mekanizmaya odaklanacağız: birden fazla MX kaydı, backup MX ve split delivery. DNS’te MX önceliklendirmesi nasıl çalışır, neleri yanlış yaparsanız mail’leriniz kaybolmasa bile günlerce gecikebilir, backup MX’i neden herkes önermiyor, split delivery ile kademeli geçişi nasıl kurarsınız; hepsini pratik adımlarla anlatacağım. Amacımız; ister paylaşımlı hosting, ister kendi VPS/dedicated altyapınızı kullanın, DCHost üzerinde çalışan e‑posta mimarinizi kesintilere karşı daha dayanıklı hale getirmek ve bunu yaparken karmaşık kurallara boğulmadan ilerleyebilmenizi sağlamak.

E‑posta Altyapısında Yedeklilik Neden Kritik?

Birçok şirkette e‑posta, fiilen iş akışının kayıt sistemi gibi çalışır. Tek bir MX kaydına, tek bir sunucuya ve tek bir veri merkezine bağlı kaldığınızda:

• Planlı bakım sırasında,
• Beklenmedik disk arızalarında,
• Veri merkezinde ağ veya elektrik sorunu yaşandığında,
• Firewall ya da anti‑spam tarafında yanlış bir kural devreye girdiğinde,

tüm mail trafiğiniz anında durur. Üstelik SMTP protokolü gereği gönderen taraf çoğu zaman mailleri bir süre queue’da tutar; bu yüzden sorun fark edilene kadar kayıp yerine gecikme yaşarsınız. Bazen bu gecikme, müşteriye zamanında gitmesi gereken kritik bir onayın kaçırılması demektir.

DCHost’ta altyapı tasarlarken, tıpkı web trafiğinde yaptığımız gibi e‑posta tarafında da tek hata noktasını ortadan kaldırmayı hedefliyoruz. Yedekli MX kayıtları, backup MX sunucuları ve split delivery mimarileri; yüksek kullanılabilirlik (HA) mimarisi kuracak kadar bütçesi olmayan küçük ekipler için bile oldukça makul maliyetlerle uygulanabiliyor. DNS’in nasıl çalıştığını daha temelden hatırlamak isterseniz, önce DNS kayıtları A’dan Z’ye rehberimizi gözden geçirmenizi öneririm.

MX Kayıtlarının Mantığı: Öncelik, TTL ve Teslimat Akışı

MX kaydı nedir, nasıl çalışır?

MX (Mail Exchanger) kaydı, bir alan adı için e‑posta kabul etmekle sorumlu sunucuları DNS düzeyinde tanımlar. Örneğin:

example.com.   3600   IN   MX   10 mail1.example.com.
example.com.   3600   IN   MX   20 mail2.example.com.

Bu yapı, @example.com adresine gelen tüm maillerin önce mail1 sunucusuna, bu sunucu yanıt vermiyorsa mail2 sunucusuna gönderilmesini söyler. Buradaki öncelik değeri (10, 20 vs.), sayısal olarak ne kadar küçükse o kadar önceliklidir.

MX önceliği ve yedeklilik senaryosu

Bir gönderen sunucu, sizin alan adınıza mail atarken DNS’ten MX kayıtlarınızı çeker; ardından:

1. Önceliği en düşük (ör. 10) MX sunucusuna bağlanmaya çalışır.
2. TCP bağlantısı kurulamazsa veya sunucu 4xx/5xx hataları dönerse, bir sonraki MX kaydına (ör. 20) geçer.
3. Hiçbir MX’e bağlanamazsa, maili kuyrukta bekletir ve belirli aralıklarla tekrar dener.

İşte bu akış, bize “pasif yedeklilik” sağlar. Birincil MX sunucunuz kapalıyken, ikincil MX devreye girer. Bu tasarımın sağlıklı çalışabilmesi için:

• Her MX kaydının işaret ettiği A/AAAA kayıtlarının doğru olması,
• Her MX sunucusunda aynı alan adları ve posta kutularının tanımlı olması (veya doğru relay kurallarının yapılması),
• MX kayıtlarında çok düşük TTL kullanarak sürekli DNS güncellemesine güvenmemek,

gerekir. TTL stratejileriyle ilgili daha derin bir bakış için zero‑downtime taşıma için TTL stratejileri rehberimizi inceleyebilirsiniz.

Birden fazla MX kaydı “yük dengeleme” yapar mı?

Çok yaygın bir yanlış anlama var: “İki MX kaydı ekleyeyim, biri 10, diğeri 20 olsun; böylece yük dengelenir.” Hayır; SMTP tarafında öncelik tabanlı bir fallback vardır, gerçek anlamda ağırlıklı yük dengeleme yoktur. Bazı gönderici sunucu implementasyonları, eşit öncelikli MX kayıtları arasında rastgele seçim yapabilir; ama bu davranışa güvenerek load balancing stratejisi kurmak sağlıklı değildir.

Eğer gerçekten yük dağıtmak istiyorsanız, genelde tek bir MX kaydı arkasında çalışan yedekli MTA kümesi (örneğin birden fazla VPS veya dedicated sunucunun ortak IP/Anycast/Load Balancer arkasına alınması) tasarlamak daha doğru bir yaklaşımdır. Bu da DCHost’ta VPS ya da dedicated sunucu çözümleri ile kurulan ayrı bir mimari konusudur.

Birden Fazla MX Kaydı ile Yedekli Kurulum Adımları

1. Mimariyi planlayın: Aynı veri merkezi mi, farklı bölgeler mi?

İlk soru şu: Yedekliliği hangi seviyede istiyorsunuz?

• Aynı veri merkezinde iki farklı sunucu: Donanım arızalarına karşı korur; ancak veri merkezi genelinde yaşanacak elektrik/ağ sorunlarına karşı savunmasızdır.
• Farklı veri merkezlerinde iki sunucu: Hem donanım hem de tesis seviyesinde yedeklilik sağlar; fakat replikasyon, latency ve maliyet açısından daha karmaşıktır.
• Farklı tip altyapı: Örneğin, birincil sunucu DCHost üzerinde yönetilen bir VPS, ikincil ise başka lokasyonda daha minimal bir relay node olabilir.

Küçük ve orta ölçekli şirketlerin çoğu için, DCHost üzerinde iki farklı fiziksel host’ta çalışan yedekli VPS ile başlamak genelde optimum çözümdür. Daha büyük yapılarda dedicated + colocation kombinasyonlarıyla da çok bölgeli HA mimarileri kurabiliyoruz.

2. DNS tarafında MX kayıtlarını ekleyin

Örnek bir senaryoyu ele alalım. Alan adınız: firma.com. İki mail sunucunuz var:

• mx1.firma.com – Birincil sunucu
• mx2.firma.com – İkincil (yedek) sunucu

DNS kayıtlarınız kabaca şöyle olabilir:

firma.com.     3600   IN   MX   10 mx1.firma.com.
firma.com.     3600   IN   MX   20 mx2.firma.com.

mx1.firma.com. 3600   IN   A    192.0.2.10
mx2.firma.com. 3600   IN   A    192.0.2.20

Burada kritik noktalar:

• mx1 ve mx2 için A/AAAA kayıtları mutlaka tanımlı olmalı.
• Her iki IP için de rDNS (PTR) kayıtları doğru şekilde ayarlı olmalı ve HELO/EHLO host adı ile tutarlı olmalı (örnek: mx1.firma.com).
• SPF, DKIM ve DMARC kayıtlarınızda hangi IP’lerden mail çıkacağını açıkça tanımlamalısınız. Bunun için detaylı bir rehbere ihtiyacınız varsa SPF, DKIM, DMARC ve rDNS ile e‑posta teslim edilebilirliğini artırma rehberimizi mutlaka okuyun.

3. Sunucu tarafında aynı domain ve kullanıcıları tanımlayın

MX yedekliliğinin en çok atlanan kısmı burasıdır. DNS’te iki MX kaydı olması yetmez; her iki MTA’da da aynı alan adları ve posta kutuları tanımlı olmalıdır. Örneğin:

• Her iki sunucuda da firma.com local domain olarak ekli olmalı,
• [email protected], [email protected] gibi kullanıcılar her iki tarafta da oluşturulmalı (veya merkezi bir IMAP/Storage altyapısına bağlı olmalı),
• Mailbox senkronizasyonu (DRBD/ZFS replication, IMAP sync gibi) için bir stratejiniz olmalı.

Eğer sadece kabul tarafını yedeklemek, asıl posta kutularını tek bir IMAP sunucusunda tutmak istiyorsanız; ikincil MX’te local mailbox açmak yerine, mailleri birincil sunucuya relay eden bir yapı da kurabilirsiniz. Bu senaryo backup MX bölümünde daha detaylı ele alınacak.

4. Test senaryoları: MX yedekliliği gerçekten çalışıyor mu?

Yapılandırma bittiğinde mutlaka şu testleri yapın:

• Bir istemciden (örneğin kendi test mail sunucunuzdan) @firma.com adreslerine mail atın, normal durumda maillerin mx1 üzerinden alındığını log’lardan doğrulayın.
• mx1 sunucusunun SMTP portunu (25) firewall ile geçici olarak kapatın veya servisi durdurun.
• Tekrar mail gönderip, bu kez gönderen sunucunun log’larında mx2’ye bağlandığını görün.
• İstemci tarafında gecikmenin makul seviyede (genelde saniyeler mertebesinde) olduğundan emin olun.

Bu testleri mümkünse periyodik olarak tekrarlayıp, dokümante edin. DCHost’ta e‑posta taşıma süreçlerinde benzer failover provalarını standart bir adım olarak uygulatıyoruz. Taşıma aşamalarının detaylı bir örneğini e‑posta altyapısını taşırken kesinti yaşamamak rehberinde bulabilirsiniz.

Backup MX Sunucusu: Avantajlar, Riskler ve Doğru Kurulum

Backup MX nedir, ne işe yarar?

Backup MX, alan adınız için ikinci (veya üçüncü) sırada tanımlı, görevi normalde mail teslim etmek değil, sadece:

• Birincil MX erişilemezken mailleri geçici olarak kuyruğa almak,
• Birincil MX tekrar ayağa kalktığında bu mailleri ona iletmek,

olan bir SMTP sunucusudur. Yani “park yeri” gibi düşünebilirsiniz. Gönderen sunucu sizin birincil MX’inize ulaşamayınca, backup MX’e düşer; backup MX mailleri kendi kuyruğunda tutar ve siz döndüğünüzde teslim eder.

Neden herkes backup MX kullanmıyor? Spam riski

Backup MX, yanlış kurulduğunda spam mıknatısı haline gelebilir. Bazı spam göndericiler, doğrudan birincil MX yerine backup MX’e mail atarak:

• Anti‑spam kontrolleri daha zayıf olan bir sunucu bulmaya çalışır,
• Relay kurallarını hatalı yapılandırmış misconfig’li backup MX’leri istismar eder,
• Geçici hatalar (4xx) yerine kalıcı hatalar (5xx) almamak için yedek MX’ten medet umar.

Bu yüzden backup MX kurarken dikkat edilmesi gerekenler:

• Backup MX üzerinde de güçlü anti‑spam kontrolleri (RBL, greylisting, SPF/DMARC doğrulama vb.) çalışmalı.
• Backup MX açık relay olmamalı; sadece belirli domain’ler ve belirli hedef sunucular için relay izni verilmeli.
• Mailleri süresiz bekletmemeli; makul bir maksimum kuyruk süresi (ör. 3–5 gün) tanımlanmalı.

Anti‑spam tarafında neler yapabileceğinizi daha pratik görmek için cPanel’de e‑posta spam filtreleme rehberimizi incelemeniz faydalı olacaktır.

Basit bir backup MX senaryosu (yüksek seviye)

Diyelim ki:

• Birincil MTA: mx1.firma.com (Postfix),
• Backup MTA: mx-backup.dchost-mail.net (DCHost üzerinde ayrı bir VPS),

olsun. DNS tarafı:

firma.com.   3600   IN   MX   10 mx1.firma.com.
firma.com.   3600   IN   MX   20 mx-backup.dchost-mail.net.

Backup MX üzerindeki yüksek seviye mantık ise şu şekilde olur:

• relay_domains içine sadece firma.com eklenir.
• Destination olarak mx1.firma.com tanımlanır.
• Birincil MTA erişilemiyorsa, mailler kuyruğa alınır ve düzenli aralıklarla tekrar teslim denenir.

Burada backup MX, asla kullanıcı posta kutusu barındırmaz; sadece akıllı bir kuyruk görevi görür. DCHost ekibi olarak müşterilerimiz için kurduğumuz yedekli e‑posta ortamlarında çoğunlukla bu yaklaşımı kullanıyoruz; bu sayede hem altyapı sade kalıyor hem de senkronizasyon karmaşası azalmış oluyor.

Split Delivery: Hibrit E‑posta Mimarilerinde Trafiği Bölmek

Split delivery nedir?

Split delivery, aynı alan adındaki farklı kullanıcıların maillerini farklı hedef sistemlere yönlendirmek anlamına gelir. Örneğin:

• [email protected] adreslerinin bir kısmı DCHost üzerindeki kendi mail sunucunuzda,
• Diğer kısmı harici bir SaaS e‑posta platformunda,

barınıyor olabilir. Bu durumda gelen mail trafiğini, SMTP tarafında kullanıcıya göre bölmeniz gerekir.

Tipik kullanım senaryoları:

• Mevcut on‑premise veya VPS mail sunucusundan bulut tabanlı bir servise kademeli geçiş,
• Farklı departmanların (örneğin çağrı merkezi vs. yönetim) farklı mail altyapıları kullanması,
• Grup şirketlerinde, bazı markaların merkezi mail sistemi, bazılarının lokal sistemler kullanması.

Split delivery nasıl uygulanır? (Yüksek seviye mantık)

Split delivery genelde üç ana yaklaşımla kurulur:

1. Directory tabanlı yönlendirme: Kullanıcı listesi (LDAP/AD vb.) hangi kullanıcının hangi platformda olduğunu bilir; MTA bu bilgiye göre mailleri içeri veya dışarı relay eder.
2. Adres tabanlı statik yönlendirme: Belirli adres veya domain pattern’leri için farklı hedef sunucu tanımlanır (örneğin Postfix transport_maps ile).
3. Catch‑all + forward: Tüm mailler önce birincil sisteme gelir; burada var olmayan kullanıcılar için harici bir hedefe yönlendirme yapılır.

Küçük ve orta ölçekli yapılarda genelde ikinci yöntem (adres tabanlı statik yönlendirme) daha pratik olur. Örneğin Postfix’te:

transport_maps = hash:/etc/postfix/transport

dosyasına:

[email protected]   smtp:[harici-mail-sunucusu]
@altdepartman.firma.com  smtp:[diger-sunucu]

gibi kurallar eklenerek belirli kullanıcılara gelen mailler farklı hedeflere taşınabilir.

Split delivery’de dikkat edilmesi gerekenler

Split delivery kurarken:

• Hangi kullanıcının hangi platformda olduğunu tek bir yerde (örneğin bir YAML/CSV dosyası veya merkezi directory) takip ettiğinizden emin olun.
• Yanlışlıkla loop (döngü) oluşmaması için her iki uçta da relay kurallarını dikkatle tasarlayın.
• SPF/DKIM/DMARC politikalarınızın, maillerin çıktığı tüm sistemleri kapsadığından emin olun.
• Geçiş sürecinde, eski sistemde kalan maillerin imap/POP üzerinden taşınması için ek bir plan yapın.

Alan adını veya mail altyapısını taşırken kesintiyi en aza indirmek için hazırladığımız alan adı taşırken e‑posta kesintisini önleme rehberi, split delivery senaryoları planlarken de işinize yarayacaktır.

Yedekli E‑posta İçin Altyapı Seçenekleri (DCHost Perspektifi)

Paylaşımlı hosting + harici backup MX

Birçok küçük işletme için klasik senaryo şu:

• Web sitesi ve mail aynı paylaşımlı hosting hesabında,
• MX, hosting sunucusunu gösteriyor,
• Başka hiçbir yedeklilik yok.

Bu durumda bile en azından harici bir backup MX ekleyerek ciddi kazanımlar elde edebilirsiniz. Örneğin:

• Birincil MX: Paylaşımlı hosting IP’si,
• Backup MX: DCHost’ta basit bir VPS üzerinde kurulu Postfix relay node’u.

Böylece hosting tarafında yaşanacak bir kesinti sırasında mailleriniz hala backup MX kuyruklarına kabul edilir; siz döndüğünüzde teslim edilir. Bu senaryoda VPS üzerinde kuracağınız mail sunucusunun detaylarını merak ediyorsanız, VPS’te e‑posta sunucusu kurulumu rehberimizi inceleyebilirsiniz.

Yedekli VPS/dedicated mimarisi

Daha yüksek hacimli e‑posta trafiği olan, kendi MTA’sını ve anti‑spam altyapısını yöneten şirketler için önerdiğimiz tipik kurgu:

• İki ayrı fiziksel host üzerinde çalışan yedekli VPS’ler veya dedicated sunucular,
• Her iki sunucuda da aynı domain ve kullanıcıların tanımlı olması,
• Veri katmanında (mailbox’larda) replikasyon veya düzenli IMAP sync,
• MX kayıtlarında birincil/ikincil önceliklendirme,
• Harici bir izleme sistemiyle SMTP health‑check’leri.

Bu tür yapılarda genelde e‑posta altyapısını da genel felaket kurtarma planınızın bir parçası yapıyoruz. Bu konuya daha geniş açıdan bakmak isterseniz, genel felaket senaryoları ve yedekleme stratejileri için blogumuzdaki diğer yazılara da göz atabilirsiniz.

İzleme, loglama ve felaket provaları

MX yedekliliği ve backup MX/split delivery kurulumunu tamamladıktan sonra iş bitmiyor; en az kurulum kadar önemli üç başlık var:

• İzleme: SMTP portlarının (25, submission için 587) dışarıdan erişilebilirliğini, gecikmeleri ve hata kodlarını düzenli izleyin.
• Loglama: MTA log’larını merkezi bir sistemde toplayıp (örneğin syslog + log analiz aracı), bounces, gecikmeler ve RBL sorunlarını erken yakalayın.
• Prova: Belirli periyotlarla, birincil MX’i kasıtlı olarak devre dışı bırakıp backup MX ve split delivery kurallarınızın gerçekten beklendiği gibi çalıştığını test edin.

DCHost olarak, özellikle yoğun mail trafiği olan müşteriler için bu testleri değişik senaryolarla birlikte (DNS kesintisi, IP değişimi, antrepo doluluğu vb.) planlıyoruz. E‑posta taşıma ve yeni altyapıya geçiş süreçlerinde, kesintisiz geçiş rehberinde anlattığımız DNS cutover teknikleriyle bu testleri birleştirmek oldukça verimli sonuç veriyor.

Örnek Uygulama: Küçük Bir Şirket İçin Adım Adım Yol Haritası

Diyelim ki 30 kişilik bir ekibiniz var, e‑postalarınız şu an tek bir paylaşımlı hosting hesabında ve bir süredir ara ara kısa kesintiler yaşıyorsunuz. Hedefiniz:

• Mail kesintilerini minimuma indirmek,
• Altyapınızı orta vadede kendi VPS veya dedicated sunucunuza taşımak,
• Bu geçişi adım adım, risksiz şekilde yapmak.

İzleyebileceğiniz pratik yol haritası:

1. Alan adı ve DNS envanterini çıkarın: Hangi nameserver’leri kullanıyorsunuz, mevcut MX ve A/AAAA kayıtlarınız neler? Bu aşamada DNS kayıtları rehberine bir göz atmak iyi olur.
2. DCHost’ta küçük bir VPS ayırın: Bu VPS, önce backup MX ve geçiş sürecinde split delivery için gateway görevi görebilir.
3. VPS üzerine MTA kurun: Postfix + Dovecot + rspamd gibi bir kurulumla başlayabilir, yapılandırma için adım adım anlatılan VPS’te e‑posta sunucusu rehberinden yararlanabilirsiniz.
4. Backup MX olarak devreye alın: Alan adınızın MX kayıtlarına VPS’i ikincil MX olarak ekleyin. Böylece en azından kesinti anlarında mailler kuyruklara kabul edilmeye başlar.
5. Kademeli split delivery planlayın: Önce IT ekibi gibi küçük bir kullanıcı grubunu yeni VPS MTA’ya taşıyın. Split delivery veya adres yönlendirme ile sadece bu kişilerin maillerini yeni altyapıya yönlendirin.
6. Gözlem ve optimizasyon: Bir süre izleyin, anti‑spam ayarlarını, SPF/DKIM/DMARC yapılandırmasını optimize edin. Teslim edilebilirlik tarafında sorun kalmadığından emin olun.
7. Tüm kullanıcıları taşıyın ve MX’i değiştirin: Her şey yolundaysa, tüm kullanıcıların mailbox’larını yeni sunucuya taşıyıp MX önceliğini tamamen yeni altyapıya verebilirsiniz.

Bu süreci doğru planlarsanız, neredeyse sıfıra yakın kesintiyle ve kullanıcıların çok az fark edeceği bir deneyimle e‑posta altyapınızı bir üst seviyeye taşımış olursunuz.

Sonuç: E‑posta Yedekliliğini “Lüks” Değil, Temel İhtiyaç Gibi Görmek

E‑posta altyapısında yedeklilik çoğu zaman, kriz yaşanana kadar göz ardı edilen bir başlık. Oysa bir alan adı için birkaç basit MX kaydı eklemek, küçük bir VPS ile backup MX kurgulamak veya split delivery ile kademeli geçiş planlamak; bütçenizi zorlamadan iş sürekliliğinizi ciddi biçimde güçlendiriyor. Özellikle finans, hukuk, sağlık, e‑ticaret gibi sektörlerde, birkaç saatlik mail kesintisinin bile doğrudan para ve itibar kaybı anlamına geldiğini sahada defalarca görüyoruz.

DCHost olarak biz, e‑posta mimarisini sadece “hosting paketinin yanında gelen özellik” olarak değil, başlı başına tasarlanması gereken bir altyapı bileşeni olarak ele alıyoruz. MX yedekliliği, backup MX ve split delivery gibi mekanizmaları doğru kurduğunuzda; SPF, DKIM, DMARC, MTA‑STS gibi ek güvenlik katmanlarıyla birleştirdiğinizde, hem teslim edilebilirliği hem de kesintilere karşı dayanıklılığı aynı anda artırmış olursunuz.

E‑posta altyapınızı DCHost üzerinde yeniden tasarlamak, mevcut yapınızı yedekli hale getirmek veya yeni bir domain için sıfırdan temiz bir kurulum yapmak istiyorsanız; ekibimizle beraber adım adım planlayabiliriz. Önce mevcut DNS ve MX yapınızı gözden geçirip, sonra işinize ve bütçenize uygun bir yol haritası çıkaralım; siz işinize odaklanırken, biz e‑postalarınızın her koşulda sorunsuz akmasını sağlayalım.