Alan Adı Taşırken E‑Posta Kesintisini Önlemek

Alan Adı Taşıma Sürecinde E‑Posta Neden En Kırılgan Nokta?

Alan adınızı başka bir kayıt firmasına taşıyor, DNS sağlayıcınızı değiştiriyor veya web hosting’inizi yeniliyorsanız; teknik olarak en hassas katman çoğu zaman e‑posta oluyor. Web sitesi birkaç dakikalık kesintiyi çoğu zaman tolere edebilir; ziyaretçi sayısı biraz düşer, sayfa bir süre ulaşılmaz olur ve sorun çözülünce hayat normale döner. Ancak e‑posta tarafında kaybolan bir iş teklifi, kaçan bir destek bileti veya ulaşmayan bir fatura, finansal ve itibar açısından geri döndürülemez sonuçlar doğurabilir.

DCHost tarafında alan adı ve hosting taşıma operasyonlarında en çok gördüğümüz hatalar hep aynı yerde toplanıyor: MX kayıtları aceleyle güncelleniyor, SPF/DKIM taşınmıyor veya yanlış kopyalanıyor, TTL değerleri yüksek bırakılıyor ve sonuçta birkaç saatlik “e‑posta boşluğu” oluşuyor. Bu boşlukta gelen mailler kimi zaman eski sunucuya gidiyor, kimi zaman yeni sunucuda henüz açılmamış kutulara teslim edilmeye çalışılıyor, kimi zaman da tamamen kayboluyor.

Bu yazıda, alan adınızı taşırken MX, SPF, DKIM ve TTL ayarlarını doğru yöneterek sıfıra yakın e‑posta kesintisi ile nasıl geçiş yapabileceğinizi adım adım anlatacağız. Gerçek senaryolardan süzdüğümüz pratikleri, kontrol listelerini ve zamanlama ipuçlarını paylaşacağız; böylece bir sonraki taşıma operasyonunda “mail kesildi mi?” sorusu yerine “iyi ki önceden plan yapmışız” cümlesini duyarsınız.

Temel Kavramlar: MX, SPF, DKIM ve TTL Ne İşe Yarar?

Önce kısa bir sözlükle başlayalım; çünkü alan adı taşırken hangi kaydın ne yaptığını bilmek, nerede hata yapmamanız gerektiğini netleştirir.

• MX (Mail Exchanger): Bir alan adı için e‑postaları hangi sunucuların kabul edeceğini söyleyen DNS kaydıdır. Örneğin mail.ornek.com adresine işaret eden bir MX kaydı, gelen tüm maillerin o sunucuya yönlenmesini sağlar.
• SPF (Sender Policy Framework): Hangi IP adresleri veya sunucuların alan adınız adına e‑posta göndermeye yetkili olduğunu tanımlayan bir TXT kaydıdır. Alıcı taraf, gelen mailin IP’si bu kayda uymuyorsa “spoofing olabilir” diye şüphelenir.
• DKIM (DomainKeys Identified Mail): Gönderilen maile kriptografik bir imza ekler. İmzanın doğrulanabilmesi için DNS’te public key (açık anahtar) kayıtları tutulur. Bu da genellikle selector._domainkey.ornek.com biçiminde bir TXT kaydıdır.
• TTL (Time To Live): DNS kayıtlarının önbellek (cache) süresini belirler. Örneğin bir MX kaydının TTL’i 86400 saniye (24 saat) ise; bir kez sorgulayan istemci bu kaydı 24 saat boyunca güncellemeden kullanır.

DNS kayıt tipleri, ad sunucuları ve yayılım davranışları hakkında temel bilginizi tazelemek isterseniz, önce DNS kayıtları A’dan Z’ye ve sık yapılan hatalar yazımıza göz atmanız faydalı olacaktır.

Hangi Taşıma Senaryosunda Ne Değişiyor?

Alan adı taşırken her zaman aynı bileşenleri oynatmıyorsunuz. Önce hangi senaryoda olduğunuzu netleştirin; sonraki tüm adımlar buna göre şekillenecek.

Senaryo 1: Sadece Alan Adı Registrar’ı Değişiyor (DNS Aynı)

Burada sadece alan adınızı tuttuğunuz firma değişiyor; nameserver (NS) kayıtlarınız aynı kalıyorsa teknik olarak MX, SPF, DKIM ve TTL tarafında bir değişiklik olmaz. Yine de pratik olarak şu kontrolleri öneriyoruz:

• Transfer sonrasında NS kayıtlarınızın otomatik olarak değiştirilmediğinden emin olun.
• Registrar panelinde DNSSEC veya özel glue record gibi ek özellikler kullanıyorsanız, yeni tarafa birebir aktarıldığını kontrol edin.
• Alan adı transferi adımlarını takip ederken e‑posta kayıtlarınızda (MX/TXT) hiçbir otomatik “optimizasyon” yapılmadığını doğrulayın.

Bu senaryoda e‑posta kesintisi yaşanma ihtimali en düşük olsa da, yanlışlıkla DNS’in de taşınması veya boş bir zone ile üzerine yazılması hâlâ gerçek bir risk.

Senaryo 2: DNS Sağlayıcısı Değişiyor (Mail Sunucusu Aynı)

Bu, pratikte en çok kafa karıştıran durum. Mail hâlâ aynı sunucuda kalıyor, ama alan adınızın DNS yönetimi farklı bir yere taşınıyor. Dolayısıyla:

• Eski DNS’teki tüm MX, A/AAAA, SPF (TXT), DKIM (TXT) ve olası DMARC (TXT) kayıtlarının yeni DNS’te birebir oluşturulması gerekiyor.
• TTL değerleri doğru stratejiyle düşürülmezse, bazı kullanıcılar günlerce eski MX kaydını kullanmaya devam edebilir.

Burada odak noktamız: DNS zone’unuzu kusursuz klonlamak ve geçişten önce TTL’i ayarlamak.

Senaryo 3: E‑Posta Hizmeti de Başka Sunucuya Taşınıyor

En riskli ama doğru planlandığında en kontrollü ilerleyen senaryo budur. Hem web hosting’iniz hem de e‑postanız DCHost tarafına geçiyor olabilir; ya da sadece e‑postayı farklı bir sunucuya alıyor olabilirsiniz. Bu durumda:

• Hem MX kayıtlarınız hem de bu MX’lerin işaret ettiği A/AAAA kayıtları değişecektir.
• Yeni sunucunun IP’si SPF kaydına mutlaka eklenmeli, eski IP ise bir süre daha listede kalmalıdır.
• Yeni e‑posta sunucusunda oluşturulan DKIM selector’ları DNS’e eklenmeli; mümkünse eski selector en az birkaç gün daha açık tutulmalıdır.

Bu senaryoda birazdan anlatacağımız zaman çizelgesi ve çift taraflı SPF/DKIM stratejisi kritik önem kazanıyor.

TTL Stratejisi: MX ve TXT Kayıtları İçin Yayılımı Kontrol Etmek

E‑posta kesintisini önlemenin omurgası TTL stratejisidir. MX, A/AAAA ve TXT (SPF, DKIM, DMARC) kayıtlarınızın TTL değeri ne kadar yüksekse, değişikliklerin tüm dünyaya yayılması o kadar geç olur.

Hangi Kayıtlarda TTL Önemli?

• MX kayıtları: Maillerin hangi sunucuya gideceğini belirler.
• A/AAAA kayıtları: MX’in işaret ettiği mail sunucusunun IP adresini gösterir.
• TXT (SPF/DKIM/DMARC): Gönderici doğrulama ve itibar için kullanılır.

Taşıma öncesi bu kayıtların TTL’lerini planlı şekilde düşürmek, geçiş anında geri dönüşü kolay ve hızlı bir yapı sağlar. TTL planlamasını daha derinlemesine anlamak isterseniz, zero-downtime taşıma için TTL stratejileri rehberimizi mutlaka okuyun.

Önerilen TTL Zamanlaması

1. Taşıma tarihinden 48–72 saat önce: Mevcut DNS üzerinde ilgili MX, A/AAAA ve TXT kayıtlarının TTL’ini düşürün.
   Tipik olarak:
   • MX: 300–600 saniye
   • Mail sunucusuna işaret eden A/AAAA: 300–600 saniye
   • SPF/DKIM/DMARC TXT: 300–600 saniye
2. Geçişten hemen sonra: Her şeyin stabil çalıştığından emin olduktan sonra TTL’leri tekrar 3600–14400 saniye bandına yükseltebilirsiniz.

Bu yaklaşım, olası bir hata durumunda “geri sarma” (rollback) yapmanızı kolaylaştırır. Yanlış MX’e geçtiğinizi fark ederseniz TTL düşük olduğu için birkaç dakika içinde tüm dünya doğru kayda döner.

MX Kayıtlarını Güvenle Taşımak: Adım Adım Uygulama

Şimdi en kritik parçaya gelelim: MX tarafını nasıl planlıyoruz? Aşağıdaki adımlar özellikle DNS sağlayıcısı değişirken, mail sunucusu aynı kalıyorsa birebir uygulanabilir; e‑posta sunucusunun da değiştiği senaryoda ise bazı adımları uyarlayacağız.

1. Adım: Mevcut DNS Zone’unuzun Tam Envanterini Alın

İlk iş, mevcut DNS zone’unuzdaki ilgili kayıtları eksiksiz çıkarmak:

• Tüm MX kayıtları (priority, hostname)
• MX’in işaret ettiği A/AAAA kayıtları
• Alan adınıza bağlı tüm TXT kayıtları (SPF, DKIM selector’ları, DMARC vb.)

Bunu manuel olarak panelden not edebilir veya zone dosyasını export edebilirsiniz. DCHost DNS altyapısına geçiyorsanız, bu export dosyasını teknik ekibimizle paylaşarak otomatik import sürecini hızlandırabilirsiniz.

2. Adım: Yeni DNS’te Zone’u Önden Hazırlayın

Henüz NS kayıtlarını değiştirmeden, yeni DNS sağlayıcınızda (örneğin DCHost DNS) alan adınız için bir zone oluşturun ve az önce çıkardığınız MX, A/AAAA ve TXT kayıtlarını birebir ekleyin. Bu aşamada:

• TTL değerlerini planınıza göre (300–600 sn) düşük girin.
• Gereksiz veya tarih geçmiş kayıtları taşımadan önce mutlaka iki kez düşünün; ama emin değilseniz silmek yerine aynen taşımak daha güvenlidir.

3. Adım: Yeni Zone’u Dışarıdan Test Edin

NS geçişi yapmadan önce yeni zone’un doğru olduğundan emin olmak için “dig” veya benzeri araçlarla doğrudan yeni nameserver’ları sorgulayın. Örneğin:

dig @yeni-ns1.ornek.net alanadiniz.com MX

Bu sorgu, global DNS’ten bağımsız olarak sadece yeni NS üzerinde hangi MX’in tanımlı olduğunu gösterecektir. Aynı testi SPF ve DKIM TXT kayıtları için de yapın.

4. Adım: NS Geçişini Planlı Bir Zaman Diliminde Yapın

Yoğun e‑posta trafiği aldığınız saatleri göz önünde bulundurun. Genellikle:

• Hafta içi mesai saatlerinin dışı
• Önemli kampanya/duyuru gönderimlerinin olmadığı bir gün

daha güvenlidir. NS değişikliğini yaptıktan sonra, düşük TTL sayesinde birkaç saat içerisinde tüm sorgular yeni DNS’e yönlenecektir.

5. Adım: Kısa Süreli Çift Takip (Monitoring)

Geçişten sonraki 24 saat boyunca:

• Hem eski hem yeni mail sunucusunun loglarını (varsa) takip edin.
• Farklı ağlardan test adreslerine mail atarak mail header’larından hangi MX’e gittiğini ve hangi SPF/DKIM kayıtlarının kullanıldığını kontrol edin.

Bu aşamada, bir süreliğine [email protected] gibi ek bir adres oluşturup farklı sağlayıcılardan test maili göndermek, tüm zincirin çalıştığını görsel olarak doğrulamanızı kolaylaştırır.

SPF Kaydını Taşırken Gönderilebilirliği Bozmamak

SPF hataları, taşıma sonrasında “mailler spam’e düşüyor” şikâyetlerinin ana sebebi. Çünkü SPF, sizin adınıza mail göndermeye yetkili IP veya sunucuların listesini tutuyor. DNS veya e‑posta altyapısını değiştirirken bu listeyi güncellemezseniz, alıcı tarafında SPF fail sonuçları almaya başlarsınız.

Mevcut SPF Kaydınızı Doğru Okuyun

Tipik bir SPF kaydı şöyle görünebilir:

v=spf1 ip4:1.2.3.4 include:_spf.ornek.net -all

Burada:

• ip4:1.2.3.4 → Alan adınız adına mail göndermeye yetkili bir sabit IP
• include:_spf.ornek.net → Başka bir SPF kaydının kurallarının da geçerli olacağını söyler
• -all → Listede olmayan her göndereni reddet anlamına gelir

Yeni Sunucuyu SPF’e Önden Ekleyin

E‑posta sunucusunu DCHost üzerinde yeni bir IP’ye taşıyorsanız, plan şu olmalı:

1. Yeni mail sunucusu için kullanacağınız IP veya SMTP host’unu netleştirin.
2. Mevcut SPF kaydınıza bu IP’yi/host’u da ekleyin. Örneğin:
   v=spf1 ip4:1.2.3.4 ip4:5.6.7.8 include:_spf.ornek.net -all
3. Bu değişikliği, MX değişiminden önce yapın ki yeni sunucudan çıkacak mailler de SPF tarafından yetkili kabul edilsin.

Bir süre hem eski hem yeni IP’yi SPF’te birlikte tutmakta sakınca yoktur. Geçiş tamamlandıktan ve eski sunucudan mail çıkmadığından emin olduktan sonra eski IP’yi kayıttan kaldırabilirsiniz.

“-all” Yerine Kısa Süreli “~all” Kullanmaya Değer mi?

Taşıma sırasında çok agresif bir SPF politikası (örneğin -all) bazen istemeden geçici sorunlara yol açabilir. Kimi ekipler, geçiş sırasında kısa süreliğine -all yerine ~all (soft fail) kullanıp, her şeyin oturmasından sonra tekrar -all’a dönmeyi tercih ediyor.

Bu yaklaşım, özellikle karmaşık include: zincirleri kullanıyorsanız mantıklı olabilir. SPF’in temel ve gelişmiş kurulum detaylarını, ayrıca 10 lookup sınırına takılmamak için flattening tekniklerini öğrenmek isterseniz, SPF, DKIM, DMARC ve rDNS ile e‑posta teslim edilebilirliğini artırma rehberimize ve SPF flattening ile 10 lookup sınırını aşma yazımıza göz atabilirsiniz.

DKIM Selector ve Anahtarlarını Taşırken Yapmanız Gerekenler

DKIM tarafında yanlış yapılan taşıma genellikle şu sonuçları doğurur: Gönderdiğiniz maillerin header’larında dkim=fail görünür ve DMARC kullanıyorsanız spam kutusuna düşme oranınız artar. Bunu önlemek için hem eski hem yeni DKIM anahtarlarını bir süre paralel çalıştırmak en güvenli yoldur.

1. Mevcut DKIM Selector’larını Tespit Edin

Örneğin cPanel kullanıyorsanız selector genellikle default olur ve DNS’te şu isimle bir TXT kaydı görürsünüz:

default._domainkey.alanadiniz.com

Taşıma öncesi tüm aktif selector isimlerini ve karşılık gelen TXT kayıtlarını not alın. Bazı sistemler çoklu selector kullanabilir (örneğin k1._domainkey, k2._domainkey gibi).

2. Yeni Sunucuda DKIM’i Etkinleştirip Public Key’i DNS’e Ekleyin

Yeni e‑posta sunucusunu DCHost üzerinde kurduysanız, kontrol paneli üzerinden ilgili domain için DKIM’i etkinleştirdiğinizde sistem size yeni bir selector adı ve TXT kaydı verecektir. Bu kaydı:

• Yeni DNS zone’unuza ekleyin.
• Mümkünse selector adını eskiyle aynı tutarak geçişi sadeleştirin; bu mümkün değilse, bir süre her iki selector’ı da (eski ve yeni) DNS’te tutabilirsiniz.

3. Eski Selector’ı Hemen Silmeyin

Özellikle karmaşık yapılarda, bazı arka plan servisleri veya otomatik gönderim sistemleri bir süre eski sunucuyu kullanmaya devam edebilir. Bu yüzden:

• Eski sunucu tamamen devreden çıkana kadar, ona ait DKIM selector TXT kayıtlarını DNS’te bırakın.
• Geçişten sonra belirli bir süre (örneğin 3–7 gün) mail header’larını kontrol ederek hangi selector’ların fiilen kullanıldığını teyit edin.

Başarılı bir taşıma sonrasında DKIM header’ında dkim=pass görmeniz gerekir.

DMARC, rDNS ve Diğer İnce Ayarlar (Bonus Katman)

Makalenin odağı MX, SPF, DKIM ve TTL olsa da, e‑posta taşıma sürecinde DMARC ve rDNS (ters DNS) ayarını da gözden geçirmek iyi bir pratiktir:

• DMARC: Eğer zaten DMARC kullanıyorsanız, yeni SPF ve DKIM düzeninizle uyumlu olup olmadığını test edin. Çok katı (p=reject) bir politika kullanıyorsanız, taşıma süresince kısa süreli p=quarantine ile ilerlemeyi düşünebilirsiniz.
• rDNS (PTR): Yeni IP’lere geçtiğinizde ters DNS kayıtlarınızın mail gönderdiğiniz hostname ile uyumlu olduğundan emin olun.

Bu katmana daha derinlemesine girmek isterseniz, DMARC ve itibar yönetimi için gelişmiş DMARC ve BIMI rehberimizi inceleyebilirsiniz.

Örnek Zaman Çizelgesi: 24 Saatlik E‑Posta Taşıma Planı

Aşağıdaki plan, DNS sağlayıcısını ve e‑posta sunucusunu birlikte taşıdığınız tipik bir senaryoya göre hazırlanmıştır. Süreler örnektir; kendi trafiğinize göre esnetebilirsiniz.

Taşıma Öncesi 48–72 Saat

• Mevcut DNS’te MX, A/AAAA ve TXT (SPF, DKIM, DMARC) kayıtlarının TTL’ini 300–600 saniyeye düşürün.
• Mevcut SPF kaydınıza yeni mail sunucusu IP’sini ekleyin.
• Yeni e‑posta sunucusunda domain’i tanımlayın; test kullanıcıları oluşturun.

Taşıma Öncesi 24 Saat

• Yeni DNS zone’unuzu tamamen hazırlayın; tüm MX, A/AAAA, SPF, DKIM, DMARC kayıtları birebir girilmiş olsun.
• dig veya benzeri araçlarla yeni NS üzerinden kayıtlarınızı test edin.
• Test adreslerine ([email protected]) yeni sunucudan mail gönderip header’ları inceleyin; SPF/DKIM’in pass verdiğini doğrulayın.

T0 – Geçiş Anı

• Alan adınızın NS kayıtlarını yeni DNS sağlayıcısına (örneğin DCHost DNS) yönlendirin.
• MX kayıtlarınızda yeni mail sunucusunu işaret edecek değişiklikleri uygulayın (eğer mail sunucusu da değişiyorsa).

T0 + 1–6 Saat

• Farklı ağlardan test mailleri göndererek gelen kutularına ulaşıp ulaşmadığını, gecikme süresini ve spam’e düşüp düşmediğini kontrol edin.
• Gelen ve giden mail loglarını izleyin; bounceları ve hata mesajlarını not alın.
• Gerekirse SPF/DKIM kayıtlarında küçük düzeltmeler yapın.

T0 + 24 Saat

• Artık trafiğin büyük çoğunluğu yeni MX’e yönlenmiş olacaktır.
• Eski e‑posta sunucusunun hâlâ mail alıp almadığını kontrol edin. Alıyorsa, TTL yayılımı tamamen bitene kadar bir süre daha açık bırakın.
• Her şey stabil ise TTL değerlerini 3600–14400 saniye bandına geri yükseltin.

DCHost ile Alan Adı ve E‑Posta Taşımada İş Akışımız

DCHost’ta, hem web sitesi hem de e‑posta altyapısını bize taşıyan kullanıcılar için bu süreci olabildiğince operasyonel bir check‑list hâline getirmiş durumdayız. Tipik bir taşıma operasyonunda:

• Önce mevcut DNS ve e‑posta mimarinizi analiz ediyor, MX, SPF, DKIM, DMARC ve rDNS durumunu netleştiriyoruz.
• Ardından, sizin için özel bir TTL düşürme ve geçiş takvimi planlıyoruz.
• Yeni sunucularınız (paylaşımlı hosting, VPS veya dedicated) üzerinde e‑posta hesaplarını, DKIM anahtarlarını ve gerekli DNS kayıtlarını önceden hazırlıyoruz.
• NS ve MX geçişini, sizin belirlediğiniz düşük riskli zaman diliminde birlikte gerçekleştirip, sonrasında log ve teslim edilebilirlik kontrollerini yapıyoruz.

Kontrol paneli değişimlerinin de işin bir parçası olduğu durumlarda, örneğin Plesk’ten cPanel’e veya tersi geçişlerde DNS ve e‑postasız kesintisiz geçiş rehberimizde anlattığımız yaklaşımları uyguluyoruz. Eğer sadece cPanel’den cPanel’e taşıma yapıyorsanız, canlı cPanel taşıma ve TTL oyun planı yazımızdaki stratejiler de birebir e‑posta tarafına uygulanabilir.

Sonuç: E‑Posta Kesintisiz Alan Adı Taşıma İçin Yol Haritan

Alan adınızı, DNS’inizi veya e‑posta sunucunuzu değiştirirken “birkaç saate bir şey olmaz” yaklaşımı, maalesef e‑posta tarafında pek işlemiyor. MX’in yanlış yere bakması, SPF’e yeni IP’nin eklenmemesi, DKIM selector’ının unutulması veya TTL’in yüksek bırakılması; tüm bu küçük gözüken hatalar bir araya gelince kritik maillerin kaybolmasına yol açabiliyor.

Bu yazıda özetle şunu gördük: doğru planlanmış bir TTL stratejisi, MX kayıtlarının yeni DNS’te önceden hazırlanması, SPF’in eski ve yeni IP’leri birlikte kapsaması ve DKIM selector’larının paralel çalıştırılması ile e‑posta kesintisini neredeyse sıfıra indirebilirsiniz. Üzerine DMARC ve rDNS’i de doğru kurguladığınızda, sadece kesintisiz değil, aynı zamanda daha güçlü bir teslim edilebilirlik elde etmiş olursunuz.

Alan adınızı veya e‑posta altyapınızı DCHost’a taşımayı düşünüyorsanız, bu rehberi bir kontrol listesi gibi kullanabilir; teknik ekibimizden taşıma öncesi mimari değerlendirme desteği isteyebilirsiniz. İster paylaşımlı hosting, ister VPS, dedicated veya colocation kullanın; DNS, MX, SPF, DKIM ve TTL planlamasını birlikte kurguladığımızda, siz işinize odaklanırken e‑posta trafiğiniz arka planda sessizce, ama kesintisiz biçimde akmaya devam eder.