DKIM kaydı değiştirileceğinde yalnız DNS ekranına odaklanmak yeterli değildir. İleti gönderen sistem ile açık anahtarın yayımlandığı kayıt birlikte çalışmalıdır. Bu nedenle bir hizmetin önerdiği yeni değeri eski satırın üzerine rastgele yapıştırmadan önce hangi selector'ın nerede kullanıldığını belirleyin. E-posta pazarlama aracı ve günlük kurumsal yazışma sistemi farklı kayıtlar kullanıyor olabilir.
Selector hangi anahtarın bulunacağını ayırır
DKIM standardı RFC 6376, selector kullanımını ve anahtar geçişinde eski ile yeni açık anahtarların bir dönem birlikte yayımlanabilmesini açıklar. Bu bir genel geçiş mantığıdır; sizin hizmetiniz için sabit bir bekleme süresi vermez. Mevcut selector adını ve onu kullanan gönderim sistemini envanterinize ekleyin.
Bütün meşru gönderim kaynaklarını listeleyin
Kurumsal posta, web formu ve kullanılan dış gönderim araçlarını ayrı değerlendirin. Bir sistemin kaydını güncellemek diğerinin anahtarını değiştirmek anlamına gelmez. SPF, DKIM ve DMARC rehberi kavramların görevlerini ayırmak içindir. Bu yazı temel kurulumu tekrar etmek yerine anahtar değişiminin kontrollü yürütülmesine odaklanır.
Yeni kaydı ve gerçek imzayı birlikte doğrulayın
Sağlayıcının oluşturduğu açık anahtar bilgisini yetkili DNS alanında yayımlayın; özel anahtarı asla paylaşmayın. Yeni düzenle gönderilen kontrollü bir iletinin doğrulama sonucunu yetkili araçla inceleyin. Sadece DNS kaydının mevcut olması başarı kanıtı değildir. Teslimat rehberi doğrulama ile bütün mesajların kesin teslim edileceği iddiasının farklı olduğunu hatırlatır.
Eski kaydı bilinçli bir kapanış planıyla değerlendirin
Eski selector'ın hangi göndericilerde kaldığını belirlemeden kaldırmayın. Değişiklik sorumlusu, geri dönüş yolu ve test zamanı yazılı olsun. Hata durumunda eski yapılandırmaya nasıl dönüleceği bilinmelidir. KOBİ güvenlik rehberi açısından erişim yetkisini de sınırlandırın; anahtar değişimini gereksiz çok sayıda kişinin yapmasına izin vermeyin.
Kurumsal e-posta yöneticisine aktarılacak kayıt; selector adı, ilgili hizmet, değişiklik tarihi ve doğrulanan test sonucunu içermelidir. Gerçek müşteri mesajlarını örnek olarak herkese açık paylaşmayın. İyi bir geçişin hedefi yalnız yeni bir TXT değeri üretmek değil, bütün meşru gönderim akışlarının beklendiği şekilde imzalanmasını sürdürmektir. İşlem tamamlandığında envanteri güncellemek bir sonraki değişikliği daha güvenli hâle getirir.
Anahtar bilgisini paylaşırken sınırı koruyun
Açık anahtar kaydının DNS'te yayımlanması ile özel anahtarın yönetim sisteminde korunması farklı işlerdir. Destek için hazırlanan ekran görüntüsünde hangi alanın göründüğünü kontrol edin; gizli imzalama bilgisini örnek diye paylaşmayın. Bir hizmetten ayrılırken yalnız DNS kaydını değil, o hizmette kalan gönderim yetkisini de ilgili yöneticilerle değerlendirin. Anahtar geçişi güvenlik şüphesi nedeniyle yapılıyorsa rutin yenilemeyle aynı olay gibi yönetilmemelidir; kapsam ve acil adımlar sorumlu ekipçe belirlenir. Bu yazı her durum için sabit takvim önermez. Kurumunuzun uyguladığı planı, değişiklik nedenini ve doğrulama sonucunu birlikte saklamak sonraki incelemeyi kolaylaştırır.
Sıkça Sorulan Sorular
Selector parola mı?
Hayır. İmza doğrulamasında ilgili açık anahtar kaydının bulunmasına yardımcı olan tanımlayıcıdır. Özel imzalama anahtarını DNS'e veya destek ekran görüntüsüne koymayın.
Yeni TXT kaydı eklemek geçişi tamamlar mı?
Hayır. Giden hizmetin doğru selector ve özel anahtarla imzaladığı da doğrulanmalıdır. DNS tarafı ile gerçek ileti sonucu birlikte kontrol edilir.
Eski selector hemen silinir mi?
Genel bir anında silme önerisi güvenli değildir. Geçiş planını, yoldaki iletileri ve sağlayıcının yönlendirmesini değerlendirerek karar verin.
Birden fazla selector olabilir mi?
Olabilir. Bunlar farklı gönderim sistemlerine veya geçişe ait olabilir; açıklaması olmayan bir kaydı kullanılmıyor varsaymayın.