DKIM Doğrulaması Başarısız: Nedenleri ve Çözümü

Bir müşterinize gönderdiğiniz mail Gmail'de "Spam" klasörüne düştü, siz de mesaj kaynağını açıp baktınız ve orada duruyor: dkim=fail. DKIM kaydını eklediğinizden eminsiniz, hatta hosting panelinde "DKIM aktif" yazıyor. Buna rağmen DKIM doğrulanmıyor ve her gönderdiğiniz mail ya spam'e düşüyor ya da tamamen reddediliyor. Bu yazının konusu tam olarak bu: kayıt varken neden fail dönüyor ve nereye bakılacak.

DKIM'in "nedir" tarafını anlatan Türkçe kaynak çok; ama işin kırıldığı yer teori değil, uygulama. Yıllardır gördüğüm başarısız DKIM vakalarının neredeyse tamamı beş sebepten birine dayanıyor: yanlış seçici (selector) adı, 2048 bit anahtarın DNS'te 255 karakter sınırına takılıp bölünmemesi, kaydı kopyalarken araya giren satır sonu ya da panelin kendiliğinden eklediği tırnak, panelde anahtar yeniden üretildiği hâlde DNS'te eski açık anahtarın kalması ve maili yolda değiştiren bir aracı (yönlendirme, liste sunucusu, antivirüs eki). Aşağıda bunların her birini gerçek komutlarla, gerçek çıktılarla ayırt etmenin yolunu bulacaksınız.

dkim=fail Ne Demek ve Bu Satır Nerede Görünür#

dkim=fail, alıcı sunucunun mesajın imzasını hesaplayıp DNS'teki açık anahtarla karşılaştırdığını ve tutmadığını söyler. Yani imza var, ama geçerli değil — kayıt hiç yok demek değildir; o durum ayrı bir sonuç döndürür.

Gmail'de bir maili açıp üç noktadan Orijinali göster dediğinizde en üstte şu satırı görürsünüz:

Authentication-Results: mx.google.com;
       dkim=fail [email protected] header.s=default header.b=hK9pLm2Q;
       spf=pass (google.com: domain of [email protected] designates 185.x.x.x as permitted sender)
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=example.com

Buradaki üç alan tanı için altın değerinde: header.i imzayı atan alan adı, header.s kullanılan seçici (selector) adı, header.b ise imzanın ilk baytları. Bu satırdan sonra mesajın kendi DKIM-Signature başlığı gelir:

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=example.com; s=default; h=Date:From:To:Subject:Message-ID;
	bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
	b=Yl3xQ0m...

d= imzalayan alan adı, s= seçici, bh= gövde özeti, b= asıl imza. Bu iki başlığı yan yana koyduğunuzda sorunun hangi katmanda olduğunu daha ilk bakışta daraltabilirsiniz. Sonuç değerlerinin anlamları şöyle:

Bu tablodaki son iki satırı birbirinden ayırmak, işin yarısını bitirir. body hash did not verify yazıyorsa anahtarlarınız doğrudur ve sorun taşıma katmanındadır; düz fail ise anahtar çifti uyuşmuyordur.

Seçici (Selector) Nedir ve Neden Yanlış Yerde Arıyorsunuz#

Seçici, aynı alan adı altında birden fazla DKIM anahtarı barındırabilmek için kullanılan etikettir ve DNS'te kaydın nereye yazılacağını belirler. Sorgulanan ad her zaman şu kalıptadır:

<seçici>._domainkey.<alanadı>

s=default ise bakılacak kayıt default._domainkey.example.com, s=mail202608 ise mail202608._domainkey.example.com olur. Türkçe kaynaklarda en çok atlanan nokta budur: DKIM kaydı alan adının köküne (@) yazılmaz, _domainkey alt alan adının altına yazılır.

Buradan doğan üç klasik hata:

1. Panelin alan adını iki kez eklemesi. cPanel Zone Editor veya bir kayıt firması panelinde ad alanına default._domainkey.example.com yazarsınız, panel de sonuna kendi alan adını ekler ve kayıt default._domainkey.example.com.example.com olarak oluşur. Panel zaten alan adını ekliyorsa ad alanına yalnızca default._domainkey yazın.
2. Alt çizgiyle başlayan adın reddedilmesi. Bazı kayıt firması panelleri _ ile başlayan etiketleri kabul etmez ya da sessizce kırpar. Bu durumda DNS yönetimini hosting tarafına taşımak en temiz çözümdür; DNS kayıtlarının hangi panelden değiştirileceği konusunu ayrıca ele alıyoruz.
3. Yanlış seçiciyi kontrol etmek. Sunucunuz s=cp veya tarih içeren bir seçiciyle imzalarken siz default kaydını kontrol edip "kayıt duruyor" diyorsunuz. Her zaman mailin kendi başlığındaki s= değerini esas alın, panelde yazanı değil.

Seçici doğrulaması tek satırlık bir iştir:

dig +short TXT default._domainkey.example.com

Boş dönüyorsa kayıt o adda yok demektir. Farklı bir çözümleyiciden de sorup karşılaştırın; ayrıntısı için dig ve nslookup ile DNS sorgulama yazısına bakabilirsiniz.

255 Karakter Sınırı: 2048 Bit Anahtar Neden DNS'e Sığmaz#

Bir TXT kaydındaki her metin parçası en fazla 255 karakter olabilir; 2048 bit RSA anahtarının base64 karşılığı bundan uzundur, bu yüzden kaydın birden fazla parçaya bölünüp tırnak içinde yan yana yazılması gerekir. Bu, Türkçe içeriklerde neredeyse hiç anlatılmayan ama en çok kayba yol açan detaydır.

1024 bit anahtarın p= değeri kabaca 216 karakterdir ve tek parçaya sığar. 2048 bit anahtarın p= değeri ise 390 karakteri geçer; toplam kayıt 400 karakteri bulur. Ham bir zone dosyasında doğru yazım şudur:

default._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; "
  "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvR7kQ2m8pT1sYbN4dLwXcH"
  "u3fZ9aK0oMqVjE5rP6tGxIyBnCwSlD8eHkR2vAtJmZq1Xy4NbOcPfUgLhTdW0iKrEsMy"
  "AoQIDAQAB" )

Buradaki parantez ve tırnaklar sözdizimidir; çözümleyici bu parçaları birleştirip tek bir dize olarak okur. Panel arayüzlerinde ise kural farklıdır ve karıştırıldığı yer tam da burasıdır:

• cPanel Zone Editor, DirectAdmin ve çoğu barındırma paneli değeri tek kutuya yapıştırmanızı bekler ve bölmeyi kendisi yapar. Buraya elinizle tırnak eklerseniz tırnaklar değerin parçası olur ve kayıt bozulur.
• Bazı kayıt firması panelleri bölmeyi yapmaz ve 255 karakterden sonrasını sessizce kırpar. Bunu anlamanın yolu kaydı yazdıktan sonra geri okumaktır.

Kırpılmayı tespit eden pratik kontrol:

dig +short TXT default._domainkey.example.com | tr -d '" ' | wc -c

2048 bit bir anahtar için bu sayı 400'ün üzerinde olmalı. 260 civarında bir sonuç görüyorsanız kaydınız kırpılmıştır — anahtarı 1024 bit'e düşürmek geçici bir çare olsa da doğru çözüm, DNS'i düzgün bölme yapan bir panele taşımaktır.

Kopyalarken İmzayı Kıran Görünmez Karakterler#

DKIM kayıtlarının bozulmasının en sinsi nedeni, anahtarın kendisi değil kopyalanma biçimidir. Panelin gösterdiği anahtarı fare ile seçip yapıştırdığınızda değere sızan şeyler şunlardır:

• Satır sonu. Panel anahtarı ekrana sığdırmak için birkaç satıra bölerek gösterir. Kopyalayınca o satır sonları da gelir ve bazı DNS panelleri bunları kabul edip kaydı iki ayrı parçaya bölünmüş gibi saklar; ortaya geçersiz bir kayıt çıkar.
• Panelin kendi eklediği tırnaklar. Değeri "v=DKIM1; k=rsa; p=..." şeklinde tırnakla kopyalayıp tırnak ekleyen bir panele yapıştırırsanız kayıt ""v=DKIM1..." olur.
• Metin editörünün akıllı tırnağı. Anahtarı bir belgeye kaydedip oradan alırsanız düz tırnak eğik tırnağa dönüşmüş olabilir.
• Baştaki/sondaki boşluk. Çoğu panel bunu kırpar, hepsi kırpmaz.
• p= önekinin iki kez yazılması. Panel size yalnızca anahtar gövdesini verir, siz de başına v=DKIM1; k=rsa; p= eklersiniz; oysa panel bunu zaten vermiştir. Sonuç: p=v=DKIM1; k=rsa; p=MIIB...

Bunların hepsini tek hamlede eleyen yöntem şudur: kaydı yazdıktan sonra panele değil DNS'e sorun ve gelen değeri gözle karşılaştırın.

dig +short TXT default._domainkey.example.com | sed 's/" "//g'

Çıktı tek satır hâlinde v=DKIM1; k=rsa; p=MIIBIjAN...AQAB şeklinde okunabiliyorsa kaydınız temizdir. Arada \010, \013 gibi kaçış dizileri ya da ikinci bir v=DKIM1 görüyorsanız kaydı silip yeniden yazın. TXT kaydının genel davranışı için TXT kaydı nedir yazısı iyi bir temel sunar.

Anahtar Çifti Uyuşmuyor: En Sık Görülen Gerçek Sebep#

Düz dkim=fail alıyorsanız ve gövde yolda değişmiyorsa, sunucudaki özel anahtar ile DNS'te yayınlanan açık anahtar aynı çiftin parçası değildir. Bu, panelde "DKIM'i yeniden oluştur" düğmesine basıldığında ya da hesap başka bir sunucuya taşındığında olur: sunucu yeni bir anahtar üretir, DNS'te ise eski açık anahtar durur.

Kendi sunucunuz varsa eşleşmeyi doğrudan doğrulayabilirsiniz. Özel anahtardan açık anahtarı türetip DNS'tekiyle karşılaştırın:

openssl rsa -in /etc/opendkim/keys/example.com/default.private -pubout -outform PEM \
  | grep -v '^-----' | tr -d '\n'

Çıkan uzun base64 dizesi, DNS kaydınızdaki p= değerinin birebir aynısı olmalıdır. Bir karakter bile farklıysa DNS'i sunucudaki anahtara göre güncelleyin.

OpenDKIM kullanan bir sistemde aynı kontrolü tek komutla da yapabilirsiniz:

opendkim-testkey -d example.com -s default -vvv

Beklenen çıktı key OK satırıdır. key not secure uyarısı DNSSEC ile ilgilidir ve doğrulamayı engellemez; key retrieval failed ise kaydın bulunamadığını, keys do not match ise tam olarak yukarıda anlattığımız uyuşmazlığı söyler.

Paylaşımlı hosting kullanıyorsanız bu kontrolü panelden yaparsınız: cPanel'de E-posta → E-posta Teslimatı (Email Deliverability) ekranı, alan adının yanında DKIM için "Sorunlu" uyarısı gösterir ve Onar düğmesi sunucudaki anahtara uygun kaydı önerir. Önerdiği değeri DNS'e olduğu gibi yazmak, elle uğraşmaktan hem hızlı hem güvenlidir.

İmza Doğru Ama Gövde Değişmiş: Yönlendirme ve Liste Tuzağı#

body hash did not verify mesajı, imzanın atıldığı andan sonra mesaj gövdesinin değiştiğini söyler; anahtarlarınızda hiçbir sorun yoktur. Bu, özellikle mailin bir yerden başka bir yere iletildiği senaryolarda kaçınılmazdır.

Gövdeyi bozan tipik durumlar:

• Otomatik iletme. [email protected] adresine gelen maili kişisel bir adrese ilettiğinizde, aradaki sunucu gövdeye "Yönlendirilen mesaj" bloğu veya bir alt bilgi eklerse özgün imza kırılır. Bu, gönderenin hatası değildir.
• Liste sunucuları. Konu başlığına [Liste] öneki ekleyen ya da mesajın sonuna abonelikten çıkma bağlantısı iliştiren her sistem imzayı bozar. h= etiketinde Subject varsa konu değişikliği de yeterlidir.
• Antivirüs/tarama etiketi. Bazı ağ geçitleri gövdenin sonuna "Bu mesaj taranmıştır" satırı ekler.
• Satır sonu dönüşümü. Katı (simple) kanonikleştirme kullanan bir imzada sondaki boş satırın eklenmesi/çıkarılması bile hash'i değiştirir. Bu yüzden imzalama tarafında c=relaxed/relaxed kullanmak, c=simple/simple'a göre çok daha dayanıklıdır.

Yapabileceğiniz somut şeyler şunlar: imzalama ayarında kanonikleştirmeyi relaxed/relaxed yapın; h= listesini gereğinden uzun tutmayın (özellikle Content-Type ve Message-ID dışında oynayan başlıkları koymayın); gövde uzunluğu etiketi l= kullanmayın — imzanın yalnızca ilk N baytı kapsaması, mesajın sonuna içerik eklenmesine kapı açar ve güvenlik açısından tavsiye edilmez.

En önemlisi de şudur: yönlendirmeden kaynaklanan body hash hatası DMARC'ta sizi kurtaracak olan şey SPF değil, doğru bir DMARC politikasıdır. Üçlünün birlikte nasıl çalıştığını SPF, DKIM ve DMARC yazısında ayrıntısıyla anlatıyoruz.

Kayıt Doğru Ama Yayılmamış: Zamanlama ve Önbellek#

Kaydı doğru yazdığınız hâlde temperror ya da "kayıt bulunamadı" alıyorsanız, sorun içerikte değil yayılmada olabilir. DKIM kaydı da diğer DNS kayıtları gibi TTL süresince önbellekte tutulur.

Sırasıyla şunları kontrol edin:

1. Yetkili sunucudan sorun. Ara çözümleyicileri atlayıp doğrudan alan adının nameserver'ına sorun:

   dig TXT default._domainkey.example.com @ns1.example-dns.com +short
   

   Burada kayıt görünüyor ama genel çözümleyicilerde görünmüyorsa mesele yalnızca zamandır.
2. TTL'e bakın. Eski (boş) yanıt uzun TTL ile önbelleğe alındıysa o süre dolmadan güncel yanıt gelmez. Kayıt eklemeden önce TTL'i düşürmek iyi bir alışkanlıktır.
3. Birden fazla noktadan kontrol edin. DNS propagasyon kontrol araçları ile farklı bölgelerde aynı yanıtın dönüp dönmediğini görebilirsiniz.
4. NXDOMAIN mı NODATA mı ayırın. Sorgu status: NXDOMAIN dönüyorsa o ad hiç yok; status: NOERROR fakat yanıt boşsa ad var ama TXT kaydı yok. İkisinin çözümü farklıdır ve DNS_PROBE_FINISHED_NXDOMAIN hatası yazısındaki mantık burada da geçerlidir.

Genel kural: kayıt yetkili sunucuda göründükten sonra beklemek dışında yapılacak bir şey yoktur; kayıt yetkili sunucuda görünmüyorsa beklemek hiçbir şeyi çözmez.

Üçüncü Taraf Servisler ve Birden Fazla Anahtar Yönetimi#

Alan adınız adına mail gönderen her sistemin kendi DKIM anahtarı olmalıdır ve bu tamamen normaldir. Bir alan adı altında istediğiniz kadar seçici barındırabilirsiniz; bu yüzden anahtarları birbirinin üzerine yazmaya çalışmayın.

Tipik bir kurulumda alan adı altında şu kayıtlar birlikte yaşar:

Bir sistemin maili doğrulanırken diğerininki fail dönüyorsa, hangi sistemin gönderdiğini s= etiketinden anlar ve yalnızca o seçicinin kaydını düzeltirsiniz. Anahtar döndürme (rotation) yaparken de eski seçiciyi hemen silmeyin: yolda olan mesajlar doğrulanamaz hâle gelir. Yeni seçiciyi yayınlayın, imzalamayı yeni seçiciye alın, birkaç gün sonra eskiyi kaldırın.

Kendi sunucunuzdan yüksek hacimli gönderim yapıyorsanız DKIM'in yanında PTR (ters DNS) kaydının da doğru olması gerekir; bu ikisi eksikken teslimat sorunlarının kaynağını yalnızca DKIM'de aramak zaman kaybıdır.

Adım Adım Tanı Akışı#

Bir vakaya sıfırdan başlıyorsanız izlenecek sıra şudur:

1. Sorunlu mailin kaynağını açın, Authentication-Results satırındaki sonucu ve header.s değerini not edin.
2. dig +short TXT <seçici>._domainkey.<alanadı> çalıştırın. Boşsa kayıt yok ya da yanlış adda.
3. Dönen değeri gözle okuyun: tek bir v=DKIM1 var mı, p= bir kez mi geçiyor, sonda kesilme var mı.
4. Karakter sayısını ölçün; 2048 bit için 400'ün altındaysa kırpılma vardır.
5. Sunucudaki özel anahtardan açık anahtarı türetip DNS'tekiyle karşılaştırın.
6. Sonuç body hash did not verify ise anahtarları bırakın, yolu inceleyin: iletme, liste, tarama eki.
7. Düzeltmeden sonra kendinize değil, dışarıdaki bir hesaba test maili atın ve yeni mailin başlığını okuyun. Eski maildeki sonuç güncellenmez.

Bu akışta atlanan en yaygın adım altıncısıdır: insanlar fail görünce refleksle anahtarı yeniden üretir, oysa gövde değişikliğinde yeni anahtar hiçbir şeyi değiştirmez.

Sıkça Sorulan Sorular#

DKIM kaydı ekledim ama hâlâ fail dönüyor ne yapmalıyım#

Önce mailin başlığındaki s= değerine bakıp doğru seçiciyi sorguladığınızdan emin olun; çok sık yapılan hata, sunucu başka bir seçiciyle imzalarken default kaydını kontrol etmektir. Ardından dig +short TXT <seçici>._domainkey.<alanadı> çıktısını gözle okuyun ve kaydın kesilmediğini, içinde ikinci bir v=DKIM1 olmadığını doğrulayın. Bunlar tamamsa sunucudaki özel anahtarla DNS'teki açık anahtarın aynı çiftten olduğunu kontrol edin. Panelde "DKIM'i yeniden oluştur" denmişse anahtar değişmiş ama DNS güncellenmemiş olabilir.

DKIM selector nedir ve hangi ismi vermeliyim#

Selector, aynı alan adı altında birden fazla DKIM anahtarı tutabilmek için kullanılan etikettir ve kaydın DNS'te nereye yazılacağını belirler. İsim tamamen size kalmıştır; harf ve rakamdan oluşan kısa bir değer yeterlidir. Pratikte default, mail ya da tarih içeren mail202608 gibi adlar tercih edilir. Anahtar döndürmeyi kolaylaştırdığı için tarih içeren adlar daha kullanışlıdır; yeni anahtarı yeni seçiciyle yayınlar, geçiş bitince eskisini silersiniz.

2048 bit DKIM anahtarı DNS'e sığmıyor ne yapabilirim#

Bir TXT kaydındaki her metin parçası en fazla 255 karakter olabildiği için 2048 bit anahtarın birden fazla parçaya bölünüp birleştirilecek şekilde yazılması gerekir. cPanel gibi paneller bu bölmeyi kendiliğinden yapar, siz değeri tek kutuya olduğu gibi yapıştırırsınız. Panel bölme yapmıyor ve değeri kırpıyorsa kaydı yazdıktan sonra dig ile geri okuyup uzunluğunu ölçün. Kalıcı çözüm, DNS yönetimini bölmeyi doğru yapan bir panele almaktır; anahtarı 1024 bit'e düşürmek yalnızca geçici bir çıkış yoludur.

DKIM kaydını değiştirdikten sonra ne kadar beklemeliyim#

Yetkili sunucuda kayıt göründükten sonra genellikle birkaç dakika ile birkaç saat arasında her yerde geçerli olur; süreyi belirleyen, eski yanıtın hangi TTL ile önbelleğe alındığıdır. Kaydı değiştirmeden önce TTL değerini düşürürseniz geçiş çok daha hızlı olur. Beklerken kontrolü doğrudan alan adının nameserver'ına sorarak yapın; orada güncel değeri görüyorsanız yapacak başka bir şey yoktur. Testi mutlaka yeni gönderilen bir mailin başlığı üzerinden yapın, eski maillerin doğrulama sonucu güncellenmez.

DKIM olmadan mail gönderebilir miyim#

Teknik olarak gönderebilirsiniz ama büyük posta sağlayıcılarının kuralları sıkılaştığı için pratikte teslimat oranınız ciddi biçimde düşer. Kimliği doğrulanmamış mesajlar ya doğrudan spam klasörüne düşer ya da hacim belirli bir eşiği geçtiğinde reddedilir. Özellikle sipariş onayı, şifre sıfırlama gibi işlem maillerinde bu kayıp doğrudan iş kaybına dönüşür. DKIM'i SPF ve DMARC ile birlikte kurmak bugün artık isteğe bağlı bir iyileştirme değil, temel bir gerekliliktir.

DKIM ve DMARC arasındaki fark nedir#

DKIM mesajın imzalanıp yolda değiştirilmediğini kanıtlar; DMARC ise bu doğrulamanın sonucuna göre ne yapılacağını söyleyen politikadır. DMARC ayrıca hizalama (alignment) şartı koyar: DKIM imzasındaki d= alan adının, mesajın görünen From adresiyle uyuşması gerekir. Bu yüzden DKIM pass dönerken DMARC fail dönebilir — imza geçerlidir ama başka bir alan adına aittir. Üçlünün birlikte nasıl kurulacağı ayrı bir konudur ve mutlaka birlikte planlanmalıdır.

Yönlendirdiğim mailler neden DKIM hatası veriyor#

Çünkü yönlendirme sırasında aradaki sunucu mesaja bir şey ekliyor ve gövdenin özeti değişiyor; imza da gövdenin o anki hâli üzerine hesaplandığı için tutmuyor. Bu durumda başlıkta genellikle body hash did not verify ifadesi görünür ve anahtarlarınızda hiçbir sorun yoktur. Kanonikleştirmeyi relaxed/relaxed yapmak bazı küçük değişikliklere karşı dayanıklılık kazandırır ama alt bilgi eklenmesini kurtarmaz. Yönlendirme yerine posta kutusunu doğrudan hedef sistemde açmak ya da IMAP ile çekmek daha sağlıklı bir çözümdür.

DKIM anahtarımı ne sıklıkla değiştirmeliyim#

Yılda bir kez ya da anahtarın sızdığından şüphelendiğiniz her durumda değiştirmek makul bir yaklaşımdır. Değiştirirken eski seçiciyi hemen silmeyin: yeni seçiciyi yayınlayın, imzalamayı ona alın ve yolda olan mesajların doğrulanabilmesi için eski kaydı birkaç gün daha bırakın. Sunucu taşındığında ya da panelde anahtar yeniden üretildiğinde de bu bir anahtar değişimidir; DNS kaydını güncellemeyi unutmak, bu yazıdaki fail vakalarının en yaygın sebebidir.

Kapanış#

DKIM doğrulanmıyorsa cevap neredeyse her zaman dört yerden birindedir: yanlış seçici adı, kırpılmış ya da bozulmuş TXT kaydı, sunucudaki özel anahtarla yayınlanan açık anahtarın uyuşmaması, ya da mesajın yolda değişmesi. Bu dördünü ayırt etmenin yolu tahmin yürütmek değil, mailin kendi başlığındaki s= ve sonuç ifadesini okuyup ardından dig ile DNS'e sormaktır. body hash did not verify gördüğünüzde anahtara dokunmayın, yolu inceleyin; düz fail gördüğünüzde ise anahtar çiftini karşılaştırın. Bu iki refleks, saatler süren denemeleri birkaç dakikaya indirir.

Kimlik doğrulama kayıtlarını kendiniz yönetmek istemiyor ya da gönderim hacminiz paylaşımlı bir ortamı zorluyorsa, işi doğru kurgulanmış bir altyapıya devretmek en sağlıklısı. Kurumsal posta kutularınızı ve DNS kayıtlarınızı tek yerden yönetmek için kurumsal e-posta çözümlerimize, yüksek hacimli işlem ve bülten gönderimi için DKIM, SPF ve PTR kayıtları hazır teslim edilen SMTP sunucu paketlerine, sitenizin barındırmasıyla posta kutularınızı aynı panelde toplamak için kurumsal hosting paketlerine göz atabilirsiniz. DNS kayıtlarını kendi alan adınız üzerinde düzenlemek istiyorsanız alan adı yönetim sayfamız bunun için yeterli araçları sunar.