Site Açılıyor Ama E-Posta Çalışmıyor: DNS Kayıtlarıyla Teşhis

DNS e-posta sorunu yaşandığında web sitesinin açılması, e-posta hizmetinin de doğru çalıştığını göstermez. Çünkü web trafiğini yönlendiren A veya CNAME kaydı ile alan adına gelen e-postaları yönlendiren MX kaydı farklı görevler üstlenir. Örneğin example.com alan adı bir sunucunun IP adresine yönlenerek siteyi açabilir; ancak [email protected] adresine gelen iletiler için doğru MX kaydı yoksa e-posta alımı yine başarısız olur.

Teşhise en güvenli başlangıç noktası nameserver kontrolüdür. Alan adının hangi DNS sunucularından yanıt aldığını doğrulamadan A, CNAME veya MX kayıtlarını incelemek, yanlış panelde yapılan düzenlemeleri kontrol etmek anlamına gelebilir.

Site Açılıyorsa E-Posta Neden Çalışmayabilir?

Alan adı, web sitesi ve e-posta gibi hizmetlerin aynı isim altında kullanılmasını sağlayan internet adresidir. Örneğin example.com bir alan adıdır. Bu alan adına ait farklı DNS kayıtları, alan adının farklı hizmetlere nasıl ulaşacağını belirler.

DNS kaydı, bir alan adı veya alt alan adı hakkında yönlendirme bilgisi taşıyan kayıttır. Bir kayıt web sunucusunun IP adresini gösterebilir, başka bir kayıt e-posta sunucusunu belirtebilir. Bu nedenle DNS, tek bir “site çalışıyor mu?” ayarından oluşmaz; her hizmet için farklı kayıtlar birlikte değerlendirilir.

Web sitesinin açılmasını sağlayan temel kayıtlar genellikle şunlardır:

• A kaydı: Bir alan adını veya alt alan adını IPv4 adresine yönlendirir.
• CNAME kaydı: Bir alan adını başka bir alan adına takma ad olarak yönlendirir. Son hedefin IP adresi, yönlendirilen alan adının DNS kayıtlarından bulunur.

E-posta alımı için kullanılan temel kayıt ise MX kaydıdır. MX, “Mail Exchange” ifadesinin kısaltmasıdır ve alan adına gönderilen e-postaların hangi posta sunucusuna teslim edileceğini belirtir. Posta sunucusu, e-postaları kabul eden, işleyen ve kullanıcıların posta kutularına ulaştıran sunucudur.

Basit bir örnek üzerinden düşünelim:

• example.com için A kaydı, web sunucusunun 203.0.113.10 adresini gösteriyor olabilir.
• www.example.com için CNAME kaydı, example.com adresini işaret ediyor olabilir.
• Ancak example.com için MX kaydı tanımlı değilse veya yanlış posta sunucusunu gösteriyorsa [email protected] adresine gelen e-postalar teslim edilemeyebilir.

Bu üç kayıt aynı DNS bölgesinde bulunabilse de görevleri aynı değildir. A ve CNAME kayıtları temel olarak web gibi bir hizmete ulaşılacak hedefi belirler. MX kaydı ise alan adına gelen e-postaların teslim edileceği sunucuyu belirler. Sitenin açılması yalnızca web yönlendirmesinin çalıştığını kanıtlar; e-posta yönlendirmesinin doğru olduğunu kanıtlamaz.

“Site açılıyor ama e-posta gelmiyor” durumunda olası tablo

Bir kullanıcı tarayıcıya example.com yazdığında tarayıcı, alan adının web için hangi hedefe yönlendirildiğini sorgular. A kaydı doğrudan bir IPv4 adresi döndürürse tarayıcı bu adrese bağlanmayı dener. CNAME kullanılıyorsa önce takma adın gösterdiği alan adı çözülür, ardından web sunucusunun adresi bulunur.

Bir gönderen ise [email protected] adresine e-posta gönderdiğinde aynı işlemi yapmaz. Gönderenin posta sistemi, example.com alan adının MX kaydını sorgular. Dönen posta sunucusuna bağlanarak iletiyi teslim etmeyi dener. Dolayısıyla web için doğru çalışan A kaydı, gelen e-postalar için gerekli MX kaydının yerine geçmez.

Bu ayrım, şu belirtileri açıklayabilir:

• Web sitesi açılır, fakat alan adı uzantılı e-posta adresine gönderilen iletiler geri döner.
• E-posta gönderimi yapılabilir, fakat dışarıdan gönderilen e-postalar ulaşmaz.
• Bazı göndericilerden e-posta gelirken bazı göndericilerden gelmez.
• Yeni bir e-posta hizmetine geçiş yapılmış olmasına rağmen dış sistemler eski posta sunucusuna teslimat yapmayı sürdürür.
• DNS panelinde MX kaydı görülür, ancak bu kayıt internete yanıt veren yetkili DNS bölgesinde bulunmaz.

Burada özellikle gönderme ve alma yönünü birbirinden ayırmak gerekir. MX kaydı gelen e-postaların yönlendirilmesiyle ilgilidir. SPF gibi TXT tabanlı kayıtlar ise esas olarak alan adı adına hangi sunucuların e-posta göndermesine izin verildiğini bildirmek için kullanılır. Bu nedenle SPF kaydındaki hata, her zaman gelen e-posta alımının temel nedeni değildir; gelen teslimat sorununda önce MX ve nameserver zinciri incelenmelidir.

İlk Kontrol: NS Kayıtları DNS Yönetimini Gösterir

NS kaydı, “Name Server” ifadesinin kısaltmasıdır ve bir alan adının DNS sorgularına hangi yetkili DNS sunucularının cevap vereceğini gösterir. Yetkili DNS sunucusu, alan adı için geçerli kabul edilen DNS bölgesini barındıran ve A, CNAME, MX, TXT gibi kayıtlar hakkında cevap veren sunucudur.

DNS yönetiminde en sık yapılan hatalardan biri, kayıtların doğru göründüğü halde yanlış DNS panelinde düzenlenmesidir. Bunun nedeni, alan adı için kullanılan nameserver’ların başka bir sağlayıcıya veya başka bir DNS yönetim hesabına işaret etmesidir.

Örneğin şu senaryoyu ele alalım:

1. Alan adının NS kayıtları, DNS hizmeti sağlayan birinci sisteme yöneliktir.
2. Kullanıcı web sitesi için A kaydını ve e-posta için MX kaydını ikinci bir panelde ekler.
3. İkinci panelde kayıtlar doğru biçimde görünür.
4. Ancak alan adının NS kayıtları hâlâ birinci sistemi gösterdiği için internet üzerindeki DNS sorguları ikinci paneli sormaz.
5. Sonuç olarak tarayıcı veya gönderen posta sunucusu, ikinci paneldeki yeni kayıtları değil, birinci sistemdeki yetkili bölgeyi görür.

Bu durumda kullanıcı “MX kaydını ekledim” diyebilir; fakat dışarıdan yapılan sorguda MX kaydı hiç görünmeyebilir veya eski posta sunucusu dönebilir. Aynı durum A ve CNAME kayıtları için de geçerlidir. Panelde kayıt bulunması ile kaydın yetkili DNS yanıtında görünmesi aynı şey değildir.

Nameserver ile DNS panelini karşılaştırma akışı

İlk kontrol için alan adınızın NS sorgusunu yapın. Sorgu sonucunda dönen nameserver adlarını, A, CNAME veya MX kayıtlarını düzenlediğiniz panelde belirtilen yetkili sunucularla karşılaştırın.

1. Alan adını doğru yazın ve mümkünse sonuna nokta eklemeden sorgulayın.
2. NS kayıtlarını sorgulayın.
3. Çıktıda listelenen nameserver adlarını not edin.
4. DNS kayıtlarını düzenlediğiniz panelin gerçekten bu sunuculara ait olup olmadığını kontrol edin.
5. Uygunluk yoksa A, CNAME veya MX kayıtlarını tekrar tekrar değiştirmeden önce DNS yönetiminin hangi sistemde olduğunu kesinleştirin.

Windows Komut İstemi’nde nslookup aracını kullanarak NS sorgusu yapabilirsiniz. Microsoft’un dokümantasyonunda nslookup aracının DNS altyapısını incelemek ve belirli kayıt türlerini sorgulamak için kullanılabildiği belirtilir. Microsoft Learn nslookup belgeleri bu komutun etkileşimli ve tek satırlık kullanım biçimlerini açıklar.

nslookup -type=NS example.com

Gerçek bir alan adı yerine kendi alan adınızı yazmalısınız. Beklenen çıktı, sorgunun hangi DNS sunucusundan yanıtlandığını gösteren bir bölüm ve ardından alan adının NS kayıtlarını içeren satırlardır. Çıktı yapısı işletim sistemi ve kullanılan DNS yanıtlayıcısına göre değişebilir; burada aranacak temel bilgi, alan adınız için dönen yetkili nameserver adlarıdır.

Örnek olarak çıktıda şu tür satırlar görebilirsiniz:

example.com    nameserver = ns1.example-dns.net
example.com    nameserver = ns2.example-dns.net

Bu satırlar, DNS kayıtlarını düzenlemeniz gereken sistemin bu nameserver’ların yönettiği yetkili bölge olması gerektiğini gösterir. Panelinizde farklı nameserver adları belirtiliyorsa veya düzenleme yaptığınız sistem bu sunucularla ilişkili görünmüyorsa, yaptığınız değişikliklerin dış DNS sorgularında görünmemesi beklenebilir.

NS sonucu doğru görünse bile neyi kontrol etmelisiniz?

NS sorgusu doğru paneli bulmanıza yardımcı olur; ancak tek başına e-posta yapılandırmasının tamamlandığını göstermez. Yetkili nameserver’ları belirledikten sonra aynı DNS yanıt zinciri üzerinde ayrıca şu kayıtları inceleyin:

• A kaydı web alan adını beklenen sunucuya yönlendiriyor mu?
• CNAME kaydı varsa hedef alan adı doğru çözülüyor mu?
• MX kaydı alan adına gelen e-postaları kabul etmesi gereken posta sunucusunu gösteriyor mu?
• MX kaydının hedefi bir alan adıysa, bu hedefin kendi A veya AAAA kaydı çözümlenebiliyor mu?
• Kontrol ettiğiniz kayıtlar, düzenleme yaptığınız panelde değil, NS sorgusuyla belirlenen yetkili DNS bölgesinde gerçekten yanıtlanıyor mu?

Özellikle aynı alan adının farklı sistemlerde kopya DNS kayıtlarına sahip olduğu durumlarda panel ekranı yanıltıcı olabilir. Teşhiste güvenilecek nokta, yalnızca yönetim arayüzünde görünen kayıt değil, dışarıdan yapılan sorguda dönen yetkili yanıttır. Bu nedenle NS kontrolü, “site açılıyor ama e-posta çalışmıyor” sorununda A, CNAME ve MX kayıtlarını incelemeden önce yapılması gereken ilk adımdır.

A, CNAME ve MX Kayıtlarını Birbirine Karıştırmayın

Bir web sitesinin açılması ile alan adına gelen e-postaların doğru sunucuya ulaşması, DNS içinde farklı kayıtlarla yönetilir. A ve CNAME kayıtları çoğunlukla web erişiminin, MX kaydı ise gelen e-posta yönlendirmesinin parçasıdır. Bu nedenle site sorunsuz açılırken e-posta alımı tamamen durmuş olabilir.

Örneğin alan adının A kaydı çalışan bir web sunucusuna yöneliyorsa ziyaretçiler siteyi görüntüleyebilir. Ancak aynı alan adında MX kaydı eksikse, yanlış yazılmışsa veya artık kullanılmayan farklı bir posta sunucusunu gösteriyorsa gönderici sistemler e-postayı nereye teslim edeceğini belirleyemez.

A kaydı web sunucusunu bulmaya yardım eder

A kaydı, bir adın hangi IPv4 adresinde çözümleneceğini belirtir. Örneğin ana alan adı bir web sunucusunun IP adresine eşlenebilir. Tarayıcı alan adını açarken DNS çözümlemesi sonucunda bu IP adresine ulaşır ve web isteğini ilgili sunucuya gönderir.

Bu işlemin başarılı olması, posta sisteminin de doğru yapılandırıldığı anlamına gelmez. A kaydı çalışıyor olsa bile alan adının MX kayıtları bağımsız olarak eksik veya hatalı olabilir. Dolayısıyla yalnızca “site açılıyor” sonucuna bakarak DNS yapılandırmasının tamamının doğru olduğu söylenemez.

CNAME kaydı bir adı başka bir ada bağlar

CNAME kaydı doğrudan bir IPv4 adresi belirtmek yerine, sorgulanan adı başka bir alan adına bağlayan takma ad kaydıdır. Örneğin bir alt alan adı, esas hizmet adını gösteren başka bir alan adına CNAME olarak tanımlanabilir. DNS çözümleyicisi daha sonra hedef adın A veya ilgili diğer kayıtlarını sorgular.

CNAME hedefi bir IP adresi değil, alan adı olmalıdır. Ayrıca CNAME kullanılan ad üzerinde başka kayıt türleriyle çakışma oluşturulmaması gerekir. Bu nedenle özellikle ana alan adı, web alt alan adı ve posta için kullanılan adlar düzenlenirken kaydın hangi ad üzerinde oluşturulduğu dikkatle kontrol edilmelidir.

MX kaydı gelen e-postanın teslim rotasını açıklar

MX kaydı, kullanıcıların posta kutularını doğrudan oluşturmaz. DNS üzerinden, “Bu alan adına gönderilen e-postayı hangi posta sunucusu kabul etmeli?” sorusunu yanıtlar. MX kaydının hedefinde posta sunucusunun alan adı bulunur; doğrudan IP adresi kullanılmaz.

Örneğin web sitesi A veya CNAME kayıtları sayesinde açılırken MX kaydı farklı bir posta altyapısının sunucu adına işaret ediyor olabilir. Böyle bir durumda web trafiği doğru yere gider, fakat gelen e-posta eski, yanlış veya erişilemeyen bir posta sistemine yönlendirilebilir. Teşhiste web kayıtlarını tekrar tekrar değiştirmek yerine MX sonucunu bağımsız olarak incelemek gerekir.

MX Sorunlarını Bulgudan Nedene Eşleştirme

MX teşhisinde en güvenli yaklaşım, rastgele kayıt değiştirmek yerine gözlenen bulgudan olası nedene ilerlemektir. Web sitesi çalışıyor fakat gelen e-postalar ulaşmıyorsa kontrol sırası önce yetkili DNS yönetimini gösteren NS kayıtları, ardından yayımlanan MX kayıtları ve son olarak gerçek gönderim testi olmalıdır.

Bu sıra önemlidir. Çünkü doğru görünen bir MX kaydı yanlış DNS panelinde oluşturulmuşsa internette kullanılan yetkili DNS kayıtlarına hiç yansımayabilir. Panelde kaydı görmek tek başına yeterli değildir; alan adının yetkili ad sunucularından dönen sonuç kontrol edilmelidir.

Eksik MX kaydı

MX sorgusu hiçbir sonuç döndürmüyorsa ilk şüphe kayıt eksikliğidir. Ancak hemen yeni kayıt eklemek yerine hangi DNS sisteminin yetkili olduğu doğrulanmalıdır. Alan adı farklı ad sunucularını kullanırken başka bir panelde MX oluşturmak, görünürde doğru fakat etkisiz bir yapılandırma meydana getirir.

Temel sorgu aşağıdaki komutla yapılabilir. Örnekteki alan adı, kontrol edilecek gerçek alan adıyla değiştirilmelidir.

nslookup -type=mx example.com

Alternatif olarak MX kayıtlarını doğrudan görmek için şu komut kullanılabilir:

dig MX example.com

Çıktıda MX hedefi bulunmuyorsa NS kontrolüne geri dönülmelidir. Hedef görünüyorsa bir sonraki adım, yazım hatası olup olmadığını ve hedef adın beklenen posta altyapısına ait olup olmadığını incelemektir.

Yanlış posta sunucusu hedefi

MX kaydı mevcut olduğu hâlde yanlış alan adına işaret edebilir. Eski bir posta hizmetinden kalan kayıt, hedef adındaki tek karakterlik yazım hatası veya yanlış alan adından kopyalanan yapılandırma teslimatı bozabilir. MX hedefinin sonunda posta sunucusunu temsil eden geçerli bir alan adı bulunmalı; hedef alanına IP adresi yazılmamalıdır.

DNS sorgusunda bir MX kaydının görünmesi, o hedefin doğru olduğu veya posta kabul ettiği anlamına gelmez. Sorgu sonucu, kullanılmak istenen posta sisteminin doğrulanmış yapılandırmasıyla karşılaştırılmalıdır.

Hatalı öncelik değeri

Birden fazla MX kaydında tercih değeri, gönderici posta sisteminin önce hangi sunucuya teslimat deneyeceğini etkiler. Daha düşük tercih değeri daha öncelikli MX hedefini ifade eder. İlk hedef kullanılamadığında diğer MX hedefleri tercih sırasına göre değerlendirilebilir.

Öncelik değerlerinin yanlış sıralanması, yedek olması amaçlanan sunucunun birincil hedef gibi kullanılmasına yol açabilir. Tek bir MX kaydı varsa değer, başka bir MX hedefiyle seçim yapılmasını sağlamaz; asıl kritik nokta hedef adın doğru olmasıdır. Birden fazla kayıt varsa hem değerler hem de her hedefin aynı alan adı için posta kabul edecek şekilde yapılandırılıp yapılandırılmadığı incelenmelidir.

Çakışan veya gereksiz MX kayıtları

Farklı dönemlerde kullanılan posta sistemlerine ait MX kayıtları aynı DNS bölgesinde bırakılabilir. Bu durum özellikle eski ve yeni posta altyapılarının birlikte görünmesine neden olur. Gönderici sistem, tercih değerlerine ve bağlantı durumuna bağlı olarak istenmeyen hedeflerden birini deneyebilir.

Her MX kaydı için “Bu sunucu neden burada?” sorusu yanıtlanmalıdır. Amacı bilinmeyen bir kaydı doğrudan silmek yerine mevcut posta düzeni, yedekleme planı ve doğrulanmış yapılandırma kontrol edilmelidir. Gereksiz kayıt ile bilinçli yedek MX kaydı birbirine karıştırılmamalıdır.

Yanlış DNS panelinde düzenleme yapılması

En yanıltıcı durumlardan biri, MX kaydının yönetim panelinde doğru görünmesine rağmen genel DNS sorgularında farklı sonuç vermesidir. Bunun temel nedeni, düzenlenen panelin alan adının yetkili DNS hizmeti olmaması olabilir.

Bu durumda teşhis sırası nettir: Önce NS sorgusuyla yetkili ad sunucuları belirlenir, ardından MX kaydı doğrudan sorgulanır ve son olarak dış bir e-posta hesabından gerçek teslimat testi yapılır. Böylece panelde görülen yapılandırmayla internetten alınan DNS yanıtı birbirinden ayrılır.

SPF Kaydı Neyi Çözer, Neyi Çözmez?

SPF, alan adınız adına hangi sunucuların e-posta göndermeye yetkili olduğunu bildiren bir gönderim doğrulama mekanizmasıdır. DNS üzerinde TXT kaydı olarak yayımlanır ve alıcı e-posta sunucusunun, gelen mesajın gönderildiği sunucuyu alan adının yayınladığı politika ile karşılaştırmasına yardımcı olur.

Örneğin alan adınızdan gönderilen bir mesajın gerçekten yetkili bir e-posta sunucusundan çıkıp çıkmadığı SPF ile değerlendirilebilir. Alıcı sistem, mesajın gönderim sırasında kullandığı alan adı kimliğini ve bağlantı kuran sunucunun IP adresini SPF kaydındaki kurallarla karşılaştırır. Sonuç; yetkili, yetkisiz, geçici hata veya yapılandırma hatası gibi farklı biçimlerde görülebilir.

SPF’nin görevi burada sona erer: SPF gelen e-postanın hangi sunucuya teslim edileceğini belirlemez. Alan adınıza gönderilen e-postaların hangi posta sunucusuna yönlendirileceği MX kayıtlarıyla ilgilidir. Bu nedenle site açılıyor ancak e-posta alınamıyorsa yalnızca SPF kaydına bakmak yanlış teşhis yönüne götürebilir. Önce MX kaydının doğru posta sunucusunu gösterip göstermediği incelenmelidir.

SPF kaydı hangi sorunlarda yardımcı olur?

SPF özellikle alan adınız kullanılarak yetkisiz sunuculardan e-posta gönderilmesini tespit etmeye yardımcı olur. Bir alıcı sunucu, mesajın gönderim kaynağını alan adının SPF politikasıyla eşleştirdiğinde aşağıdaki durumlarla karşılaşabilir:

• Mesaj yetkili bir sunucudan gönderilmişse SPF sonucu olumlu olabilir.
• Mesaj, alan adının izin verdiği sunucular arasında bulunmayan bir kaynaktan çıkmışsa SPF başarısız olabilir.
• DNS geçici olarak yanıt vermiyorsa sonuç geçici bir hata olarak değerlendirilebilir.
• SPF kaydı birden fazla veya yorumlanamayacak biçimde yayınlanmışsa alıcı sistem yapılandırma hatası bildirebilir.

SPF’nin başarılı olması, mesajın kesin olarak gelen kutusuna ulaşacağını da garanti etmez. Alıcı sistemler spam filtreleri, alan adı itibarı, DKIM veya DMARC sonuçları, içerik analizi ve kullanıcı politikaları gibi başka kontroller uygulayabilir. Aynı şekilde SPF başarısız olduğunda da her alıcı sistemin mesajı ele alma biçimi aynı olmayabilir.

SPF ile MX kaydını nasıl ayırmalısınız?

Bu ayrım, “site açılıyor ama e-posta çalışmıyor” sorununun temel teşhis noktasıdır. A kaydı veya CNAME kaydı web sitesini doğru sunucuya götürebilir; ancak bu kayıtların doğru olması, alan adının posta alımının da doğru yapılandırıldığı anlamına gelmez. Gelen posta için MX, giden posta doğrulaması için SPF değerlendirilir.

Gönderim testi ile alım testini ayrı yapın

DNS e-posta sorunu araştırılırken tek bir test yapmak yeterli değildir. Çünkü e-posta alımı ile e-posta gönderimi farklı kayıtları ve farklı sunucu kontrollerini kullanabilir.

• Alım testi: Alan adınız dışındaki bir e-posta adresinden alan adınızdaki posta kutusuna mesaj gönderin. Mesajın ulaşmasını, gecikmesini, geri dönmesini veya hiç görünmemesini ayrı ayrı not edin.
• Gönderim testi: Alan adınızdaki posta kutusundan dış bir e-posta adresine mesaj gönderin. Alıcı tarafta mesajın ulaşıp ulaşmadığını, spam klasörüne düşüp düşmediğini ve varsa hata bildiriminde SPF sonucunun nasıl göründüğünü inceleyin.

Dış adresten gönderilen mesaj hiç ulaşmıyorsa MX hedefi, MX hedefinin A veya AAAA çözümü, posta sunucusunun durumu ve posta kutusunun varlığı incelenmelidir. Alan adınızdan gönderilen mesaj reddediliyor veya doğrulama sorunu gösteriyorsa SPF kaydı, gönderen sunucunun yetkisi ve alıcı tarafındaki kimlik doğrulama sonucu değerlendirilmelidir.

Birden fazla SPF kaydı neden kontrol edilmelidir?

Aynı alan adı için birden fazla TXT kaydının v=spf1 ile başlayan ayrı SPF politikaları içermesi, SPF değerlendirmesinde yapılandırma sorununa yol açabilir. RFC 7208, bir yetkilendirme kontrolünün birden fazla SPF kaydı seçmesine neden olacak yayın biçimini geçerli bir yapı olarak kabul etmez; böyle bir durumda alıcı sistem permerror sonucu üretebilir. Bu nedenle TXT kayıtlarını incelerken yalnızca “SPF kaydı var mı?” sorusu sorulmamalı, aynı ad için birden fazla SPF politikası bulunup bulunmadığı da kontrol edilmelidir. Teknik çerçeve için RFC 7208 SPF standardı başvuru kaynağıdır.

Burada önemli bir ayrım vardır: Tek bir TXT kaydının teknik olarak birden fazla metin parçasından oluşması ile aynı alan adı için birden fazla ayrı SPF kaydının bulunması aynı şey değildir. DNS panelinde satırlar farklı görünebilir. Bu nedenle kayıtları birleştirme veya silme kararı verilmeden önce hangi sistemlerin alan adınız adına e-posta gönderdiği belirlenmeli, ardından yalnızca bulguya dayalı değişiklik yapılmalıdır.

SPF incelemesinde pratik kontrol listesi

• TXT kayıtları arasında v=spf1 ile başlayan politika var mı?
• Aynı alan adı için birden fazla ayrı SPF politikası yayınlanmış mı?
• Mesajı gönderen gerçek sunucu veya hizmet SPF politikasında yetkili olarak tanımlanmış mı?
• SPF kaydı yalnızca varsayılan bir metin olarak mı duruyor, yoksa gerçek gönderim mimarisini yansıtıyor mu?
• Alım sorunu SPF’ye bağlanmadan önce MX kaydı kontrol edildi mi?
• Gönderim testi sırasında alıcı sunucunun verdiği SPF sonucu veya hata açıklaması kaydedildi mi?

Uygulanabilir DNS Teşhis Akışı ve Karar Ağacı

DNS hata ayıklama sürecinde en güvenilir yöntem, belirtileri birbirine karıştırmadan bulgudan nedene ilerlemektir. Önce web ve e-posta davranışını ayrı kaydedin; ardından DNS kayıtlarını yetki sırasına göre inceleyin. Her adımda yalnızca gözlenen sonuca bağlı bir sonraki kontrole geçin.

1. Web erişimini ayrı bir belirti olarak kaydedin.

   Site tarayıcıda açılıyor mu, doğru içerik geliyor mu, yoksa yalnızca alan adı yanıt veriyor gibi mi görünüyor? Web sitesinin açılması, A veya CNAME çözümünün en azından belirli bir sorgulama noktasında çalıştığını gösterebilir; ancak bu durum e-posta kayıtlarının doğru olduğu anlamına gelmez.

2. NS sorgusuyla yetkili DNS yönetimini doğrulayın.

   Alan adının NS kayıtlarında görünen sunucular, DNS bölgesinin hangi yetkili sistem tarafından yönetildiğini gösterir. Kontrol ettiğiniz A, MX veya TXT kayıtlarının gerçekten bu yetkili DNS yönetiminde bulunması gerekir. Panelde yaptığınız değişiklik ile sorgulama sonucundaki yetkili sunucular farklı sistemleri gösteriyorsa, değişiklik yanlış yerde yapılmış olabilir.

3. Kök alan adının A veya CNAME çözümünü kontrol edin.

   Alan adının kök adı hangi hedefe çözülüyor, bunu inceleyin. Web erişiminin çalışıp çalışmadığını doğrulamak için bu kayıt önemlidir. Fakat A veya CNAME sonucunu e-posta alımının kanıtı olarak kullanmayın; web hedefi ile posta hedefi ayrı olabilir.

4. MX sorgusunda hedef ve öncelik değerlerini inceleyin.

   MX sonucunda alan adınız için posta sunucusu hedefleri görünmelidir. Her hedefin yanında bir öncelik değeri bulunabilir. Düşük sayı daha yüksek önceliği ifade eder. MX hedefinin kendisi ayrıca adres kaydına çözülmeli ve posta sunucusuna ulaşılabilir bir hedef göstermelidir.

5. TXT veya SPF kaydını gönderim açısından değerlendirin.

   TXT kayıtlarında SPF politikası bulunup bulunmadığını ve gönderim yapan sunucunun bu politikada yetkili olup olmadığını kontrol edin. Bu adım yalnızca giden e-posta doğrulamasıyla ilgilidir. MX kaydındaki bir hata, SPF kaydı doğru olsa bile gelen e-postaların yanlış yere yönelmesine neden olabilir.

6. Dışarıdan e-posta alımını ve alan adından e-posta gönderimini ayrı test edin.

   Önce dış bir adresten alan adınızdaki posta kutusuna mesaj gönderin. Daha sonra alan adınızdaki posta kutusundan dış bir adrese mesaj gönderin. Her test için gönderim saati, alıcı adres, hata mesajı, geri dönüş bildirimi ve mesajın spam klasörüne düşüp düşmediği gibi ayrıntıları not edin.

7. DNS önbelleği nedeniyle farklı sorgulama noktalarında farklı yanıt görülebileceğini hesaba katın.

   DNS değişikliklerinden sonra bazı sorgulama noktaları eski, bazıları ise yeni yanıtı gösterebilir. Bu durum tek başına kaydın kesin olarak doğru veya yanlış olduğunu kanıtlamaz. Yetkili DNS yanıtını, farklı ağlardan alınan sonuçlarla karşılaştırın; fakat yalnızca tek bir sorgulama sonucuna bakarak kesin yayılım garantisi vermeyin.

8. Yalnızca bulguya dayalı düzeltme uygulayın ve tekrar test edin.

   MX hatası görülüyorsa SPF metnini değiştirerek çözüm aramayın. SPF uyumsuzluğu görülüyorsa A kaydını rastgele değiştirmeyin. Önce tek bir problemi düzeltin, ardından hem DNS sorgusunu hem de ilgili e-posta testini tekrarlayın. Aynı anda çok sayıda kayıt değiştirmek, hangi değişikliğin sonucu etkilediğini izlemeyi zorlaştırır.

Çevrim içi DNS sorgusu nasıl yapılır?

Bir çevrim içi DNS sorgulama ekranında önce kayıt türünü seçin, ardından alan adını yazın ve dönen yetkili yanıtı karşılaştırın. NS, A, CNAME, MX ve TXT kayıtlarını ayrı ayrı sorgulayın. Sonuç ekranında özellikle şu alanları not edin:

• Sorgulanan kayıt türü
• Yanıt veren yetkili sunucu
• Kayıt hedefi
• MX için öncelik değeri
• TXT içinde SPF politikasının bulunup bulunmadığı
• Yanıtın hata, boş sonuç veya geçerli kayıt biçiminde dönüp dönmediği

Sorgulama ekranında görülen bir kaydı doğrudan değiştiremezsiniz; bu ekran yalnızca DNS’in dışarıdan nasıl göründüğünü anlamaya yarar. Düzeltme, NS kayıtlarının gösterdiği yetkili DNS yönetiminde yapılmalıdır. Çevrim içi araçların adı, arayüzü ve sunduğu özellikler değişebildiği için yayın öncesinde kullanılan aracın resmî bilgileri ayrıca doğrulanmalıdır.

Bulgudan nedene kontrol tablosu

Bu akışın amacı, “e-posta çalışmıyor” gibi geniş bir şikâyeti test edilebilir küçük belirtilere ayırmaktır. DNS ve programlama mantığını birlikte geliştirmek isteyenler, ücretsiz yazılım bilgisi testi üzerinden özellikle algoritmik düşünme ve hata ayıklama yaklaşımını da değerlendirebilir.

Kısa karar ağacı

NS beklenenden farklıysa: DNS yönetimini doğrula.

NS doğruysa: MX sorgula.

MX yok veya hatalıysa: Gelen e-posta yönlendirmesini düzelt.

MX doğruysa: Alım testi ve posta kutusu durumunu incele.

Alım çalışıyor, gönderim sorunluysa: SPF ve gönderim doğrulamasını incele.

Sık Sorulan Sorular

Web sitesi açıldığı hâlde e-posta almak neden mümkün olmayabilir?

Web sitesi genellikle A veya CNAME kaydıyla bir web sunucusuna yönlenir. E-posta alımı ise MX kayıtlarıyla posta sunucusuna yönlendirilir. Bu nedenle A veya CNAME doğru çalışırken MX kaydı eksik, hatalı, yanlış hedefe yönlenmiş veya hedef sunucu çözümlenemiyor olabilir. Alım sorunu için önce MX kaydı ve MX hedefinin adres çözümü incelenmelidir.

NS kayıtları doğru değilse MX kaydı neden etkisiz kalır?

NS kayıtları, alan adının yetkili DNS yönetimini gösterir. MX kaydı başka bir DNS panelinde düzenlenmiş olsa bile alan adının NS kayıtları farklı yetkili sunucuları gösteriyorsa dış dünyaya o değişiklik sunulmayabilir. Bu durumda panelde doğru görünen MX kaydı, sorgulama yapan e-posta sunucuları tarafından görülmeyebilir.

MX kaydı ile SPF kaydı arasındaki temel fark nedir?

MX kaydı, alan adına gelen e-postaların hangi posta sunucusuna teslim edileceğini belirler. SPF kaydı ise alan adı adına e-posta göndermeye yetkili sunucuları TXT kaydı içinde tanımlar. Kısaca MX alım yönlendirmesiyle, SPF gönderim doğrulamasıyla ilgilidir.

Birden fazla MX kaydı varsa öncelik değerleri nasıl değerlendirilir?

MX kayıtlarında düşük öncelik numarası daha öncelikli hedef anlamına gelir. Gönderen posta sunucusu önce daha düşük numaralı MX hedefini denemelidir. Aynı öncelik değerine sahip birden fazla hedef bulunabilir; bu durumda sistemler alternatif hedefler arasında seçim yapabilir. Bir MX kaydının listede bulunması, hedef sunucunun gerçekten çözümlendiği ve bağlantı kabul ettiği anlamına gelmez; hedefin adres kaydı ve erişilebilirliği de kontrol edilmelidir.

DNS değişikliğinden sonra bazı sorgulama noktalarında eski kayıtların görünmesi nasıl yorumlanmalıdır?

DNS yanıtları önbelleğe alınabildiği için değişiklikten sonra farklı sorgulama noktalarında bir süre farklı kayıtlar görülebilir. Bu sonuç, tek başına değişikliğin başarısız olduğunu veya her yerde tamamlandığını kanıtlamaz. Yetkili NS yanıtı, farklı ağlardan alınan sorgular ve gerçek e-posta testleri birlikte değerlendirilmelidir.

Doğru teşhis için web, MX ve SPF kontrollerini ayrı belirtiler olarak ele alın; her düzeltmeden sonra ilgili sorguyu ve e-posta testini yeniden çalıştırın.