Bir alan adının nameserver adreslerini değiştirmek birkaç dakikalık bir işlem olabilir. Ancak bu değişiklikten sonra web sitesinin açılmaması, e-postaların ulaşmaması veya bazı kullanıcıların eski sunucuya yönlendirilmesi, DNS geçişinin dikkatli planlanmadığını gösterebilir.
Özellikle web sitesi ile e-posta hizmeti farklı sağlayıcılarda barındırılıyorsa yalnızca yeni nameserver adreslerini tanımlamak yeterli değildir. Mevcut DNS bölgesindeki kayıtların doğru şekilde aktarılması, yeni DNS hizmetinin önceden hazırlanması ve geçiş sonrasında kayıtların doğrulanması gerekir.
Bu rehberde nameserver değişikliğinin hangi servisleri etkilediği, e-posta kesintisi riskinin nasıl azaltılacağı ve olası sorunların nasıl tespit edileceği adım adım ele alınmaktadır.
Nameserver Nedir ve Değiştirildiğinde Ne Olur?
Nameserver (NS), bir alan adının DNS kayıtlarını sunan yetkili DNS sunucusudur. DNS sistemi, alan adlarıyla ilişkili IP adresleri, e-posta sunucuları ve diğer hizmet bilgilerini bu kayıtlar üzerinden çözümler.
Alan adı kaydı, DNS yönetimi ve hosting hizmeti birbirinden farklı bileşenlerdir. Bu kavramların temel ilişkisi, alan adı ile DNS yönetimi arasındaki farkı açıklayan rehberde de ele alınmaktadır.
Örneğin ornekfirma.com alan adının DNS kayıtlarının bir hosting sağlayıcısında tutulduğunu düşünelim. Alan adı sahibi DNS yönetimini başka bir sağlayıcıya taşıdığında alan adı kayıt kuruluşundaki nameserver adresleri değiştirilir.
Bu işlem, alan adının DNS sorgularını yanıtlamakla yetkili sunucuları değiştirir.
Önemli nokta şudur: Nameserver değiştirmek, web sitesi dosyalarını veya e-posta kutularını otomatik olarak başka bir sunucuya taşımaz.
Yeni DNS bölgesinde doğru kayıtlar bulunuyorsa mevcut web ve e-posta hizmetleri aynı sunucularda çalışmaya devam edebilir.
Ancak kayıtlar eksikse DNS sorguları yanlış hedeflere yönlenebilir veya gerekli yanıtlar hiç alınamayabilir.
Nameserver Değişikliğinde Hangi DNS Kayıtları Kontrol Edilmeli?
DNS bölgesi (DNS zone), belirli bir alan adına ait kayıtların yönetildiği yapılandırma alanıdır.
Nameserver değişikliği öncesinde mevcut bölgedeki kayıtlar envanter haline getirilmelidir.
| DNS kaydı | Görevi | Eksik veya yanlış olursa |
|---|---|---|
| A | Alan adını IPv4 adresine yönlendirir. | Web sitesi yanlış sunucuya gidebilir. |
| AAAA | Alan adını IPv6 adresine yönlendirir. | IPv6 bağlantılarında erişim sorunu oluşabilir. |
| CNAME | Bir alan adını başka bir alan adına yönlendirir. | Alt alan adları çalışmayabilir. |
| MX | Gelen e-postaların hangi posta sunucusuna teslim edileceğini belirtir. | E-posta alımında sorun yaşanabilir. |
| TXT / SPF | E-posta göndermeye yetkili kaynakları tanımlar. | Gönderilen iletilerin doğrulaması etkilenebilir. |
| TXT / DKIM | E-posta imzalarının doğrulanması için gerekli açık anahtarı yayımlar. | DKIM doğrulaması başarısız olabilir. |
| TXT / DMARC | SPF ve DKIM doğrulama sonuçlarına göre uygulanacak politikayı bildirir. | Alan adının e-posta doğrulama politikası değişebilir. |
| CAA | Sertifika düzenleyebilecek yetkili kuruluşları sınırlar. | Yeni TLS sertifikası alınması engellenebilir. |
Bu tablodaki kayıtların tamamı her alan adında bulunmak zorunda değildir. Önemli olan, kullanılan hizmetlerin gerektirdiği kayıtların korunmasıdır.
Örneğin yalnızca web sitesi barındıran bir alan adıyla, Microsoft 365 üzerinde e-posta kullanan ve çok sayıda alt alan adına sahip bir kurumsal alan adının DNS ihtiyaçları aynı değildir.
Nameserver Değiştirmeden Önce Yapılması Gerekenler
Geçişin güvenilirliği, nameserver adreslerinin değiştirildiği andan çok önce başlar.
1. Mevcut DNS kayıtlarının yedeğini alın
İlk olarak alan adının mevcut yetkili DNS sağlayıcısını belirleyin.
Ardından kullanılan DNS yönetim panelinden bütün kayıtları dışa aktarın. Sağlayıcı bölge dosyası (zone file) dışa aktarımını desteklemiyorsa kayıtları tür, ad, değer, öncelik ve TTL bilgileriyle birlikte belgeleyin.
Özellikle şu bilgileri kaydedin:
- Web sitesi ve
wwwalt alan adının A, AAAA veya CNAME kayıtları - E-posta hizmetine ait MX kayıtları ve öncelikleri
- SPF, DKIM ve DMARC kayıtları
- Doğrulama amaçlı TXT kayıtları
- Kullanılan alt alan adları ve servis adresleri
- CAA, SRV ve uygulamaya özgü diğer kayıtlar
- Mevcut nameserver adresleri ve DNSSEC durumu
Bu kayıtların bir kopyası, taşıma sonrasında sorun yaşanırsa eski yapılandırmanın yeniden kurulabilmesini sağlar.
DNS bölgesi yedeği, e-posta mesajlarının veya web sitesi dosyalarının yedeği değildir. Bu verilerin korunması için ayrıca yedekleme yapılmalıdır.
2. Yeni DNS bölgesini önceden oluşturun
Nameserver adreslerini hemen değiştirmek yerine önce yeni DNS sağlayıcısında alan adını ekleyin ve gerekli kayıtları oluşturun.
Örneğin Cloudflare kullanılacaksa alan adı hesaba eklenebilir, mevcut kayıtlar taranabilir ve eksik kayıtlar elle tamamlanabilir.
Ancak otomatik DNS taramasının bütün kayıtları tespit ettiği varsayılmamalıdır.
Cloudflare’ın nameserver geçişi dokümantasyonu, özellikle web sitesi, alt alan adı ve e-posta kayıtlarının nameserver değişikliğinden önce kontrol edilmesini önerir.
Yeni bölgede yapılandırma tamamlanmadan eski nameserver adreslerinin kaldırılması, kesinti riskini gereksiz yere artırır.
3. TTL değerlerini kontrol edin
TTL (Time to Live), DNS kayıtlarının önbellekte ne kadar süre saklanabileceğini belirleyen değerdir.
Örneğin 3600 saniyelik TTL, ilgili kaydın uygun önbellekleme davranışında bir saate kadar saklanabileceğini ifade eder.
Planlı bir DNS kaydı değişikliğinden önce TTL değerini düşürmek, eski cevapların daha kısa süre tutulmasına yardımcı olabilir.
Değişiklik yapılacak uygun kayıtlar için, sağlayıcının izin verdiği durumlarda 300 saniye gibi kısa bir TTL tercih edilebilir.
Ancak burada iki önemli ayrıntı vardır:
Birincisi: TTL düşürme işlemi, eski yüksek TTL değerleri önbelleklerden silinmeden hemen önce yapılırsa beklenen faydayı sağlamayabilir. Bu nedenle değişiklik önceden planlanmalıdır.
İkincisi: A veya MX kaydının TTL değerini düşürmek, alan adının üst DNS bölgesindeki nameserver delegasyonunun önbellek süresini doğrudan değiştirmez.
Nameserver değişikliklerinde delegasyon önbelleği ve kayıt kuruluşu süreçleri de etkilidir.
TTL yönetiminin ayrıntıları Cloudflare’ın resmî TTL belgesinde açıklanmaktadır.
E-Posta Kesintisini Önlemek İçin MX Kayıtlarını Koruyun
Nameserver geçişlerinde en kritik kontrollerden biri MX kayıtlarının korunmasıdır.
MX (Mail Exchanger), bir alan adına gönderilen e-postaların hangi posta sunucusuna yönlendirileceğini belirtir.
Örneğin ornekfirma.com alan adı üzerinden [email protected] adresi kullanılıyorsa gelen e-postaları teslim edecek sunucunun MX kayıtlarıyla tanımlanması gerekir.
MX kaydı nasıl çalışır?
Bir alan adının aşağıdaki gibi bir MX kaydına sahip olduğunu varsayalım:
| Tür | Ad | Hedef | Öncelik |
|---|---|---|---|
| MX | @ | mail.ornekfirma.com | 10 |
| A | 203.0.113.20 | — |
Bu değerler yalnızca açıklama amaçlıdır. 203.0.113.20, dokümantasyon için ayrılmış örnek IP adresidir.
Bu yapılandırmada gelen e-postaların tesliminde mail.ornekfirma.com hedefi kullanılır.
Nameserver değişikliğinden sonra MX kaydı yeni DNS bölgesinde bulunmuyorsa e-postaların teslimi başarısız olabilir.
Benzer şekilde MX kaydı doğru görünse bile hedef posta sunucusunun A veya AAAA kaydı yanlışsa yine teslimat problemi oluşabilir.
Bu nedenle MX kaydını kontrol ederken yalnızca öncelik numarasına değil, hedef sunucunun çözümlenebilir ve erişilebilir olmasına da dikkat edilmelidir.
E-posta hizmeti başka sağlayıcıdaysa ne yapılmalı?
Web sitesi ile e-posta aynı sağlayıcıda bulunmak zorunda değildir.
Örneğin web sitesi bir hosting hesabında barındırılırken e-posta hizmeti Google Workspace, Microsoft 365 veya bağımsız bir sağlayıcı üzerinde çalışabilir.
Bu durumda nameserver değişikliği sırasında e-posta sağlayıcısına ait MX kayıtları korunmalıdır.
Ayrıca mevcut kurumsal e-posta altyapısının hangi sunucularla çalıştığının bilinmesi gerekir.
Hostider tarafından sunulan kurumsal e-posta hizmeti gibi bağımsız posta çözümlerinde de alan adının e-posta trafiği, ilgili hizmetin sağladığı DNS ve MX bilgilerine göre yapılandırılır.
Kayıt değerleri sağlayıcıya özgüdür. Bu nedenle örnek MX değerlerini gerçek alan adına doğrudan uygulamak yerine mevcut hizmet sağlayıcısının güncel yapılandırması esas alınmalıdır.
SPF, DKIM ve DMARC Kayıtlarını Unutmayın
MX kayıtları e-posta alımında önemli rol oynarken SPF, DKIM ve DMARC kayıtları e-postaların doğrulanmasıyla ilgilidir.
Bu kayıtların aktarılmaması, e-posta gönderimi teknik olarak çalışsa bile iletilerin spam klasörüne düşmesine veya alıcı sistemler tarafından reddedilmesine neden olabilir.
SPF kaydı
SPF (Sender Policy Framework), alan adı adına e-posta göndermeye yetkili sunucuları veya servisleri tanımlamak için kullanılır.
Genellikle TXT kaydı olarak yayımlanır.
Örnek bir SPF kaydı şu şekilde olabilir:
v=spf1 ip4:203.0.113.20 -all
Bu örnekte yalnızca belirtilen IPv4 adresinin yetkilendirildiği ifade edilir.
Gerçek SPF kaydı; kullanılan posta sunucularına, üçüncü taraf gönderim hizmetlerine ve sağlayıcının gereksinimlerine göre hazırlanmalıdır.
Aynı alan adı için birden fazla bağımsız SPF kaydı oluşturulmamalıdır. Birden çok gönderim servisi varsa gerekli yetkilendirmeler uygun tek bir SPF politikası içinde düzenlenmelidir.
DKIM kaydı
DKIM (DomainKeys Identified Mail), gönderilen e-postaların dijital imzalarının doğrulanmasını sağlar.
DKIM imzasının doğrulanmasında DNS üzerinde yayımlanan açık anahtar kullanılır.
DKIM kayıtları genellikle belirli bir selector adıyla tanımlanır.
Örnek kayıt adı:
selector1._domainkey.ornekfirma.com
Buradaki selector1, ilgili e-posta sistemi tarafından kullanılan seçiciyi temsil eder.
Nameserver değişikliğinde mevcut DKIM kaydı aktarılmazsa yeni DNS bölgesi üzerinden ilgili açık anahtara ulaşılamayabilir.
Bu nedenle etkin DKIM selector kayıtları eksiksiz korunmalıdır.
DMARC kaydı
DMARC, SPF ve DKIM sonuçları ile alan adı hizalamasını değerlendirerek doğrulaması başarısız iletiler için bir politika tanımlar.
Örnek bir DMARC kaydı:
v=DMARC1; p=none
Bu örnek yalnızca temel politikayı gösterir. Gerçek uygulamalarda raporlama adresleri, alt alan adı politikaları ve farklı güvenlik seçenekleri bulunabilir.
DMARC politikasını geçiş sırasında rastgele değiştirmek doğru değildir.
Özellikle p=reject gibi katı politikalar, SPF ve DKIM yapılandırması düzgün çalışmıyorsa meşru e-postaların reddedilmesine yol açabilir.
Bu nedenle nameserver geçişi ile e-posta doğrulama politikasında kapsamlı değişiklik yapılmasını mümkünse ayrı işlemler olarak planlamak daha güvenlidir.
E-posta kayıtlarının hazırlanmasına ilişkin ayrıntılar Cloudflare’ın e-posta DNS kayıtları dokümantasyonunda bulunmaktadır.
cPanel Kullanılıyorsa Email Routing Ayarını Kontrol Edin
cPanel kullanan sistemlerde DNS kayıtlarının doğru olması her zaman yeterli değildir.
E-posta yönlendirme davranışı, cPanel’in Email Routing yapılandırmasından da etkilenebilir.
cPanel ortamında bu bölüm genellikle Email → Email Routing yolunda bulunur. Arayüz erişimi ve seçenekler sunucu yapılandırmasına göre değişebilir.
Başlıca seçenekler şunlardır:
| Seçenek | İşlevi |
|---|---|
| Local Mail Exchanger | Sunucu, alan adına gelen e-postaları yerel olarak kabul eder. |
| Remote Mail Exchanger | Sunucu, alan adının gelen e-postalarını yerel posta kutularına teslim etmez. |
| Backup Mail Exchanger | Sunucu, uygun şekilde yapılandırıldığında yedek posta sunucusu görevi görür. |
| Automatically Detect Configuration | Yerel DNS bölgesindeki MX bilgilerini kullanarak yönlendirme türünü belirlemeye çalışır. |
Burada dikkat edilmesi gereken konu otomatik algılamanın çalışma biçimidir.
cPanel’in Email Routing dokümantasyonuna göre otomatik algılama, gerçek zamanlı harici DNS sorgusu yapmak yerine sunucudaki yerel DNS bölgesini esas alır.
Dolayısıyla DNS yönetimi başka bir sağlayıcıya taşınmışsa yerel bölgedeki eski kayıtlar yönlendirme davranışını etkileyebilir.
Örneğin web sitesi cPanel sunucusunda, e-posta ise farklı bir sağlayıcıda çalışıyorsa yerel posta yönlendirmesinin yanlış seçilmesi e-posta akışında sorun oluşturabilir.
Ancak her dış MX kaydı için aynı ayarın geçerli olduğu düşünülmemelidir. Sunucunun geçit veya yedek posta işlevi de bulunabilir.
Bu nedenle Email Routing ayarları mevcut posta mimarisine göre kontrol edilmelidir.
DNS kayıtlarının düzenlenmesi için cPanel’in Domains → Zone Editor arayüzü kullanılabilir. Bununla birlikte nameserver başka bir DNS sağlayıcısına yönlenmişse cPanel üzerinde yapılan yerel DNS değişiklikleri herkese açık yetkili DNS cevaplarını değiştirmeyebilir.
DNSSEC Etkinse Nameserver Değişikliğine Dikkat Edin
DNSSEC (Domain Name System Security Extensions), DNS yanıtlarının doğruluğunu kriptografik yöntemlerle doğrulamaya yardımcı olan güvenlik mekanizmasıdır.
DNSSEC kullanılan alan adlarında üst DNS bölgesinde DS (Delegation Signer) kaydı bulunabilir.
Bu kayıt, alt bölgenin DNSSEC doğrulama zinciriyle ilişkilidir.
Nameserver değişikliği yapıldığında eski DNS sağlayıcısına ait DS kaydı korunur ancak yeni sağlayıcının DNSSEC anahtarlarıyla uyumlu olmazsa doğrulama hataları ortaya çıkabilir.
Bunun sonucunda DNSSEC doğrulaması yapan çözümleyiciler alan adı için SERVFAIL yanıtı döndürebilir.
Güvenli DNSSEC geçişi nasıl planlanır?
İzlenecek yöntem, eski ve yeni DNS sağlayıcılarının DNSSEC desteğine ve kullanılan geçiş modeline göre değişir.
Cloudflare’ın standart tam DNS kurulumunda önerilen işlem sırası şöyledir:
- Eski DNSSEC yapılandırmasını kontrol etmek.
- Nameserver değiştirilmeden önce kayıt kuruluşundaki eski DNSSEC/DS yapılandırmasını uygun şekilde kaldırmak.
- Yeni nameserver adreslerini tanımlamak.
- Yeni DNS hizmetinin çalıştığını doğrulamak.
- Yeni sağlayıcının DNSSEC anahtarlarını kullanarak DNSSEC’i yeniden etkinleştirmek.
- Kayıt kuruluşundaki yeni DS bilgisinin doğru olduğunu kontrol etmek.
DNSSEC geçici olarak kapatıldığında doğrulama zincirinin sağladığı güvenlik koruması da geçici olarak devre dışı kalır. Bu nedenle işlem planlı ve mümkün olduğunca kısa bir geçiş süreciyle yürütülmelidir.
DNSSEC’i etkin tutarak geçiş yapabilen gelişmiş yöntemler de vardır; ancak bu yöntemler iki sağlayıcının anahtar ve imza yönetiminin uyumlu olmasını gerektirir.
Cloudflare’ın DNSSEC ve nameserver değişikliği yönergeleri bu riskleri ayrıntılı şekilde açıklamaktadır.
Nameserver Değişikliği Adım Adım Nasıl Yapılır?
Ön hazırlık tamamlandıktan sonra değişiklik kontrollü biçimde gerçekleştirilebilir.
Adım 1: Eski nameserver bilgilerini kaydedin
Alan adı kayıt kuruluşunun yönetim panelinde mevcut nameserver adreslerini not alın.
Bu bilgiler olası geri dönüş senaryosunda gerekli olacaktır.
Adım 2: Yeni nameserver adreslerini alın
Yeni DNS sağlayıcısı, alan adına atanmış nameserver adreslerini sunar.
Cloudflare gibi hizmetlerde bu adresler hesap ve alan adına özel olabilir.
Bu nedenle başka bir alan adında kullanılan nameserver adresleri kopyalanmamalıdır.
Adım 3: Yeni DNS bölgesini doğrulayın
Nameserver değiştirilmeden önce yeni sağlayıcıdaki kayıtları mevcut bölgeyle karşılaştırın.
Özellikle web ve e-posta için kullanılan A, AAAA, MX, SPF, DKIM ve DMARC kayıtlarını kontrol edin.
Yeni sağlayıcının yetkili DNS sunucusu, delegasyon değiştirilmeden önce doğrudan sorgulanabiliyorsa bu kayıtlar önceden de test edilebilir.
Adım 4: Kayıt kuruluşundaki nameserver adreslerini değiştirin
Alan adının kayıt kuruluşunda nameserver yönetimi bölümünü açın.
Mevcut adresleri, yeni sağlayıcının alan adına özel olarak bildirdiği adreslerle değiştirin.
DNSSEC gereksinimleri ve varsa özel delegasyonlar önceden değerlendirilmiş olmalıdır.
Adım 5: Eski DNS bölgesini hemen silmeyin
Nameserver değişikliği sonrasında farklı çözümleyiciler, önbellekte bulunan eski delegasyon bilgilerini bir süre kullanmaya devam edebilir.
Bu nedenle eski yetkili DNS hizmetini hemen kapatmak yerine geçişin tamamlandığını gözlemlemek daha güvenlidir.
Eski ve yeni DNS bölgelerinin geçiş süresince aynı kritik hizmetlere yönlendirilmesi, tutarsız cevaplardan kaynaklanan riskleri azaltır.
Ancak bu yaklaşım, tüm istemciler için sıfır kesinti garantisi oluşturmaz.
Nameserver Değişikliğinden Sonra DNS Nasıl Kontrol Edilir?
DNS geçişinden sonra yalnızca web sitesinin tarayıcıda açılıp açılmadığını kontrol etmek yeterli değildir.
Yetkili nameserver bilgileri, DNS kayıtları ve gerçek hizmet erişimi ayrı ayrı test edilmelidir.
Linux ve macOS üzerinde dig komutuyla kontrol
dig, DNS sorgularını incelemek için kullanılabilen bir komut satırı aracıdır. Bazı sistemlerde ayrıca kurulması gerekebilir.
Alan adının NS kayıtlarını sorgulamak için:
dig ornekfirma.com NS +shortMX kayıtlarını kontrol etmek için:
dig ornekfirma.com MX +shortSPF ve diğer TXT kayıtlarını görüntülemek için:
dig ornekfirma.com TXT +shortDMARC kaydını kontrol etmek için:
dig _dmarc.ornekfirma.com TXT +shortKullanılan DKIM selector biliniyorsa:
dig selector1._domainkey.ornekfirma.com TXT +shortBu komutların tamamı sorgulama amaçlıdır. DNS kayıtlarını değiştirmezler.
Örnek alan adı ve DKIM selector değeri gerçek yapılandırmaya göre değiştirilmelidir.
Yeni yetkili DNS sunucusu doğrudan nasıl sorgulanır?
Yeni DNS sunucusundaki kayıtları önbellekten bağımsız olarak incelemek için sunucu açıkça belirtilebilir.
dig @ns1.yeni-dns.example ornekfirma.com MXBuradaki nameserver adresi örnektir. Gerçek geçişte sağlayıcının bildirdiği yetkili DNS sunucusu kullanılmalıdır.
Bu yöntem, yeni DNS bölgesinin gerçekten doğru MX kaydını sunup sunmadığını kontrol etmek açısından yararlıdır.
Sorgunun yanıt bayrakları ve yetkili sunucu bilgileri de incelenebilir.
Farklı DNS çözümleyicilerinden kontrol
Örneğin Cloudflare ve Google Public DNS üzerinden MX kayıtları sorgulanabilir:
dig @1.1.1.1 ornekfirma.com MX +short
dig @8.8.8.8 ornekfirma.com MX +shortYanıtların farklı olması, çözümleyicilerde farklı sürelerle saklanan DNS verilerinden kaynaklanabilir.
Ancak bu durumun tek açıklaması önbellek değildir. Yanlış yapılandırma veya DNSSEC doğrulama sorunları da araştırılmalıdır.
Windows üzerinde DNS kontrolü
Windows sistemlerde PowerShell’in Resolve-DnsName komutu kullanılabilir.
Resolve-DnsName ornekfirma.com -Type MXNS kayıtlarını sorgulamak için:
Resolve-DnsName ornekfirma.com -Type NSBöylece DNS yapılandırması farklı işletim sistemlerinde karşılaştırılabilir.
DNS Yayılımı Ne Kadar Sürer?
Nameserver değişiklikleri için bütün dünyada geçerli, kesin bir tamamlanma süresi bulunmaz.
Kayıt kuruluşunun değişikliği işlemesi, üst DNS bölgesindeki delegasyon bilgileri, TTL değerleri ve DNS çözümleyicilerin önbellek davranışı sonucu etkiler.
Bazı sorgularda yeni nameserver bilgileri kısa sürede görünürken diğer sorgularda eski bilgiler bir süre daha kullanılabilir.
Bu nedenle geçişin yalnızca birkaç dakika içinde tamamlanacağını garanti etmek doğru değildir.
Süreç boyunca hem eski hem yeni DNS hizmetinin doğru kayıtları sunması önemlidir.
DNS kayıtlarının farklı katmanlarda nasıl önbelleğe alındığı, DNS önbelleğinin çalışma biçimi hakkındaki rehberde açıklanmaktadır.
Yerel DNS önbelleğini temizlemek bazı istemci sorunlarını gidermeye yardımcı olabilir. Ancak bu işlem, kayıt kuruluşundaki delegasyon değişimini hızlandırmaz veya üçüncü taraf DNS çözümleyicilerin bütün önbelleklerini temizlemez.
Nameserver Değişikliğinden Sonra E-Posta Çalışmıyorsa Ne Yapılmalı?
E-posta sorunu yaşanıyorsa farklı ihtimaller belirli bir sırayla değerlendirilmelidir.
1. MX kaydının yeni DNS bölgesinde bulunduğunu doğrulayın
MX kaydı eksikse e-posta alımı etkilenebilir.
Ancak DNS standartları gereği MX kaydı bulunmayan bazı alan adlarında belirli koşullarla adres kayıtlarına dayalı teslim denemesi yapılabildiğinden, yalnızca MX kaydının yokluğundan bütün teslimatların kesin olarak başarısız olduğu sonucu çıkarılmamalıdır.
2. MX hedefinin doğru çözümlendiğini kontrol edin
MX kaydının yönlendirdiği posta sunucusunun DNS adreslerini inceleyin.
MX hedefinin doğrudan bir IP adresi yerine geçerli bir posta sunucusu alan adı olması gerekir. Standartlara uygun yapılandırmada MX hedefi CNAME takma adına değil, uygun adres kayıtları bulunan gerçek bir sunucu adına işaret etmelidir.
3. Cloudflare kullanılıyorsa proxy durumunu inceleyin
Cloudflare üzerinde standart e-posta trafiği için kullanılan sunucu adlarının DNS Only modunda bulunması gerekebilir.
Özellikle MX hedefi olarak kullanılan posta sunucusunun A veya AAAA kaydının web trafiğine yönelik HTTP proxy üzerinden çalışacağı varsayılmamalıdır.
İlgili yapılandırma, posta sağlayıcısının talimatlarıyla birlikte kontrol edilmelidir.
4. cPanel Email Routing ayarlarını inceleyin
E-posta farklı bir sağlayıcıda barındırılıyorsa cPanel sunucusunun e-postaları yerel olarak teslim etmeye çalışmadığından emin olun.
Bu kontrol özellikle web sitesi ile e-posta hizmeti ayrıldığında önem kazanır.
5. E-posta gönderim doğrulamasını test edin
Alan adı üzerinden harici bir posta kutusuna test iletisi gönderin.
Ardından farklı bir sağlayıcıdaki hesaptan ilgili alan adına test e-postası yollayın.
Her iki yöndeki işlem ayrı ayrı doğrulanmalıdır.
Gönderilen mesajın alıcıya ulaşması tek başına SPF, DKIM ve DMARC yapılandırmasının kusursuz olduğu anlamına gelmez.
Uygun test araçları veya posta başlıkları üzerinden doğrulama sonuçlarının da incelenmesi gerekir.
Nameserver Değişikliğinde Geri Dönüş Planı
Yeni yapılandırma beklendiği gibi çalışmıyorsa öncelikle sorunun DNS bölgesi kayıtlarından mı, delegasyondan mı yoksa posta sunucusundan mı kaynaklandığı belirlenmelidir.
Yeni DNS bölgesinde tek bir MX kaydı eksikse nameserver adreslerini yeniden değiştirmek yerine doğru kaydı eklemek daha uygun olabilir.
Bununla birlikte sorun yaygın ve kritikse eski DNS hizmetine dönüş değerlendirilebilir.
Geri dönüş için şu hazırlıklar yapılmış olmalıdır:
- Eski nameserver adresleri kaydedilmiş olmalı.
- Eski DNS bölgesi çalışır durumda tutulmalı.
- Eski bölgedeki web ve posta kayıtları güncel olmalı.
- DNSSEC/DS yapılandırması geri dönüş yönüne uygun şekilde planlanmalı.
- Kayıt kuruluşu hesabına güvenli erişim sağlanmalı.
Eski nameserver adreslerini geri yüklemek, bütün DNS çözümleyicilerin anında eski yapılandırmayı kullanacağı anlamına gelmez.
Bu nedenle geri dönüş işlemi de kontrollü bir geçiş olarak ele alınmalıdır.
Özellikle DNSSEC etkin alan adlarında plansız geri dönüş yeni doğrulama hatalarına yol açabilir.
Sıkça Sorulan Sorular
Nameserver değiştirmek e-postaları siler mi?
Hayır. Nameserver değişikliği tek başına posta kutularını veya mevcut e-postaları silmez. Ancak DNS kayıtları yanlış yapılandırılırsa yeni gelen mesajların teslimi etkilenebilir. Gerçek posta sunucusu taşınacaksa mesajların ve hesapların ayrıca aktarılması gerekir.
Nameserver değiştirildiğinde hosting de değişir mi?
Hayır. Nameserver değişikliği, alan adının DNS kayıtlarını hangi sunucuların yöneteceğini değiştirir. Web sitesi dosyaları ve veritabanı mevcut hosting sunucusunda kalabilir.
MX kayıtları doğru olduğu halde e-posta neden çalışmaz?
MX hedefinin yanlış IP adresine çözülmesi, posta sunucusunun erişilemez olması, cPanel Email Routing ayarlarının yanlış yapılandırılması veya DNSSEC sorunları gibi farklı nedenler bulunabilir.
Nameserver değiştirmeden önce TTL düşürmek gerekli mi?
Her zaman zorunlu değildir ancak belirli DNS kayıtlarının planlı şekilde değiştirilmesinde yararlı olabilir. Bununla birlikte A veya MX kayıtlarının TTL değerlerini düşürmek nameserver delegasyonunun önbellek süresini doğrudan azaltmaz.
Cloudflare’a geçince MX kayıtları otomatik aktarılır mı?
Cloudflare mevcut DNS kayıtlarını tarayabilir ancak tüm kayıtların bulunması garanti edilmez. MX ve diğer e-posta kayıtları geçişten önce manuel olarak doğrulanmalıdır.
Nameserver değişikliği sırasında DNSSEC kapatılmalı mı?
Bu, kullanılan geçiş yöntemine bağlıdır. Cloudflare’ın standart tam kurulum sürecinde eski DNSSEC/DS yapılandırmasının geçiş öncesinde kaldırılması ve yeni yapılandırmanın geçişten sonra etkinleştirilmesi önerilir. Diğer sağlayıcılarda farklı yöntemler bulunabilir.
Web sitesi açılıyor ama e-postalar gelmiyorsa sorun DNS olabilir mi?
Evet. Web sitesi ve e-posta farklı DNS kayıtlarını kullanır. A kaydı doğru çalışırken MX kayıtları eksik veya yanlış olabilir. Bu nedenle iki hizmet bağımsız olarak test edilmelidir.
Sonuç
Nameserver değişikliği, doğru hazırlık yapıldığında web sitesi ve e-posta hizmetlerini başka sunuculara taşımadan gerçekleştirilebilir. Ancak işlemin güvenliği, yalnızca yeni nameserver adreslerinin doğru yazılmasına bağlı değildir.
Mevcut DNS kayıtlarının yedeklenmesi, yeni bölgenin önceden hazırlanması, MX ve e-posta doğrulama kayıtlarının korunması, cPanel yönlendirme ayarlarının kontrol edilmesi ve DNSSEC yapılandırmasının uygun şekilde yönetilmesi gerekir.
Geçiş tamamlandıktan sonra web sitesinin erişilebilirliğini ve e-posta trafiğini farklı ağlardan test etmek, olası yapılandırma sorunlarını erken tespit etmeye yardımcı olur.
DNS taşıma işlemlerinde en güvenilir yaklaşım, değişiklikleri tek seferde ve kontrolsüz biçimde uygulamak yerine mevcut ve yeni yapılandırmaları karşılaştırarak ilerlemektir. Böylece hem kesinti riski azaltılır hem de gerektiğinde geri dönüş için gerekli bilgiler korunmuş olur.
