Bir sağlayıcı geçerli yayabilir DKIM kuruluşunuzun imzalama alanını desteklemeden imzalar. Bu sınırlama, hizmetin imzasının müşterilerin Kimden'de gördüğü etki alanıyla uyumlu olmadığı durumlarda geçerlidir. DNS değiştirmeden veya hizmeti değiştirmeden önce kesin sınırlamayı belirleyin.
Sağlayıcının gerçekte neyi desteklediğini doğrulayın
Kullandığınız hesap katmanını, gönderme arayüzünü ve etki alanı türünü kapsayan güncel belgeleri isteyin. Doğrulanmış gönderen adresi, özel izleme alanı veya markalı dönüş yolu, özel DKIM desteğinin kanıtı değildir. Gerçek rotadan ham alınan bir mesaj alın ve her imzanın d ve s değerlerini ve güvenilir alıcının doğrulama sonuçlarını kaydedin.
RFC 6376 d'yi imzalama etki alanı olarak tanımlar ve doğrulama verilerini bulmak için bu etki alanıyla birlikte s'yi kullanır. Kendi etki alanınız altında bir anahtar yayınlamak, sağlayıcının oluşturduğu imzadaki d'yi değiştiremez. A CNAME benzer şekilde sağlayıcı tarafından desteklenen bir imzalama yapılandırmasına ihtiyaç duyar; DNS takma adı tek başına bir hizmete sizin adınıza imza atması talimatını vermez.
Başka bir hizalanmış yolun mevcut olup olmadığını kontrol edin
Uygulanabilir bir politikaya sahip ve çözülmemiş değerlendirme hatası olmayan, DMARC geçen bir hizadan geçebilir SPF veya DKIM sonucu. Hizmetin gerçek değerini değerlendirin POSTA etki alanı ve SPF sonucu ayrı ayrı. Desteklenen bir özel dönüş yolu, özel DKIM kullanılamadığında bile hizalanmış SPF sağlayabilir. Doğrulayın hizalama mod ve etki alanı ilişkisi; sağlayıcıya ait bir dönüş yolu, yalnızca hesap için ödeme yaptığınız için uyumlu değildir.
Örnek örnek: posta From= notices@brand.example kullanır ve DKIM d=vendor.example. MAIL FROM alan adı bounce.brand.example ve SPF geçer. Organizasyonel alan ilişkisinin uygun olduğu varsayıldığında, rahat SPF hizalaması DMARC karşılayabilir. Katı SPF hizalaması ile alt alan adı tam olarak eşleşmez. Bu sentetik bir karar örneğidir, herhangi bir satıcıya yönelik bir iddia değildir.
RFC 9989 Bölüm 7.4 ve 8, alan adı yayınlamayı gerektirir p=reject DMARC geçişi için yalnızca SPF güvenmemek ve geçerli DKIM imzalarını uygulamak. Bu nedenle doğrudan dağıtımlı bir SPF geçişi, tam bir p=reject dağıtım tasarımı değildir. Hizmeti bu politikaya hazır olarak değerlendirmeden önce eksik hizalanmış DKIM yolunu çözün.
SPF hizalanmış DKIM aynısı olarak tanımlamayın. Yönlendirme, bağlantı IP'sini değiştirebilir ve SPF bozabilir; ancak hizalama bozulmadan gerçekleşir. DKIM imzası hayatta kalabilir. Tek bir doğrudan dağıtım testine güvenmek yerine, kullanıcılarınız için önemli olan rotaları değerlendirin.
Desteklenen alternatifleri karşılaştırın
Pratik seçenekler, hizmeti, alanın politikası ve kabul edilen sınırlamalarla uyumlu, belgelenmiş, hizalanmış bir SPF yolu ile tutmak, gönderimi gerekli DKIM kimliğini destekleyen bir hizmete taşımak veya son mesajı imzalayan, desteklenen bir yetkili aktarma kullanmaktır. Her biri test ve bir sahip gerektirir. Aktarıcının gerekli uygulama davranışını koruması ve içerik değiştirme işleminden sonra imzalaması gerekir; yalnızca ilgisiz bir imza eklemek hizalamayı çözmez.
Görünür Kimden alanını değiştirmek, gizli bir teknik düzeltme değil, başka bir ürün kararıdır. Tanıma ve yanıtları etkiler ve değiştirilen alanın hâlâ geçerli kimlik doğrulamasına ihtiyacı vardır. Belgelenmemiş bir gönderme yolunu gizlemek için tüm kuruluşun DMARC politikasını zayıflatmaktan kaçının.
Kabul edilen sınırlamayı kaydedin
Sağlayıcının yetenek bildirimini, alınan mesaj kanıtlarını, seçilen uyum yolunu, iş sahibini ve inceleme tetikleyicisini saklayın. Hizmetle ilgili işlem mesajlarını ve iletme senaryolarını test edin. Bir sınırlama devam ederse, maruz kalma ve geçiş kararını açıkça belirtin. Tamamlama, yeşil bir DNS ekran görüntüsü değil, doğrulanmış desteklenen bir rota veya sahip olunan bir istisna anlamına gelir.
Doldurulmuş bir karar kaydı kullanın
Bu açıkça kurgusal iki yollu matrisi düşünün. Faturalandırma API'si A'da From= brand.example , d=vendor.example, seçici satıcı1, MAIL FROM= bounce.brand.example , ham SPF geçişi ve ham DKIM geçişi. Gevşek SPF hizalamasını ve belirtilen paylaşılan değeri varsayalım organizasyon alanı: Başarılı yolu yalnızca SPF ile hizalanmıştır. Yedek röle B'de From= brand.example , d=brand.example, seçici röle2 ve MAIL FROM= vendor.example vardır; her iki ham kontrol de başarılıdır: başarılı yolu yalnızca DKIM hizalanmıştır. Buradaki her yetenek ve sonuç, bir sağlayıcıdan gözlemlenmez, varsayılır.
Bu alan karşılaştırmaları varsayılan sonuçları açıklamaktadır; hiçbir fikstür uygulaması veya sağlayıcı doğrulaması talep edilmez. Faturalandırma API'si A p=reject dağıtımı için kabul edilebilir tek yolu değil, yalnızca SPF sonucunu gösterir. Her iki tasarımı da dağıtmadan önce, rotaya özel tarihli sağlayıcı talimatlarını, oluşturulan DNS değerlerini, ham alınan postayı ve güvenilir bir alıcı sonucunu edinin. Amaçlanan ve gözlemlenen kimlikleri karşılaştırın, kritik formatları ve ilgili iletmeyi test edin ve sahibin kalan sınırlamaları kabul ettiğini kaydedin. Bu gerçek dünyadaki kabul alanları hala beklemededir.
Desteklenen sonraki adımı seçin
- Bilinmeyen yetenek: Tam hesap katmanı ve gönderme yolu için güncel talimatları alma; DNS değerlerini tahmin etmeyin.
- Yalnızca uyumlu SPF mevcut: doğrudan dağıtım sınırlarını ve mevcut politikayı kaydedin; p=reject. için tek DMARC yolu olarak kullanmayın.
- Desteklenen imzalama geçişi mevcuttur: geçişten önce uygulama davranışını, son içeriği, hizalanmış d='yi ve anahtar saklamayı doğrulayın.
- Uygun yol yok: sağlayıcıyı değiştirin veya Kimden kimliği hakkında açık bir ürün kararı verin.
- Kapanış: Alınan mesaj kanıtlarını, kalan sınırlamaları, sorumlu sahibi ve bir sonraki inceleme tetikleyicisini kaydedin.