E-posta Aracı Değiştirdikten Sonra DKIM Bozuldu: CNAME ve Seçici Geçiş Rehberi (2026)

Yayımlanma 2026-07-08

Veriler 2026-06-29 itibarıyla · metodoloji v7. 261 milyon derecelendirilmiş alan genelinde toplu sayım verileri. Bkz. nasıl derecelendiriyoruz.

DKIM, araç değişikliğinden sonra iki mekanik nedenle bozulur: DNS paneliniz yeni aracın CNAME hedeflerini bozdu — genellikle kendi bölgenizi ekleyerek — ya da eski aracın seçicileri postası tükenmeden silindi. Defaults.Exposed’un 261,086,232 derecelendirilmiş alan sayımına göre yalnızca 3.87% oranındaki alan — 10,092,481 — SPF+DKIM+DMARC üçlüsünü tamamlar.

Düzeltme sırası: alanı tarayın, ardından her yeni CNAME’in dig ile saklanan hedefini kontrol edin — kendi alan adınızla biten bir hedef açık kanıttır. Yetkili ad sunucularında kayıtları düzeltin, yeni aracın gerçek postayı yönlendirmeden önce imzaladığını ve geçtiğini doğrulayın, eski aracın seçicilerini trafiği tükenene kadar yayımlanmış tutun.

Araç değiştirince DKIM neden bozuldu?

DKIM’in kendisinde hiçbir şey değişmedi — seçicileriniz değişti. Eski araç kendi seçicileriyle imzalıyordu; yeni araç, ekleme sırasında genellikle iki veya üç CNAME kaydı aracılığıyla yetkilendirilen farklı seçicilerle imzalar. Dört tuzak, geçiş sonrası neredeyse her DKIM hatasını açıklar:

DNS paneliniz CNAME hedefine kendi bölgenizi ekledi. Pek çok panel, yapıştırılan herhangi bir ana bilgisayar adını göreli olarak değerlendirir ve target.provider.com yerine target.provider.com.yourdomain.com olarak sessizce saklar. Kayıt mevcuttur, panel yeşil bir tik gösterir ve hiçbir şeye çözümlenmez.
Sondaki nokta karışıklığı. Bazı paneller sondaki nokta gerektirir (target.provider.com.) yani “mutlak — bölgemi ekleme”; diğerleri noktayı geçersiz olarak reddeder ve mutlaklığı kendileri yönetir. Aynı yapıştırılan değer bir panelde doğrudur, diğerinde bozulur.
Eski aracın seçicileri geçiş günü silindi. Eski aracın zaten imzaladığı postalar günlerce yeniden deneme kuyruklarında ve yönlendirme yollarında bekler; seçicilerini kaldırmak — veya delegasyonlu CNAME’lerini öldüren eski hesabı kapatmak — bu postaları geriye dönük olarak bozar.
Yanlış ad sunucularında doğrulama yaptınız. Geçiş bir ad sunucusu değişikliğini de kapsıyorsa, düzeltilmiş kayıtlar bir NS kümesinde bulunurken alıcılar hâlâ diğerini sorgulayabilir.

Sayımdaki 261 milyon alanın yalnızca 51.84%‘si tarama anında keşfedilebilir bir DKIM anahtarı sunar (veriler 2026-06-29 itibarıyla).

Aynı geçiş genellikle SPF kalıntıları da bırakır — SPF denenmeye çalışan alanların yaklaşık 1/138‘si olan 1,013,416 alan iki v=spf1 kaydı çalıştırır; bu, sağlayıcı geçişinin birleştirme yerine kayıt eklediğinin klasik işaretidir. Bu tarafın kendi rehberi vardır: E-posta sağlayıcısı değiştirdikten sonra SPF durdu.

Bozulmuş bir CNAME kaydını nasıl tespit ederim?

Panele güvenmeyin — DNS’e gerçekte ne sakladığını sorun. Yeni aracın size verdiği her seçici için CNAME hedefini sorgulayın. SendGrid tarzı yetkilendirilmiş seçiciyi taklit eden açıklayıcı bir örnek (sağlayıcınızın hedef şekli farklı olacaktır):

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.yourdomain.com.

Sağlayıcı s1.domainkey.u1234567.wl123.sendgrid.net istedi — ancak saklanan hedef .yourdomain.com ile bitiyor. Panel bölgeyi ekledi; bu ad hiçbir şeye çözümlenmez, dolayısıyla alıcılar anahtar bulamaz. Sağlıklı versiyon:

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.

(dig çıktısındaki tek sondaki nokta normaldir — tam nitelikli bir adı belirtir.) Hedef doğruysa bir adım ileri gidin: dig TXT s1._domainkey.yourdomain.com +short sağlayıcının anahtarını döndürmelidir. Doğru CNAME ile boş yanıt, sorunun yetkilendirmenin sağlayıcı tarafında olduğu anlamına gelir — doğrulama adımlarını tamamlayın veya seçici düzeyinde tanı için DKIM “no key for signature” sayfasına bakın.

Geçiş koşu kitabı: önce, sırasında, sonra

Hata genellikle kayıtlarda değil — sırada. DKIM geçişleri kesintide yanlış gider çünkü doğrulama, gerçek postalar zaten başarısız olurken geçişten sonra gerçekleşir.

Aşama	Ne yapmalı	Devam etmeden önce geçilmesi gereken kapı
Geçişten önce	Yeni aracın DKIM CNAME”lerini (ve geri dönüş alanı kayıtlarını) ekleyin, ardından kanıtlayın: ağınız dışından her CNAME”in saklanan hedefini `dig` ile kontrol edin, aracın kendi doğrulama adımını tamamlayın ve denetlediğiniz bir posta kutusuna yeni araç üzerinden test gönderin	Test iletisi, `d=` değeriniz alanınıza eşit olan `dkim=pass` gösterir — gerçek postayı doğrulanmamış bir araçtan asla geçirmeyin
Geçiş günü	Gerçek trafiği yeni araca taşıyın. Eski araca ait hiçbir şeye dokunmayın: seçicilerini, CNAME’lerini ve hesabını canlı bırakın	Yeni aracın postası gerçek alıcılarda geçiyor; eski araç üzerinden akan her şey için geçmeye devam ediyor
Tükenme sonrası	Eski aracın seçicileri görünmeyi bırakana kadar DMARC toplu raporlarını izleyin (yeniden deneme kuyrukları ve yönlendirmeler günlerce çalışır — bir hafta veya daha fazla bekleyin), ardından kayıtlarını ve hesabını kasıtlı olarak kapatın	Eski seçiciler ≥ 7 günlük raporlarda yoksa kaldırılabilir

Kalın satır, geçişlerin kurtarıldığı ya da kaybedildiği yerdir: içindeki her kontrol, canlı postaya sıfır risk olmadan geçişten günler önce yapılabilir. Seçici emeklilik mekanikleri — boş p= ile yeniden yayımlamanın neden silinmekten daha iyi olduğu da dahil — rotasyon koşu kitabında ele alınmıştır; bu tablo araç geçişinin sırasını düzenlemekle ilgilidir.

Geçişten sonra DKIM’i nasıl düzeltirim?

DNS’e dokunmadan önce defaults.exposed üzerinden ücretsiz taramayı çalıştırın. Canlı kayıtlarınızı okur ve alıcıların gerçekte neyi gördüğünü gösterir — bölge eklenmiş CNAME hedefleri ve çözümlenmeyen seçiciler dahil.
Yeni aracın beklediği DKIM kayıtlarını listeleyin. Yönetici konsolundan — posta kutusu sağlayıcıları için Google Workspace ve Microsoft 365 kurulum rehberleri nerede olduğunu gösterir; bülten ve CRM araçları CNAME’lerini alan kimlik doğrulaması altında listeler (bkz. Mailchimp/Brevo/Klaviyo e-postaları DMARC’ta başarısız oldu).
Her kaydın saklanan değerini dig CNAME <ad> +short ile kontrol edin ve aracın istediğiyle karakter karakter karşılaştırın. Kendi alanınızla biten bir hedef = bölge eklenmiş; yeniden girin ve panel eklemeye devam ederse sondaki noktayı ekleyin (veya panel noktaları reddediyorsa kaldırın).
Yetkili ad sunucularında doğrulayın. dig +short NS yourdomain.com, ardından CNAME kontrollerini @<o ad sunucusu> ile tekrarlayın. Geçiş ad sunucularını değiştirdiyse her iki kümeyi de kontrol edin — alıcılar yetkilendirme yayılana kadar hâlâ eskisini sorgulayabilir.
Aracın doğrulamasını yeniden çalıştırın ve test iletisi gönderin. Authentication-Results başlığı, d= değeri alanınıza eşit olan dkim=pass göstermelidir — aracın varsayılan alanında geçiş, DMARC için hizalanmaz.
Eski aracın seçicilerini postası tükenene kadar yayımlanmış bırakın, ardından kasıtlı olarak kaldırın. Ardından yeniden tarayın ve DKIM düzeltme sayfasında işaretlenen diğer konuları ele alın.

Sık sorulan sorular

DKIM CNAME’imde sondaki noktaya ihtiyacım var mı yok mu? Bu tamamen panele bağlıdır. Nokta “mutlak ad — bölgemi ekleme” anlamına gelir; bazı paneller gerektirir, bazıları kendiliklerinden ekler, bazıları reddeder. Önemli olan tek test, kayıt ettikten sonra dig CNAME <seçici>._domainkey.yourdomain.com +short çıktısıdır: hedef kendi alanınızla bitiyorsa panel bölgeyi eklemiş ve noktaya ihtiyaç duyuyorsunuzdur (ya da farklı bir giriş biçimine).

Geçiş günü eski aracın DKIM kayıtlarını silebilir miyim? Hayır. Eski aracın imzaladığı postalar hâlâ yeniden deneme kuyruklarında ve yönlendirme yollarındadır; işaret ettiği anahtarı silmek bu iletileri geriye dönük olarak bozar. Eski seçicileri, DMARC toplu raporlarında görünmeyi bırakana kadar — bir hafta veya daha uzun — canlı tutun ve o zamana kadar eski hesabı kapatmayın.

DNS panom ve yeni araç her ikisi de “doğrulandı” diyor ama alıcılar hâlâ DKIM’de başarısız oluyor. Neden? İki yaygın durum: araç, yetkili ad sunucuları farklı bir şey sunarken önbelleğe alınmış bir kontrole karşı doğrulamış (doğrudan dig @<ns> ile sorgulayın), ya da DKIM geçiyor ama kendi alanınız yerine aracın varsayılan imzalama alanında; dolayısıyla DMARC hâlâ hizalama başarısızlığıyla karşılaşıyor. Tarama ikisini ayırt eder.

Örtüşme sırasında her iki aracın DKIM kayıtları bir arada var olabilir mi? Evet — ve olmalı. DKIM’in tek kayıt kuralı yoktur: her seçici kendi DNS adıdır, dolayısıyla her iki aracın kayıtları çakışma olmaksızın yan yana yaşar; bu da eski seçicileri tükenmeye kadar tutma kuralını uygulamayı ücretsiz kılar. (SPF bunun tersidir — iki v=spf1 kaydı onu geçersiz kılar; bu nedenle SPF geçiş rehberi birleştirmekle ilgilidir.)

Sahiplerine raporu gönderin

Bu geçişi bir müşteri veya işvereniniz için yürütüyorsanız, kanıtla kapatın. Yeni araç imzaladıktan ve hizaladıktan sonra ücretsiz taramayı yeniden çalıştırın ve derecelendirilmiş raporu iş sahibine iletin: tarihli, sade dilli, geçişin alanı tam kimlik doğrulamayla bıraktığının kanıtı. Bu, siber sigorta yenileme ve bir sonraki tedarikçi güvenlik anketi için ihtiyaç duyacakları belgedir — “geçiş tamamlandı”yı bir iddiadan belgeye dönüştürür.

DKIM’inizi ücretsiz kontrol edin

Yeni aracın seçicilerinin çözümlenip çözümlenmediğini — ve tam olarak neyin düzeltileceğini — gizli ve yalnızca sahip olarak görün.

Alanınızı kontrol edin → · Sağlayıcı değiştirdikten sonra SPF bozuldu → · DKIM’i düzelt → · Google Workspace’te DKIM kurulumu → · Yalnızca toplu veriler. Veriler AB’de depolanır ve işlenir.