A DKIM seçici bir imzalama etki alanının kapsamına alınmıştır. İki hizmet, farklı d= alanları altında "varsayılan" kelimesini güvenli bir şekilde kullanabilir, ancak default._domainkey.example.com , bir DNS sahibinin adıdır. İki bağımsız hizmetin aynı adda farklı anahtarlara ihtiyacı varsa, ikinci hizmetin eklenmesi ilkinin doğrulamasını bozabilir. DNS değiştirmeden önce sahiplik çakışmasını çözün.
Tam adları karşılaştırın
Her etkin hizmetten yakın zamanda alınan imzalı bir mesajı toplayın ve d= ve s=. Bu değerleri bekleyen sağlayıcı kurulum talimatlarıyla karşılaştırın. DNS tabanlı anahtar alımı için seçici ve imzalama alanı, arama adını belirler. Bir kurulum ekranında “seçici 1” gibi sağlayıcı etiketi, gerçek DNS sahibini tanımlamak için yeterli değildir. RFC 6376 §3.5 Ve RFC 6376 §3.6.2.1.
Açıklayıcı örnek: bordro ve pazarlamanın her ikisi de d=example.com, ile s=default isteğinde bulunur, ancak her biri farklı bir özel anahtara sahiptir. Her iki imza da doğrulayıcıları default._domainkey.example.com adresine yönlendirir. Bordronun genel anahtarının pazarlama anahtarıyla değiştirilmesi, halihazırda aktarılmakta olan mesajlar da dahil olmak üzere bordro mesajlarının doğrulanamamasına neden olabilir. Bunun tersine, d=payroll.example.com altındaki varsayılan ve d=marketing.example.com altındaki varsayılan farklı arama adlarıdır. Hizalama sonuçların hâlâ ayrı bir kontrole ihtiyacı vardır.
Desteklenen bir ayırma tasarımı seçin
Sağlayıcıların desteklediği durumlarda bağımsız imzalama hizmetleri için farklı seçicileri tercih edin. Yeni hizmetin oluşturulan genel anahtar kaydını kendi sahibi adına yayınlayın, doğrulayın, ardından imzalayanı etkinleştirin ve alınan postayı test edin. Bir hizmet seçici adını düzeltirse ayrı bir imzalama alt alan adını mı yoksa başka bir belgelenmiş yapılandırmayı mı desteklediğini sorun. Bir şey icat etme CNAME Bir seçiciyi yalnızca DNS hedefleyin veya yeniden adlandırın: imzalayanın eşleşen s= değerini yayması gerekir.
d='yi bir alt alan adıyla değiştirmek etkileyebilir DMARC. Bir alt alan adı, bir üst Yazar Alanı ile tam uyum sağlamada başarısız olurken, esnek kurallara göre hizalanabilir. Adlandırma geçici çözümünü seçmeden önce amaçlanan ilişkiyi onaylayın. RFC 9989 §4.4.1 Ve RFC 9989 §4.10.2.
Belirsiz anahtar cevaplara güvenmeyin
Altında RFC 6376 §3.6.2.2TXT anahtar kayıtları seçici adı için benzersiz olmalıdır; çoklu kayıt sonuçları tanımsızdır. Birden fazla farklı anahtarın tek bir sahipte yayınlanması, bu yayın kuralını ihlal eder ve bir hizmet ayrımı tasarımı değildir. RFC 6376 doğrulayıcının döndürülen bir anahtarı seçmesine veya kendi takdirine bağlı olarak belirtilmemiş bir sıralamayla birkaçını denemesine olanak tanır. Bu nedenle, bir alıcıda çalışan bir konfigürasyon başka yerde güvenilmez olabilir. Ayrı seçiciler, anahtar seçimi davranışına güvenmek yerine açık bir eşleme sağlar. RFC 6376 §6.1.2.
Bir TXT kaynak kaydındaki birden çok tırnaklı karakter dizesi farklı bir sorundur: bunlar tek bir kaydın parçaları olabilir. Sağlayıcının ekran sarmasını birden çok farklı anahtarla karıştırmayın. Uygun bir DNS aracı kullanarak gerçek DNS yanıtlarını ve sağlayıcının ürettiği değeri karşılaştırın.
Mevcut bir çarpışmayı güvenli bir şekilde ele alın
Zaten bir çarpışma meydana gelmişse mevcut DNS , yapılandırma geçmişini, etkilenen d/s çiftlerini ve alıcı hatalarını yakalayın. Önceki eşlemeyi yalnızca güvenliyse ve hala gerekliyse geri yükleyin, ardından yeni hizmeti desteklenen ayrı bir seçiciyle çevrimiçi duruma getirin. Özel anahtarları yalnızca tek bir kamu kaydına sığdırmak amacıyla ilgisiz hizmetler arasında paylaşmaktan kaçının; bu da gözetimi ve olayın etkisini genişletir.
Güvenlik hususlarına ve sağlayıcının rotasyon sürecine bağlı olarak meşru gecikmeli posta yolu ihtiyaçlarınızın çakışması için eski doğrulama kaydını saklayın. Güvenliği ihlal edilmiş bir anahtar farklı bir durumdur ve teslimatın etkisine rağmen derhal iptal edilmesini gerektirebilir. Değişiklikten sonra her iki hizmeti de bağımsız olarak test edin, sahiplerini kaydedin ve seçici adlarını envanterde saklayın. Kabul testi, yalnızca iki yeşil sağlayıcı kurulum ekranı değil, iki doğrulanabilir, amaçlanan kimliktir.
Sentetik iki hizmet talebini çözümleyin
Maaş bordrosunun şu anda s=default ve d=example.com, ile işaretlendiğini ve pazarlama isteklerinin aynı çifti farklı bir anahtarla işaretlediğini varsayalım. Arama sahibi aynıdır, bu nedenle üzerine yazmayın veya yanına ikinci bağımsız anahtarı yayınlamayın. Pazarlama s=marketing2026, oluşturulan anahtarını marketing2026._domainkey.example.com adresinde yayınlayın ve aynı seçiciyi imzalayanda yapılandırın. Daha sonra bordro/varsayılan ve pazarlama/pazarlama2026'yı bağımsız olarak test edin. Yalnızca imzalama alt alan adı seçeneği destekleniyorsa d'yi değiştirmeden önce hizalamasını gözden geçirin. Bunlar, test edilmiş bir sağlayıcı prosedürü değil, planlama adımlarıdır.