Openprovider'ın aktif bölgeye hizmet edip etmediğini belirleyin
Bu kılavuz, kimlik doğrulama kayıtlarının Openprovider DNS yayınlanmasıyla ilgilidir. Openprovider'ın ayrı posta kutusu veya yönlendirme ürünleri için bir yapılandırma kılavuzu değildir. Microsoft 365 , bir kampanya hizmeti veya başka bir sağlayıcı posta gönderirken alan adınız Openprovider'a kaydedilebilir. Gönderen, kimlik doğrulama talimatlarını sağlar; yetkili DNS operatörü onaylanmış kayıtları yayınlar. İşi atarken bu rolleri ayrı tutun.
Openprovider kendi kendisini destekliyor ad sunucuları ve harici ad sunucuları. Ad sunucusu kılavuzu, harici olarak barındırılan bölgelerin harici DNS sağlayıcısında yapılandırılması gerektiğini, Openprovider tarafından barındırılan bölgelerin ise DNS Yönetimi ve DNS bölgelerine genel bakış aracılığıyla yönetildiğini açıklar. Gerçek kamu delegasyonuyla ve değiştirilen tam bölgeyle başlayın. Kayıtlı bir alan adı ve hesapta görünen bir bölge, yetki oluşturmak için yeterli değildir. Openprovider ad sunucusu kılavuzu
Ad sunucularını yalnızca bir değişiklik yapmak için değiştirmeyin. SPF düzenleyici mevcuttur. Bu, web sitesini, gelen postayı, doğrulama belirteçlerini ve DNSSEC. Harici bir sağlayıcı yetkiliyse, onaylanmış kayıt değişikliklerini o sağlayıcının yöneticisine iletin. Openprovider yetkiliyse gelecekte kullanılmak üzere tasarlanmış bir şablon yerine canlı bölgeyi düzenlediğinizi onaylayın.
Gönderen hizmetten kayıt değişikliklerini bir araya getirin
Gönderenin verdiği mevcut SPF yetkilendirmesini isteyin, DKIM sahipler ve değerler, özel zarf talimatları ve her birinin geçerli olduğu kesin alan adı. Openprovider SPF ayarı olarak adlandırılan evrensel bir kayıttan kaçının: bir DNS ana bilgisayarı, yalnızca bölgeyi barındırarak yetkili bir posta göndericisi haline gelmez. Aynı ayrım DKIM için de geçerlidir. Openprovider'ın DKIM makalesinde, gönderen posta sunucusunun kayıt içeriğini belirlediği ve sağlayıcının veya sistem mühendisinin bunu sağladığı belirtiliyor. Openprovider DKIM yayını
Sahip adları, türleri, TTL'ler ve değerler de dahil olmak üzere, etkilenen kayıt kümelerinin tamamını dışa aktarın veya başka şekilde koruyun. İlgisiz TXT tokenlerini olduğu gibi tutun. Önerilen her eylemi, hizmet sahibi ve nedeni ile birlikte ekleme, değiştirme veya kullanımdan kaldırma olarak kaydedin. A seçici eski görünen bir e-posta, sıradaki postayı hâlâ doğrulayabilir veya başka bir uygulamayı destekleyebilir. Yeni bir hizmetin talimatı, eski hizmetin anahtarının silinmesine izin vermez.
Tam yetkili hedef sahibi, editör girdisinden ayırın. DKIM için seçici ve _domainkey etiketleri önemlidir; alan apeksi ile değiştirilemezler. İçin DMARC, geçerli _dmarc sahibini tanımlayın. SPF için gerçek SMTP zarf alanını tanımlayın. Alınan DNS Kayıtları kılavuzu, geçerli bir evrensel apeks giriş kuralı oluşturmaz. Kaydetmeden önce kök sahibin ve eklenen soneklerin mevcut arayüz kullanımını doğrulayın; boş bir alan olduğunu veya her giriş modunda @'nin kabul edildiğini varsaymayın. Açık sağlayıcı DNS kayıt kuralları
Doğrulanmış TXT biçimlendirmesiyle SPF tek bir politika olarak yayınlayın
Openprovider'ın SPF kılavuzunun kullanım alanları TXT kayıtları ve özellikle kullanıcılarına içeriği düz tırnak işaretleri içine almaları talimatını verir. Geçerli editörün belgelenmiş giriş kuralını izleyin, ardından biçimlendirmenin doğru şekilde yorumlandığını doğrulamak için yayınlanan TXT yanıtını inceleyin. Bir kelime işlemciden kopyalanan kıvrık tırnak işaretleri eşdeğer değildir. Bir çözümleyici zaten dizeleri tırnak işaretleri ile görüntülediğinde, tekrar tekrar tırnak katmanları eklemeyin. Openprovider SPF yayını
Protokol semantiği kabul kriteridir. Değerlendirilen sahipte bir aday SPF politikası bulunmalıdır. Bir TXT kaydı, SPF işlemesi için birleştirilmiş birden fazla karakter dizisi içerebilir; bu nedenle, bir görüntü bölünmesinin mutlaka birden fazla politika olması gerekmez. Bunun tersine, SPF sürüm işaretçisiyle başlayan iki ayrı kayıt, iki göndereni barındırmanın geçerli bir yolu değildir. Yeniden oluşturulan değerde gerekli alanları ve tüm mekanizma sırasını koruyun. SPF RFC 7208
Sağlayıcının genel SPF makalesi, TXT uzunluğu hakkında basitleştirilmiş bir dil içerirken, DNS Kayıtları kılavuzu, büyük bir TXT değerinin bir kayıt içinde daha küçük dizelere bölünmesini açıkça açıklar. Karakter dizisi sınırı, toplam kayıt sınırı olarak değerlendirilmemelidir. Mevcut editörün kullanımını onaylayın ve yeniden oluşturulan yanıtı doğrulayın. Openprovider TXT kayıt kılavuzu Uzun bir değer reddedilirse sağlayıcının rehberliğini alın; ortak anahtarı kısaltmayın veya bir SPF politikasını bağımsız kayıtlara bölmeyin.
Birleştirilmiş bir politikayı kaydetmeden önce SPF yinelemeli arama sınırlarını değerlendirin. Görsel olarak kısa bir politika, dahil edilen politikalar aracılığıyla yine de sınırı aşabilir. Bakım modeli kasıtlı olarak onaylanıp desteklenmediği sürece, sağlayıcı tarafından korunan mekanizmaları günümüzün IP adreslerinin anlık görüntüsüyle değiştirmeyin. Gelecekteki altyapı değişikliklerini takip etmesi gereken statik düzleştirme değişiklikleri.
DKIM kayıt türlerini ve seçici sahipliğini olduğu gibi koruyun
Bazı gönderme hizmetleri bir TXT genel anahtarı sağlar; diğerleri bir tedarik eder CNAME takma ad. Sağlanan türü, sağlanan seçici sahibinde yayınlayın. TXT alanına bir CNAME hedefi koymayın veya anahtarı tepe noktasında yayınlamayın. Alıcı, aramayı mesajın imzalama alanından ve seçicisinden alır; bu nedenle farklı bir sahipte makul görünen bir kayıt yardımcı olmaz. DKIM RFC 6376
Openprovider, bir CNAME sahibini diğer sıradan kayıt verileriyle paylaştığında oluşan hataları belgeler. Düzenleyici bir kopya veya CNAME çakışması bildirirse, söz konusu sahibin tam kayıt kümesini inceleyin. Çakışan TXT kaydını, sahibi olan göndereni belirlemeden silmeyin. Yeni gönderenden desteklenen, çakışmayan bir seçici isteyin veya kontrollü bir rotasyon planlayın. Çatışma yalnızca bir girdi doğrulama sorunu değil, bir güven-sahiplik sorunudur. Openprovider CNAME çakışması kılavuzu
Ortak anahtar veya yetkilendirme kaydı, gönderen hizmetin imzalamaya başlamasına neden olmaz. Gönderen tarafı aktivasyonunu ayrı olarak tamamlayın ve gerçek bir mesajdaki imzayı doğrulayın. Özel anahtarları, API kimlik bilgilerini veya SMTP parolalarını bölgede veya çalışma sayfasında asla yayınlamayın.
Manuel DMARC barındırılan delegasyondan ayırma
Openprovider'ın EasyDMARC entegrasyonu iki yönetim yolunu tanımlar: CNAME takma adı aracılığıyla ulaşılan barındırılan bir politika ve manuel olarak bakımı yapılan bir TXT politikası. Bir örnekte gösterilen yetkilendirme hedefinin kullanılacak değer olmadığı konusunda uyarır; kontrol paneli gerçek hedefi sağlar. Ayrıca, Openprovider ad sunucularını kullanarak uygun bir satın alma veya etkinleştirme akışında otomatik CNAME oluşturma işlemini de açıklar. Bu nedenle manuel olarak herhangi bir şey eklemeden önce mevcut _dmarc sahibini inceleyin. Açık sağlayıcı EasyDMARC yönetimi
Onaylanmış bir yönetim modeli seçin. Barındırılan bir temsilci ile, Openprovider bölgesinde ilgili bir düzenleme yapılmadan, barındırılan hizmetteki operasyonel politika değişebilir. Bu hizmet için bir sahip atayın ve onaylı politika ayarlarını koruyun. Manuel TXT ile değişikliklerin yayınlanan değere yansıtılması gerekir. Bir TXT politikasını ve bir CNAME aynı sahipte bırakmaktan kaçının ve yalnızca bir entegrasyon sihirbazını takip etmek için mevcut raporlama hedeflerini değiştirmeyin.
DMARC , görünen From alanını, geçen hizalanmış SPF veya DKIM kimliklerine göre değerlendirir. Yayınlama bu sürecin bir parçasıdır; alan adının gönderenlerinin aynı hizada olduğunu kanıtlamaz. Alıcı davranışını istenen politikadan farklı tutun ve yaptırımları sıkılaştırmadan önce alan çapında bir gönderen envanteri tutun. DMARC RFC 9989
Yeniden kullanılabilir Openprovider yayınlama çalışma sayfası
Değiştirilen her sahip için bir satır oluşturun ve alan adı için paylaşılan bir değişiklik kaydını saklayın.
- Etki alanı, yetkili ad sunucuları ve canlı bölge tanımlayıcısı: ______.
- DNS yöneticisi, gönderen yöneticisi ve değişikliği onaylayan: ______.
- Gönderim hizmeti ve mevcut yapılandırma kanıtı: ______.
- Amaçlanan tam nitelikli sahip ve ayrı editör ana bilgisayar girişi: ______.
- Kayıt türü, onaylanan değerin tamamı ve TTL: ______.
- Önceki kayıt kümesi ve hayatta kalması gereken bağımlılıklar: ______.
- SPF zarf sahibini ve özyinelemeli politika denetimini değerlendirdi: ______.
- DKIM seçici sahipliği, çakışmanın incelenmesi ve gönderenin etkinleştirilmesi: ______.
- DMARC manuel TXT veya barındırılan CNAME seçimi ve politika sahibi: ______.
- Yetkili değişiklik sonrası cevap ve yinelemeli karşılaştırma: ______.
- Alınan ileti referansı, Kimden, zarf, imzalar ve güvenilir sonuçlar: ______.
- Geri alma adımları, sahibi yeniden test etme, görsel kontrol ve insan kabulü: beklemede.
Seçici çarpışmanın kurgusal tanısı
Bu örnek hayal ürünüdür. Bir bayi, DNS Openprovider tarafından barındırılan bir alana yeni bir pazarlama hizmeti ekler. Yeni hizmet, fatura göndereni için halihazırda bir TXT anahtarına sahip olan seçiciden bir CNAME talep ediyor. Openprovider, değişikliği bir çakışma olarak reddeder. Bayi, yeni kurulum kılavuzunda seçicinin gerekli olduğu söylendiğinden TXT kaldırılmasını öneriyor.
Güvenli inceleme, faturayı göndereni tanımlar ve giden mesajları hâlâ bu seçiciyle imzaladığını doğrular. Önerilen kurtarma, pazarlama hizmetinden farklı bir desteklenen seçici talep etmek veya her iki sahiple doğrulanmış bir anahtar geçişini koordine etmektir. Fatura anahtarını körü körüne silmek değildir. Onaylanan bir değişiklikten sonra ayrı fatura ve pazarlama mesajları test edilecektir. Bu senaryoda hiçbir gerçek bölge, gönderen veya başarılı test temsil edilmez.
DNS ve mesaj kanıtlarıyla kapat
Yanıtları kaydettikten ve sakladıktan sonra yetkili ad sunucularında tam sahipleri sorgulayın. Önbelleğe almayı tanıyarak özyinelemeli bir yanıtı ayrı olarak karşılaştırın. Daha sonra etkilenen her gönderenin bağımsız bir posta kutusu için kontrollü bir mesaj üretmesini ve güvenilir alıcı sonuçlarını kaydetmesini sağlayın. Yalnızca DNS doğrulayıcı, gönderenin gerçekte hangi seçiciyi kullandığını veya geçen kimliğinin hizalanıp hizalanmadığını doğrulayamaz.
Kurtarma gerekiyorsa yalnızca etkilenen önceki kayıt kümesini geri yükleyin ve ilgili iş akışı testlerini tekrarlayın. Barındırılan politika ayarlarının yanı sıra DNS değerlerine ilişkin kanıtları da koruyun; çünkü DNS değerleri bağımsız olarak değişebilir. Mevcut hesap erişimi, arayüz ekran görüntüleri, yetkili öncesi ve sonrası kayıtları, alınan mesaj kanıtları ve insan KOBİ onayı bu kılavuz için beklemededir. Hiçbir DNS düzenlemesi veya canlı test yapılmadı.
Genel kayıtları kriptografik işlemlerden ayrı tutun
Genel anahtarın yayınlanması, e-posta gövdesini şifrelemez, bir imza oluşturmaz veya mesajın tamamının güvenli olduğunu belirlemez. Sağlayıcı makalesinin basitleştirilmiş şifreleme açıklaması yerine, anlambilimi imzalamak için DKIM standardını kullanın. Gönderen operatör etkinleştirmeyi tamamladıktan sonra gerçek imzalı içeriği ve alıcı sonucunu doğrulayın.
Mesaj kabulünü politikanın kullanıma sunulmasından ayırın
Başarılı bir hizalanmış SPF sonucu, bir mesaj değerlendirmesini karşılayabilir, ancak tek başına tüm alanın reddedilmek üzere taşınmasını haklı çıkarmaz. RFC 9989 Bölüm 7.4, alan yayınlama için geçerli DKIM gerektirir p=reject ve dolaylı postaların birlikte çalışabilirliği konusunda uyarıda bulunur. Politika sahibi uygulamayı onaylamadan önce tüm meşru gönderenlerin ve dolaylı yolların envanterini çıkarın. Bu makale için hiçbir DNS değişikliği, kiracı işlemi veya alınan ileti testi yürütülmedi.