Mevcut Hizmet Masası rotasını kullanın
Bu katalog girişi Samanage adını kullanıyor. Buradaki uygulama prosedürünün kapsamı, belgelenen altyapısı hala samanage.com adlarını kullanan mevcut SolarWinds Hizmet Masası e-posta ayarlarını kapsamaktadır. Bunu eski Samanage ekran görüntüleriyle birleştirmeyin veya mevcut hesabın geçiş dönemi kontrol listesinin açıkladığını varsaymayın. Değişiklik yapmadan önce hizmeti, veri merkezini, hesap türünü ve sorumlu yöneticiyi kaydedin.
Mevcut birinci taraf gezinmesi hesap organizasyonuna göre farklılık gösterir. ITSM, Kurulum > Hesap > E-posta ayarlarını kullanır. ESM'nin bu ayarlarla ilgili organizasyon veya hizmet sağlayıcı bağlamı vardır. Hangi içeriği görüntülediğinizi kaydedin; böylece tek bir servis sağlayıcı için yapılandırılan alan adının her servis sağlayıcıyı kapsayacağı varsayılmaz. SolarWinds Hizmet Masası e-posta ayarları
Güvenilirliği önemli olan mesajları belirleyin: temsilci yanıtları, görevle ilgili mesajlar, otomatik olay bildirimleri ve müşteriye yönelik tüm farklı yollar. Ayrıca gelen bilet adreslerini ve iletim kurallarını da kaydedin. Giden kimlik doğrulama ve gelen olay oluşturma farklı akışlardır; birini değiştirmek diğerini sessizce bozmamalı.
Kimlik doğrulamasına bağlı kontrolleri anlayın
Mevcut kılavuz, kişiselleştirilmiş e-posta adresleri ve özel yanıt e-posta adresi için alan adı kimlik doğrulamasının bir ön koşul olduğunu belgelemektedir. Kişiselleştirilmiş adları kişiselleştirilmiş adreslerden ayırır. Otomatik bildirimler, kullanıcı eylemlerinden kaynaklanan mesajlarla aynı şekilde etkilenmez. Sonuç olarak, bir aracının kişiselleştirilmiş görünen adının her göndereni tanımladığını varsaymak yerine gerçek mesaj kategorilerini test edin. SolarWinds Hizmet Masası e-posta ayarları
Aracı adresi etki alanlarının ve otomatik bildirimler tarafından kullanılan sabit kimliklerin bir listesini oluşturun. Bir yardım masası, e-posta etki alanları farklı sahiplere sahip yan kuruluşların veya yüklenicilerin temsilcilerini içerebilir. Bir temsilcinin bu adrese sahip olması nedeniyle bir alan adını yetkilendirmeyin. Kuruluşun kimlik olarak gönderme iznine sahip olduğunu ve sağlayıcının doğrulama sürecini tamamlayabildiğini doğrulayın.
Yanıt hedefini işlevsel bir bağımlılık olarak ele alın. Bir destek adresi, gelen postayı Hizmet Masası dropbox'ına iletebilir. Doğrulanmış bir giden gönderen, iletim kuralının çalıştığını veya yanıtların amaçlanan olaya eklendiğini kanıtlamaz. Belirlenmiş bir olaya zararsız bir yanıt testi ekleyin ve olayın gerçekten etkilenen kullanıcılara bildirimde bulunmadığından emin olun.
Oluşturulan üç kayıtlı yapılandırmayı yayımlayın
Geçerli belgelenen iş akışı E-posta Ayarları > E-posta Kimlik Doğrulaması > Özel alan adı ekle şeklindedir. Onaylanan alanı ekleyin, DNS ayarlarını genişletin ve oluşturulan üç alanı kopyalayın CNAME kayıtları. Bunları yetkili DNS yayınlayın, hesaba geri dönün ve Doğrula'yı kullanın. Beklenen başarılı durum Doğrulandı'dır. SolarWinds Hizmet Masası e-posta ayarları
Uydurma seçicileri değil, canlı olarak oluşturulmuş sahipleri ve hedefleri kullanın. bir kayıt başka bir müşteriden ayarlandı. Her giriş için tam genel değeri, ilgili alanı, TTL'yi ve değişiklik referansını koruyun. Değişiklik yapmadan önce DNS yöneticisinden aynı sahibin önceden var olan verilerini incelemesini isteyin. Çakışma, ilgisiz bir anahtarın silinmesine izin vermek değil, yapılandırmayı araştırmak için bir nedendir.
DNS konsolunun göreli ve tam adları nasıl işlediğini kontrol edin. Başarılı bir kaydetme yine de yanlış sahibi veya hedefi oluşturabilir. Amaçlanan genel adları sorgulayın ve gerektiği şekilde CNAME çözümlerini izleyin. Gerçekte yayınlananları ve gözlem zamanını kaydedin. Sağlayıcı doğrulaması ve bağımsız DNS kanıtları aynı kayıt kümesini tanımlamalıdır.
Doğrulama başarısız olursa bu sonuçları mevcut hesabın oluşturulan değerleriyle karşılaştırın. Düzenlenen DNS hizmetinin yetkili olduğunu ve önbelleklerin süresinin dolması için uygun bir fırsata sahip olduğunu doğrulayın. Mevcut durumu anlamadan etki alanını tekrar tekrar eklemeyin veya kayıtların üzerine yazmayın. Tam hatayı koruyun ve sağlayıcının doğru şekilde yayınlanan kayıtları tanıyamaması durumunda hizmet sahibini dahil edin.
SPF ve yerel alım kontrollerini ayrı ayrı ele alın
SolarWinds belgeleri şunları include:_spf.samanage.com SPF örnek. Kullanımını gerçek zarf rotasına ve kuruluşun mevcut yetkilendirmesine göre inceleyin. Kuruluşun politikasının tamamını değiştirmeyin veya birden fazla uygulanabilir politika oluşturmayın. SPF kayıtları. İç içe DNS değerlendirmesini hesaba katın ve halihazırda bu sahibi kullanan meşru gönderenleri koruyun. SolarWinds Hizmet Masası e-posta ayarları SPF RFC 7208
Sağlayıcı ayrıca veri merkezine özel alıcı izin verilenler listelerini de listeler. Bu kontroller kendi posta sistemleriniz tarafından kabul edilmeyle ilgilidir; harici alıcılar için geçişli, hizalanmış bir imza oluşturmazlar. Önerilen izin verilenler listesi değişikliklerini güvenlik ekibiyle birlikte saklayın ve kullanımdan önce mevcut bölgesel değerleri doğrulayın. Otomatik kimlik doğrulama onarımı olarak her bölgenin adresini veya genel URL istisnalarını uygulamayın.
Özellikle yerel bir güvenlik ürünü, kimlik doğrulaması yanlış olsa bile bir istisna nedeniyle mesaj iletebilir. Yalnızca gelen kutusu yerleşimini değil, temel kimlik doğrulama sonuçlarını da koruyun. Güvenli Bağlantılar, spam filtreleme veya ek erişiminde yapılan değişikliklerin daha geniş güvenlik etkileri olabilir ve bunların kendi incelemelerini gerektirebilir. Bu kılavuz, testin başarılı görünmesi için bu kontrollerin atlanmasını önermez.
2025 geçiş planını yeniden kullanmayın
SolarWinds'in geçiş bildirimi, ikinci aşaması 16 Mart 2025 tarihli bir geçişi tanımlıyor. Kimliği doğrulanmamış hesapların neden özel yanıt davranışını kaybedebileceğini veya kişiselleştirilmiş adresler olmadan kişiselleştirilmiş adları tutabildiğini açıklıyor. Bu bildirimi, güncel bir son tarih veya belirli bir kiracının geçişi tamamladığının kanıtı olarak değil, tarihsel tanılama bağlamı olarak kullanın. SolarWinds e-posta hizmeti geçiş bildirimi
Uzun süredir devam eden bir hesabın yanıt adresi beklenmedik bir şekilde değiştiyse mevcut ayarları daha önce kaydedilen bir yapılandırmayla karşılaştırın. Kimlik doğrulama durumu konuyla ilgili olabilir ancak bunun tek neden olduğunu düşünmeyin. Hesabın sahibine, hesabın yeniden yapılandırılıp yapılandırılmadığını, bir servis sağlayıcının eklenip eklenmediğini veya temsilci kimliğinin değiştirilip değiştirilmediğini sorun. Herhangi bir şeyi geri yüklemeden önce mevcut rotayı belgeleyin.
Eski DNS kayıtları ancak aktif hesap bulunmadığı tespit edildikten sonra kaldırılmalıdır, seçiciveya mesaj rotası bunlara bağlıdır. Geçiş bildiriminin yaşı, güvenli bir silme işlemini tanımlamak için yeterli değildir. Temizleme işlemini, doğrulanmış, çalışan bir göndereni edinme acil görevinden ayrı tutun.
Temsilci mesajlarını ve otomatik bildirimleri doğrulayın
Yetkili bir test olayı oluşturun ve kapsam içi kullanıcı eylemi ve otomatik bildirim yollarını kullanın. Orijinal mesajı güvenilir bir alıcıda yakalayın. Görünen Gönderen adresini ve görünen adı, Yanıtla'yı, zarf kimliğini ve tümünü ayrı ayrı kaydedin. DKIM etki alanlarını ve seçicileri imzalama ve güvenilir kimlik doğrulama sonuçları. Mesajı oluşturan servis sağlayıcı bağlamını ve olayı ekleyin.
Alınan mesajdan DKIM d= ve s= değerlerini okuyun ve bunları yayınlanan yapılandırmayla karşılaştırın. Bir seçicinin varlığı yalnızca bir kaydın mevcut olduğunu kanıtlar; mesajın aslında geçerli bir imza kullanması gerekir. Alıcı birden fazla imza görürse ilgili tüm imzaları koruyun. DKIM RFC 6376
DMARC görünür Kimden etki alanı için geçişli, hizalanmış bir kimlik doğrulama yolu gerektirir. Yanıtla ve görünen adlar bu kimliğin yerine geçmez. Sağlayıcı zarf alanı için SPF geçişi, SPF eksikliğiyle bir arada bulunabilir hizalama, ancak hizalanmış DKIM yine de DMARC karşılayabilir. Gerçek mesajı etkili politika kapsamında değerlendirin. DMARC RFC 9989
Bir sınıf başarılı ve diğeri başarısız olursa, paylaşılan DNS değiştirmeden önce gönderenin kimliklerini karşılaştırın. Bir kullanıcı eylemi mesajı bir aracı adresini kullanabilirken, otomatik bildirim farklı bir kimliği takip eder. Posta hiç gönderilmediyse öncelikle bildirim olayını ve mevcut teslimat kanıtlarını inceleyin. Kimlik doğrulama kayıtları, eksik bir tetikleyiciyi veya kasıtlı olarak bastırılmış bir hedefi düzeltemez.
Yanıltıcı görünen adın kurgusal örneği
Yalnızca kurgusal yazılı durum: SW-01, bir kullanıcı eylemi mesajının Alex Desteğini görüntülediğini varsayar, ancak gerçek Kimden, bir sağlayıcı hizmet adresi olarak kalır. Yanıtla: help@example.org ; kesin sağlayıcı adresi, DKIM ve SPF sonuçları bilinmiyor. Yönetici, kişiselleştirilmiş adları kimliği doğrulanmış kişiselleştirilmiş adreslerden ayırmalı, ardından aracı eylemini, otomatik bildirimi ve olaya yanıt verme yolunu ayrı ayrı test etmelidir. Bu kanıtın yerine geçecek izin verilenler listelerini değiştirmeyin. Hiçbir hizmet hesabı, olay veya mesaj incelenmedi.
Uygulama çalışma sayfası ve sürüm sınırları
- Hesap bağlamı: Hizmet Masası ürünü, veri merkezi, ITSM veya ESM, kuruluş veya hizmet sağlayıcı ve sahibi.
- Kimlik envanteri: aracı alanları, otomatik bildirim Gönderen değerleri, görünen ad ayarları ve yanıt adresleri.
- DNS : oluşturulan üç CNAME'in tümü, mevcut veriler, yayınlanan tam adlar, TTL'ler, arama süresi ve Doğrulanmış durumu.
- Politika: SPF sahibi ve yetkili mekanizmalar, etkili DMARC politikası ve ayrıca onaylanmış yerel alım istisnaları.
- Testler: olay referansı, tetikleyici eylem, alıcı, Kimden, Yanıtla, zarf kimliği, DKIM d=/s= değerleri ve hizalama sonucu.
- Kurtarma: önceden desteklenen ayarlar, iletme bağımlılıkları, bildirim duraklatma sahibi ve temizleme incelemesi.
Canlı hesap yapılandırması, taşıma durumu, DNS , alınan başlıklar ve ekran görüntüleri kontrol edilmedi. Görsel inceleme, insan KOBİ onayı ve yayın henüz beklemededir. Bu yayınlanmamış aday, mevcut belgelenmiş Hizmet Masası rotasını kapsamaktadır; eski yapılandırmalar ve test edilmemiş hizmet sağlayıcı bağlamları beklemede kalır.
Geçiş mesajını yaptırım hazırlığından ayırın
RFC 9989 Bölüm 7.4, alan adı yayınlama için geçerli DKIM gerektirir p=reject ve dolaylı postaların birlikte çalışabilirliğine ilişkin uyarılar. Tek bir hizalanmış SPF sonucu, tek başına reddetme politikasının kullanıma sunulmasını haklı çıkarmaz. Tüm meşru rotaları ve politika sahipliğini bu sağlayıcı kurulumundan ayrı olarak inceleyin.