[ DKIM ]

Aktarım halindeki postalar için doğrulamayı kaybetmeden DKIM anahtarlarını dönüşümlü kullanın

Yeni anahtar yayınını, imza geçişini, örtüşmeyi ve kullanımdan kaldırmayı ayırın ve alınan gerçek mesajların ne kullandığını doğrulayın.

EmailAuth araştırma ekibi tarafından · 5 dakikalık okuma

[ Anahtar noktalar ]

  • İmzalayanı değiştirmeden önce yeni doğrulama materyalini yayınlayın.
  • Gerekçeli bir geçiş dönemi boyunca eski ve yeni seçicileri kullanılabilir durumda tutun.
  • Uzlaşma tepkisini rutin rotasyondan ayrı olarak ele alın.
Bu sayfada

Planlanmış bir DKIM rotasyon, halihazırda aktarılmakta olan iletiler için gereken doğrulama materyalini korurken, yeni postayı hangi özel anahtarın imzaladığını değiştirir. Yeni bir genel anahtar yayınlama, imzalayanı değiştirme ve eskisini kullanımdan kaldırma seçici ayrı aşamalardır.

İmzalama hizmeti ve desteklenen rotasyon prosedürüyle başlayın. Sağlayıcı tarafından yönetilen seçici delegasyon, doğrudan kuruluşunuz tarafından kontrol edilen anahtar çiftinden farklı bir işletim modeline sahiptir.

Geçerli imzalama durumunu oluşturma

Gerçek d= imzalama alanlarını ve s= seçicilerini tanımlamak için orijinal alınan mesajları kullanın. Bunları imzalama hizmeti, anahtar yönetimi modeli ve işletme sahibiyle ilişkilendirin.

Mevcut mesajlar tarafından kullanılmadan bir DNS kaydı mevcut olabilir. Bunun tersine, eski bir mesaj, artık yeni posta için etkin seçim olmayan bir seçiciye atıfta bulunabilir.

İlgili genel yanıtları ve yapılandırma durumunu kaydedin. Özel imzalama anahtarlarını bilette, envanter e-tablosunda veya genel DNS kaydında değil, yetkili imzalama sisteminde tutun.

Algoritmayı ve sağlayıcı gereksinimlerini onaylayın

Mevcut şifreleme kılavuzunu ve desteklenen doğrulama davranışını inceleyin. RFC 8301 §3 rsa-sha1'i hariç tutar ve RSA anahtar boyutu gereksinimlerini belirler; en az 2048 bitlik RSA anahtarlarını önerir. RFC 8463 §5 Ed25519-SHA256'yı ek bir yöntem olarak tanımlar.

Bir algoritmanın spesifikasyonu ve ilgili göndericilerin, sağlayıcıların ve alıcıların gerçek desteği farklı kanıtlardır. Bir üretim hizmetini, desteklenen yapılandırmasının kullanamayacağı bir yöntemle değiştirmeyin.

Sağlayıcı tarafından yönetilen imzalama için oluşturulan değerleri ve rotasyon sürecini izleyin. Bir DNS takma adı, ekibinize özel anahtarı veya manuel geçiş kontrolünü vermeden anahtar yönetimini devredebilir.

Geçişten önce yeni doğrulama materyalini yayınlayın

Desteklenen tasarımın yeni bir seçici kullanması durumunda, önce doğru genel doğrulama materyalini yayınlayın. Nihai sahibin adını, yanıtını ve varsa yetkilendirme zincirini onaylayın.

Desteklenen prosedürün izin verdiği durumlarda yeni bir anahtar için farklı bir seçici kullanın. Bir seçicinin altındaki anahtarın değiştirilmesi, eski anahtarla imzalanan mesajların değiştirilmeye karşı doğrulanamamasına neden olabilir.

Yeni DNS yanıtı doğru göründüğü için eski anahtarı kaldırmayın. Bu aşamada, imzalayanın değişmesi veya her alıcının amaçlanan materyali alabilmesi için yayını kurdunuz.

İmzalamayı değiştirin ve yeni mesajları doğrulayın

Yeni anahtarla imzalamaya başlamak için yetkili imzalama prosedürünü kullanın. Önemli rotalar üzerinden temsili mesajlar gönderin ve orijinal alınan imzaları ve güvenilir sonuçları inceleyin.

Sentetik rotasyonda, önceki postalar s=old2026 , yeni postalar ise s=new2026. Her iki genel doğrulama adı da planlanan çakışma sırasında kullanılabilir durumda kalırken, yeni alınan mesajlar amaçlanan seçiciyi ve geçen imzayı gösterir.

Bir ağ geçidi imzalamadan sonra mesajı değiştirirse, bu ağ geçidinden önce yapılan doğrudan test eksik olur. İş rotasının tamamını kontrol edin ve DMARC hizalama ham imza sonucunun yanı sıra.

Teslimat koşullarından emekliliği seçin

RFC 6376 §3.1 Postanın hala transit halinde olabileceği geçiş sırasındaki eşzamanlı yayını açıklar. Her kuruluş için tek bir evrensel örtüşme süresi sağlamaz.

Kuyrukları, yeniden deneme davranışını, beklenen teslimat gecikmelerini, DNS önbellek davranışını, ilgili imza süre sonu ve doğrulama ihtiyaçlarını değerlendirin. Seçilen çakışmanın nedenini ve varsa sağlayıcı kısıtlamalarını kaydedin.

Desteklenen süreç kapsamındaki eski doğrulama materyalini yalnızca değerlendirmenin haklı kıldığı durumlarda kullanımdan kaldırın. Kaydedilen bir mesajın daha sonra kontrol edilmesi, anahtarın kullanımdan kaldırılmasından sonraki orijinal teslim süresi sonucundan farklı olabilir.

Şüpheli uzlaşmayı farklı bir karar olarak değerlendirin

Rutin rotasyon sürekliliği amaçlamaktadır. Şüphelenilen bir özel anahtar ihlali, doğrulamanın eski postalar üzerindeki olası etkisine rağmen acil kısıtlama veya kullanımdan kaldırma gerektirebilir.

Kuruluşun olay sürecini ve imza sağlayıcısının desteklenen yanıtını takip edin. Kanıtları koruyun ve takası açıklayın. Aktif bir uzlaşma sırasında rutin bakıma uygun bir örtüşmenin uygun olacağına dair söz vermeyin.

Doğrulanabilir bir imza kaydıyla kapatın

Hizmeti, sahibi, eski ve yeni seçicileri, yayın kanıtlarını, kesinti gözlemini, örtüşme gerekçesini, emeklilik kararını ve temsilcinin aldığı sonuçları koruyun.

The seçici kılavuzu Kimlik aramayı açıklar. Microsoft 365 veya Workspace için bunların kiracıya özel veya seçili alan adı yapılandırma rehberliği. Yeni imzalama yolu doğrulandığında ve eski bağımlılık belgelenen bir nedenden dolayı kullanımdan kaldırıldığında rotasyon tamamlanmış olur.

Üç ayrı kabul kontrolü kullanın

Önerilen bu kontrol listesi bir kayıt tamamlanmış rotasyon. Geçişten önce, eski seçici kullanılabilir kalırken yeni seçicinin oluşturulan genel değere çözümlendiğini doğrulayın. Geçişten sonra, yeni alınan bir uygulama mesajı s=new2026 ve güvenilir geçişe sahip amaçlanan d alanını göstermelidir. Kullanımdan kaldırılmadan önce, kararlaştırılan kuyruk/yeniden deneme ve doğrulama koşullarının karşılandığını doğrulayın ve kararı kaydedin. İlgisiz bir uygulamadan geçiş, etkilenen rotayı kapatmaz. Örnek aralığını evrensel bekleme süresine dönüştürmeyin.

[ Götürmek ]

İmzalayanı değiştirmeden önce yeni doğrulama materyalini yayınlayın. Gerekçeli bir geçiş dönemi boyunca eski ve yeni seçicileri kullanılabilir durumda tutun. Uzlaşma tepkisini rutin rotasyondan ayrı olarak ele alın.

[ Role göre ]

Bu sizin için ne anlama geliyor?

Sonraki pratik adımlar için rolünüzü seçin.

BT / Posta Yöneticisi

Yayınlamayı, imzalamayı ve kullanımdan kaldırılmayı ayrı ayrı takip edin.

Mevcut DNS kayıtlarının mevcut kullanımı gösterdiğini varsaymak yerine, gerçek imza kimliklerini ve desteklenen anahtar yönetimi modelini kullanın.

Sonraki adımlar

  1. Geçiş yapmadan önce yeni seçiciyi doğrulayın.
  2. Son ağ geçidinden sonra test edin.
  3. Belge örtüşmesi ve kullanımdan kaldırılma koşulları.

CISO / SecOps

Anahtar saklama ve takası gözden geçirin.

Planlı süreklilik ve uzlaşma tepkisi farklı kararlar gerektirebilir. Her aşamanın mülkiyetini, erişim kontrollerini ve kanıtını isteyin.

Sonraki adımlar

  1. Özel anahtar yönetimi sorumluluğunu gözden geçirin.
  2. Doğrulama kanıtlarının saklanmasını değerlendirin.
  3. Uzlaşma yükseltme rotasını onaylayın.

Kurucu / Teknik Olmayan

Önemli postalar için süreklilik isteyin.

Rotasyonun, işletmenin ihtiyaç duyduğu mesajlara yönelik bir sahibi ve bir test planı bulunmalıdır; bu plan, uzlaşmadan şüphelenildiğinde belirgin bir yanıt vermelidir.

Sonraki adımlar

  1. Kritik iş akışlarını tanımlayın.
  2. Değişimi ve sahipliğin üst kademeye aktarılmasını kabul edin.
  3. Geçişten sonra alınan mesaj sonucunu isteyin.

[ SSS ]

Sık sorulan sorular

Yeni anahtar yayınlanır yayınlanmaz eski seçiciyi silmeli miyim?

Hala transit halindeki postaları ve diğer doğrulama bağımlılıklarını değerlendirmeden rutin bir rotasyon için değil. Yayınlama, imzalamanın kesilmesi ve emeklilik ayrı aşamalardır.

RFC 6376 §3.1

Yeni bir anahtar için neden yeni bir seçici kullanmalısınız?

Geçiş sırasında eski ve yeni doğrulama materyalinin ayırt edilebilir olmasını sağlar. Aynı seçicinin altındaki bir anahtarın değiştirilmesi, eski mesajların daha sonra yorumlanmasını zorlaştırabilir.

RFC 6376 §3.1

Evrensel bir DKIM çakışma dönemi var mı?

Burada evrensel bir süre belirtilmemiştir. Teslimat kuyruklarını, yeniden denemeleri, DNS önbelleğe almayı, imza koşullarını, sağlayıcı kontrollerini ve kuruluşun doğrulama ihtiyaçlarını göz önünde bulundurun.

Yeni bir DNS anahtarı imzalamanın değiştiğini kanıtlar mı?

Hayır. Gerçek hizmetten alınan yeni mesajları inceleyin ve bunların seçicisini, imza alanını ve güvenilir doğrulama sonucunu onaylayın.

Sağlayıcı tarafından yönetilen bir rotasyon neyi takip etmelidir?

Sağlayıcının mevcut oluşturulmuş değerlerini ve desteklenen sürecini kullanın. Yetki verilen anahtar yönetimi, doğrudan çalıştırılan imzalamadan farklı kontrollere ve kısıtlamalara sahip olabilir.

Kullanımdan kaldırılan bir anahtar kayıtlı mesajların doğrulanmasını etkileyebilir mi?

Evet. Daha sonraki bir doğrulama girişimi, teslimat sırasında mevcut olan ancak daha sonra değiştirilmiş veya kaldırılmış olan DNS malzemesine bağlı olabilir. Teslimat süresi kanıtlarını koruyun.

RFC 6376 §3.1 RFC 6376 §6.1.2

Şüphelenilen bir uzlaşma normal bakım çakışmasını mı kullanmalı?

Öyle varsaymayın. Olay müdahalesi, farklı bir süreklilik dengesi ile acil eylem gerektirebilir. Yetkili süreci takip edin ve kanıtları koruyun.

Planlanan rotasyonun tamamlandığını kanıtlayan şey nedir?

Yayınlama ve kesme kanıtlarını, gerçek rotadaki imzaları ve uyumu, örtüşme gerekçesini, kullanımdan kaldırma kararını ve sorumlu hizmet sahipliğini koruyun.

[ Kaynaklar ]

Kaynaklar

  1. RFC 6376

    Bölümler §1 · §2.1 · §3.1 · §3.5 · §6.1.2 · §8.3

  2. RFC 8301

    Bölümler §3

  3. RFC 8463

    Bölümler §5 · §6

  4. RFC 9989

    Bölümler §4.1 · §4.4

  5. RFC 1034

    Bölümler §3.6 · §4.2

[ Sözlük ]

Sözlük

DMARC
Kimliği doğrulanmış e-posta kimliklerini Yazar Etki Alanı ve politikasıyla ilişkilendiren bir mekanizma.

RFC 9989 §4.1

Hizalama
Kimliği doğrulanmış bir tanımlayıcı ile DMARC kapsamında Yazar Etki Alanı arasında gerekli olan ilişki.

RFC 9989 §4.4

Yetkili DNS
Önbelleğe alınmış çözümleyici yanıtlarından farklı olarak, bir bölgenin verilerinin sunulmasından sorumlu DNS sunucuları.

RFC 1034 §4.2

DKIM
Alıcının genel anahtar verileriyle doğruladığı, seçilen mesaj başlıkları ve gövde içeriği üzerinde alanla ilişkili bir imza.

RFC 6376 §1

Seçici
DKIM genel doğrulama verilerini bulmak için imzalama alanıyla birlikte kullanılan s değeri.

RFC 6376 §3.1

Kurumsal menşe

Neden en iyi finans kurumları ve hükümetler e-posta güvenlik kontrol panellerini kullanımdan kaldırdı.

Geleneksel e-posta kimlik doğrulama platformları size bir gösterge tablosu satar ve mühendislerinizden bu işi yapmalarını ister. Riskli ortamlarda, manuel gözetim, gecikmeli uygulama, konfigürasyon kayması ve izlenmeyen gölge alanlar anlamına gelir.

EmailAuth aracılı e-posta kaynak platformudur. Temsilcilerimiz uyguluyor p=reject, üçüncü taraf gönderenleri uyumlu tutun ve alan adlarınızı tam sürüme taşıyın RFC 9989 döngüdeki insan tarafından denetlenebilirliğe sahip yeni DMARC standardı uyumluluğu.

Hükümetler Büyük işletmeler 1. Seviye finans kurumları

SaaS · Özel kiracılık · Şirket içi hava boşluklu · BYOK şifrelemesi

Bilgi Bankası