[ DKIM ]

DKIM alınan bir mesaj ve imzalama alanı aracılığıyla açıkladı

Alınan bir mesajı imzasından genel anahtara, güvenilir doğrulama sonucuna ve DMARC ilişkisine kadar takip edin.

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

[ Anahtar noktalar ]

  • Alınan orijinalden her d/s çiftini okuyun.
  • İmza veya DNS anahtarı tek başına doğrulama sağlamaz.
  • DMARC uyumunu ve iş güvenliğini ayrı ayrı değerlendirin.
Bu sayfada

DKIM Bir alanın, kriptografik imza yoluyla bir mesajın sorumluluğunu almasına olanak tanır. Bunun belirli bir e-posta için ne anlama geldiğini anlamak için DNS denetleyicisi yerine alınan orijinalle başlayın. Yararlı kanıt zinciri, mesaj imzası, imzalama alanı ve seçici, genel anahtar, alıcı doğrulama sonucu ve ardından herhangi biri DMARC hizalama karar.

İmzalanan kimliği okuyun

Her birini bulun DKIM-Signature Orijinal mesajdaki başlık. d= değeri imzalama alanını tanımlar ve s= onun seçicisini tanımlar. DNS tabanlı anahtar alımı için bunları seçici olarak birleştirin. _domainkey.signing-domain. İmzalama alanı, yazarın kuruluşuna, bir aktarma kuruluşuna veya onun adına hareket eden bir hizmete ait olabilir. DKIM imzalama sorumluluğunu kasıtlı olarak görünen yazardan ayırmaktadır. RFC 6376 §1, RFC 6376 §3.5, RFC 6376 §3.6.2.

Açıklayıcı örnek: Kimden accounts@example.com ve bir imza şunu içerir d=example.com; s=mail2026. Doğrulayıcı mail2026._domainkey.example.com arar. Bu DNS kaydı herkese açık doğrulama materyali sağlar. Özel imzalama anahtarı yetkili imzalayanda kalır ve yayınlanmamalıdır. Bu örnek aramayı açıklamaktadır; gerçek bir imza veya test edilmiş bir mesaj değildir.

Varlığı başarılı doğrulamadan ayırın

DKIM-Signature başlığı hem mevcut hem de geçersiz olabilir. Uygulama hiçbir imza göndermediğinde bir DNS anahtarı mevcut olabilir. Doğrulama imza yapısını, anahtarı, seçilen başlıkları ve gövde gösterimini kontrol eder. İmzalamadan sonra yapılan değişiklikler, neyin değiştiğine ve imzanın ne olduğuna bağlı olarak imzayı bozabilir. kanonikleştirme kullanılmış. Özet görünümlü bir dize, bu kontrollerin başarılı olduğunun kanıtı değildir. RFC 6376 §3.4, RFC 6376 §3.5, RFC 6376 §3.7, RFC 6376 §6.

Alıcı sistemin güvenilir olup olmadığını inceleyin Authentication-Results veya eşdeğer günlükler. Bu sonucu hangi kimlik doğrulama hizmetinin eklediğini ve güvenilmeyen gelen sonuç başlıklarının nerede kaldırıldığını veya yok sayıldığını anlayın. Gönderen, bir mesaja makul görünen geçiş metni ekleyebilir, dolayısıyla keyfi Authentication-Results içeriği kanıt değildir. RFC 8601 §1.2, RFC 8601 §7.1.

Sonucu görünür yazara bağlayın

DMARC için, başarıyla doğrulanmış bir d= alanını Kimden Yazar Alanıyla karşılaştırın. Sıkı DKIM hizalaması, tam bir eşleşme gerektirir RFC 9989 §3.2.10; Rahat hizalama, organizasyonel alan keşfini kullanır. RFC 9989 §4.10.2. Seçici ve isteğe bağlı i= değeri, bu DMARC karşılaştırması için kullanılan alanlar değildir. Birden fazla DKIM imzası mevcutsa, geçen hizalanmış bir imza, DMARC geçişine giden DKIM yolunu sağlayabilir. RFC 9989 §4.4.1.

Örnekte d=example.com Kimden alanıyla eşleşiyor. Bunun yerine d=service.example.net doğrulanırsa ham DKIM geçer ancak ilgisiz alan adı example.com ile uyum sağlamaz. Alınan bir başlığı düzenleyerek bu durumu "düzeltmeyin": meşru imzalayanı uygun bir desteklenen kimlik kullanacak şekilde yapılandırın.

Yararlı bir araştırma kaydı oluşturun

Mesaj zamanını, rotayı, Etki alanından, her d/s çiftini, güvenilen DKIM sonucunu ve nedenini, DNS gözlem süresini ve hizalama sonucunu kaydedin. Kişisel veya gizli bilgiler içerebileceği için orijinal mesajı koruyun. Bir kopyanın redakte edilmesi imzanın geçersiz kılınmasına neden olabilir; Yeniden doğrulama gerektiğinde erişim kontrollü bir orijinali saklayın.

Doğrulama başarısız olursa imzalamanın etkinleştirilip etkinleştirilmediğini, doğru anahtarın mevcut olup olmadığını, algoritmanın desteklenip desteklenmediğini ve iletinin aktarım sırasında değiştirilip değiştirilmediğini araştırın. Mevcut kriptografik rehberlik, eski varsayılanların yerini alır: RFC 8301 §3.1 rsa-sha1'in imzalanmasını ve doğrulanmasını yasaklar; RFC 8301 §3.2 RSA anahtar kılavuzunu günceller. Eski bir öğreticinin şifreleme seçeneklerini yalnızca sözdizimi hala geçerli görünüyor diye kullanmayın. Yalnızca DNS bir anahtar içerdiğine dair kanıtla değil, alınan sonucun kanıtlarıyla bitirin.

Ayrımı uygula

Varsayımsal bir mesaj için her imza için bir satır yazın: d, s, arama sahibi, güvenilir doğrulama sonucu ve hizalama. İlgisiz bir service.example.net imzası geçerken example.com imzası başarısız olursa, ilk etki alanını ikinci sonuçla birleştirmeyin. Başarısız imzayı araştırın ve değerlendirin SPF DMARC atamadan önce ayrı ayrı. Bu makale için herhangi bir mesaj doğrulaması yürütülmedi.

[ Götürmek ]

Alınan orijinalden her d/s çiftini okuyun. İmza veya DNS anahtarı tek başına doğrulama sağlamaz. DMARC uyumunu ve iş güvenliğini ayrı ayrı değerlendirin.

[ 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

Alınan her d/s çiftini kaydedin.

Her rota için d/s'den DNS'ye ve alıcıya sonuç zincirinin tamamını saklayın. Daha sonra yeniden doğrulama önemliyse orijinal baytları güvenli bir şekilde koruyun.

Sonraki adımlar

  1. Alınan her d/s çiftini kaydedin.
  2. Ortak anahtar sahibinin tam adını alın.
  3. Güvenilir doğrulama sonuçlarını kaydedin ve orijinalleri güvence altına alın.

CISO / SecOps

Özel imzalama anahtarı saklamasını koruyun.

Geçerli bir imzayı, kişinin, isteğin veya ekin güvenli olduğunun kanıtı değil, imzalı içerik için alan adı sorumluluğu olarak değerlendirin. Kimlik doğrulamayı hesap ve kötüye kullanım kontrolleriyle birleştirin.

Sonraki adımlar

  1. Özel imzalama anahtarı saklamasını koruyun.
  2. İmza kimliğini ve kapsamını inceleyin.
  3. Kimliği doğrulanmış mesajlar için kötüye kullanım kontrollerini koruyun.

Kurucu / Teknik Olmayan

Önemli imzalı mesaj akışlarını tanımlayın.

Önemli hizmetlerinizin alan adınıza bağlı bir kimlikle imzalanıp imzalanmadığını ve bu imzaların teslimatta hayatta kalıp kalmadığını sorun. Yayınlanmış bir anahtar tek başına her iki soruyu da yanıtlamaz.

Sonraki adımlar

  1. Önemli imzalı mesaj akışlarını tanımlayın.
  2. Geçişli hizalanmış bir kimliğin kanıtını isteyin.
  3. İşletme onayı kontrollerini DKIM bağımsız tutun.

[ SSS ]

Sık sorulan sorular

DKIM başlığı doğrulamanın geçildiği anlamına mı geliyor?

Hayır. Başlık, ilgili anahtarla hâlâ kriptografik doğrulamaya ihtiyaç duyan bir iddiadır.

RFC 6376 §6.1

d= neyi tanımlar?

Alan adı imzalama sorumluluğunu üstleniyor. Görünür yazarın etki alanından farklı olabilir.

RFC 6376 §3.5

Seçici ne yapar?

d=, ile birlikte doğrulama için kullanılan DNS ortak anahtarını bulur.

RFC 6376 §3.6.2.1

Birden fazla imza geçerli olabilir mi?

Evet. Her bir imzayı ve imzalama alanını inceleyin, ardından DMARC için geçiş yapan hizalanmış imzaları belirleyin.

RFC 6376 §4.2 RFC 9989 §4.4.1

Genel DNS anahtarı gizli mi?

Hayır. Doğrulama materyalidir. İlgili özel imzalama anahtarının korunması gerekir.

RFC 6376 §3.6 RFC 6376 §8.3

i= DMARC DKIM hizalamasını kontrol ediyor mu?

Hayır. DMARC isteğe bağlı i= kimliğini değil, doğrulanmış d= imzalama alanını kullanır.

RFC 9989 §4.4.1

Düzenlenmiş bir e-postayı doğrulayabilir miyim?

Düzenleme, imzalanan baytları değiştirebilir ve doğrulamayı geçersiz kılabilir. Doğrulama gerektiğinde korumalı bir orijinali saklayın.

RFC 6376 §3.4 RFC 6376 §3.7

DKIM bir e-postayı güvenli hale getirir mi?

Hayır. Kapsamı dahilinde imzalama sorumluluğunu ve bütünlüğünü tesis eder. Alıcının rızasını, niyetini veya bağlanma güvenliğini belirlemez.

RFC 6376 §1 RFC 9989 §2.4

[ Kaynaklar ]

Kaynaklar

  1. RFC 6376

    Bölümler §1 · §3.1 · §3.4 · §3.5 · §3.6 · §3.6.2.1 · §3.7 · §4.2 · §5.5 · §6.1 · §8.3

  2. RFC 8301

    Bölümler §3.1 · §3.2

  3. RFC 8601

    Bölümler §1.2 · §7.1

  4. RFC 9989

    Bölümler §2.4 · §3.2.10 · §4.4 · §4.4.1 · §4.10.2

[ Sözlük ]

Sözlük

DKIM
Genel anahtar verileri kullanılarak doğrulanan, seçilen mesaj içeriği üzerindeki alanla ilişkili imza.

RFC 6376 §1

Seçici
Doğrulama verilerini bulmak için d imzalama etki alanıyla birlikte kullanılan s değeri.

RFC 6376 §3.1 RFC 6376 §3.5

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

RFC 9989 §4.4

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ı