DKIM doğrulama hatası: DNS kaydından MimeKit mesaj serileştirmesine

DKIM fail sonucu mesajın hangi aşamada bozulduğunu tek başına açıklamaz. Yanlış DNS anahtarı, imzalama ayarı veya imzadan sonra değişen içerik aynı sonuca yol açabilir. İnceleme gönderici uygulamadan alıcının doğrulama sonucuna kadar ilerlemelidir.

1. Ham başlığı sakla
2. İmza alanını oku
3. DNS anahtarını doğrula
4. Mesaj zincirini izle
5. Serileştirmeyi düzelt
6. Alıcıda yeniden sına

Ham mesaj ve doğrulama sonucunu alın

Authentication-Results ve DKIM-Signature alanları tam mesajla birlikte incelenir. Ekran görüntüsü yerine yetkili ortamda ham başlık ve gerekli MIME yapı korunur. Başlıklarda kişisel adres ve iç rota bilgileri bulunabileceğinden herkese açık paylaşılmaz.

SMTP sunucusunun mesajı kabul etmesi DKIM’in geçtiğini göstermez. Teslim, spam değerlendirmesi ve alan adı doğrulaması farklı sonuçlardır. Alıcının hangi imzayı değerlendirdiği açıkça belirlenmelidir.

İmza alan adı ve selector’ü eşleştirin

İmzadaki d= ve s= alanları doğru DNS anahtarına götürmelidir. Örneğin lab._domainkey.batuhanyazici.com yalnızca temsili bir kayıt adıdır. Etkin DNS’te yayımlanan public key ile göndericinin kullandığı private key ilişkisi doğrulanır.

Anahtar rotasyonunda eski mesajların doğrulanma süresi ve DNS önbelleği hesaba katılır. Private key açık dokümana eklenmez. Birden fazla imza varsa başarısız olanla başarılı olanın alan adı ayrı değerlendirilir.

İmzadan sonra mesajın değişip değişmediğini bulun

Footer ekleyen geçit, karakter kodlaması, satır sonları veya MIME bölümünün yeniden oluşturulması imzayı etkileyebilir. İmzalayan uygulama ile gerçek çıkış mesajı güvenli test ortamında karşılaştırılır.

MimeKit’in ToString serileştirmesine ilişkin uyarısı önemli bir ipucudur; fakat tek başına bütün hata zincirini kanıtlamaz. Mesajı metne çevirip yeniden kurmak yerine kütüphanenin desteklediği WriteTo veya doğrudan gönderim akışı değerlendirilir.

İmzalama sırasını ve canonicalization seçimini kontrol edin

Gerekli başlık ve gövde değişiklikleri tamamlandıktan sonra imzalama yapılmalıdır. İmza sonrası yapılan değişikliğin kapsamı kullanılan canonicalization davranışıyla birlikte incelenir. Ayarları rastgele değiştirmek gerçek dönüşümü gizleyebilir.

DKIM içeriği şifrelemez ve göndericinin bütün güvenilirliğini tek başına kanıtlamaz. SPF ve DMARC gibi diğer kontroller ayrı değerlendirilir. Sadece teslim artsın diye doğrulama politikasını gevşetmek kök neden düzeltmesi değildir.

Temsilî mesajlarla yeniden doğrulayın

Düz metin, HTML ve ekli mesaj gibi kullanılan türler ayrı test edilir. Alıcıdaki DKIM sonucu ve ham mesaj korunur. Geçit veya uygulama güncellemesi sonrasında aynı testlerin tekrar çalıştırılabilmesi faydalıdır.

• Doğru imza ve selector incelendi.
• DNS public key eşleşiyor.
• İmza sonrası değişiklik yolu belirlendi.
• Serileştirme desteklenen API ile yapılıyor.
• Alıcı tarafında doğrulama başarılı.

İlgili çalışma notları

• E-posta gelmiyor: istemci, dağıtım grubu ve filtreyi ayrı incelemek
• Superset üretim geçişi: metadata, Redis, worker ve HTTPS birlikte doğrulanmalı
• TLS sertifikası: CSR üretiminden otomatik yenilemeye