현재 서비스 데스크 경로 사용
이 카탈로그 항목은 Samanage라는 이름을 사용합니다. 여기서 구현 절차의 범위는 문서화된 인프라가 여전히 samanage.com 이름을 사용하는 현재 SolarWinds Service Desk 이메일 설정으로 제한됩니다. 이전 Samanage 스크린샷과 결합하거나 마이그레이션 시대의 체크리스트가 현재 계정을 설명한다고 가정하지 마세요. 변경하기 전에 서비스, 데이터 센터, 계정 유형 및 담당 관리자를 기록해 두십시오.
현재 자사 탐색은 계정 조직에 따라 다릅니다. ITSM은 설정 > 계정 > 이메일 설정을 사용합니다. ESM에는 해당 설정에 대한 조직 또는 서비스 제공자 컨텍스트가 있습니다. 하나의 서비스 공급자에 대해 구성된 도메인이 모든 서비스 공급자를 포함한다고 가정하지 않도록 현재 보고 있는 컨텍스트를 기록하세요. SolarWinds 서비스 데스크 이메일 설정
상담원 응답, 작업 관련 메시지, 자동 사고 알림, 고유한 고객 대면 경로 등 신뢰성이 중요한 메시지를 식별하세요. 또한 수신 티켓 주소와 전달 규칙을 기록하십시오. 아웃바운드 인증과 인바운드 인시던트 생성은 서로 다른 흐름입니다. 하나를 바꾸면 다른 하나가 조용히 중단되어서는 안 됩니다.
인증 종속 제어 이해
현재 가이드에서는 개인화된 이메일 주소와 사용자 정의 회신 이메일 주소에 대한 전제 조건으로 도메인 인증을 문서화합니다. 이는 개인화된 이름과 개인화된 주소를 구별합니다. 자동 알림은 사용자 작업으로 인해 발생하는 메시지와 같은 방식으로 영향을 받지 않습니다. 따라서 상담원의 개인화된 표시 이름이 모든 보낸 사람을 설명한다고 가정하기보다는 실제 메시지 범주를 테스트하십시오. SolarWinds 서비스 데스크 이메일 설정
자동 알림에 사용되는 에이전트 주소 도메인 및 고정 ID 목록을 작성합니다. 헬프 데스크에는 이메일 도메인의 소유자가 다른 자회사나 계약자의 에이전트가 포함될 수 있습니다. 한 에이전트가 해당 주소를 가지고 있다고 해서 도메인을 승인하지 마십시오. 조직에 ID로 보낼 권한이 있고 공급자의 확인 프로세스를 완료할 수 있는지 확인하세요.
응답 대상을 기능적 종속성으로 처리합니다. 지원 주소는 수신 메일을 서비스 데스크 보관용 계정으로 전달할 수 있습니다. 확인된 발신자는 전달 규칙이 작동하는지 또는 의도한 사건에 회신이 첨부되었는지 증명하지 않습니다. 지정된 사고에 무해한 응답 테스트를 포함하고 실제 영향을 받은 사용자에게 알리지 않도록 하세요.
생성된 3개 레코드 구성 게시
현재 문서화된 워크플로는 이메일 설정 > 이메일 인증 > 사용자 정의 도메인 추가입니다. 승인된 도메인을 추가하고 해당 DNS 설정을 확장한 후 생성된 세 가지 도메인을 복사합니다. CNAME 기록. 신뢰할 수 있는 DNS 에 게시하고 계정으로 돌아가 확인을 사용하세요. 예상되는 성공 상태는 확인됨입니다. SolarWinds 서비스 데스크 이메일 설정
조작된 선택기가 아닌 실시간으로 생성된 소유자 및 대상을 사용하거나 기록 다른 고객으로부터 설정되었습니다. 각 항목에 대해 정확한 공개 값, 관련 도메인, TTL 및 변경 참조를 유지하세요. 변경하기 전에 동일한 소유자의 기존 데이터를 검사하도록 DNS 관리자에게 요청하세요. 충돌은 구성을 조사해야 하는 이유이지 관련 없는 키를 삭제할 수 있는 권한이 아닙니다.
DNS 콘솔이 상대 이름과 전체 이름을 처리하는 방법을 확인하세요. 성공적으로 저장하더라도 잘못된 소유자나 대상이 생성될 수 있습니다. 의도한 공개 이름을 쿼리하고 필요에 따라 CNAME 확인을 따릅니다. 실제로 출판된 내용과 관찰 시간을 기록합니다. 공급자 확인과 독립적인 DNS 증거는 동일한 레코드 세트를 설명해야 합니다.
확인에 실패하면 해당 결과를 현재 계정에서 생성된 값과 비교하세요. 편집된 DNS 서비스가 신뢰할 수 있고 캐시가 만료될 적절한 기회를 가졌는지 확인하십시오. 기존 상태를 이해하지 못한 채 도메인을 반복적으로 추가하거나 레코드를 덮어쓰지 마십시오. 정확한 오류를 유지하고 공급자가 올바르게 게시된 기록을 인식할 수 없는 경우 서비스 소유자를 참여시키십시오.
SPF 및 로컬 수신 제어를 별도로 처리
SolarWinds 문서에는 include:_spf.samanage.com SPF 예. 실제 봉투 경로와 조직의 기존 인증에 대한 사용을 검토합니다. 조직의 전체 정책을 대체하거나 적용 가능한 여러 정책을 생성하지 마십시오. SPF 레코드. 중첩된 DNS 평가를 고려하고 이미 해당 소유자를 사용하고 있는 합법적인 발신자를 보존합니다. SolarWinds 서비스 데스크 이메일 설정 SPF RFC 7208
공급자는 데이터 센터별 수신 허용 목록도 나열합니다. 이러한 통제는 귀하의 메일 시스템에 의한 승인과 관련이 있습니다. 외부 수신자를 위해 통과 정렬 서명을 생성하지 않습니다. 제안된 허용 목록 변경 사항을 보안 팀과 함께 유지하고 사용하기 전에 현재 지역 값을 확인하세요. 자동 인증 복구로 모든 지역의 주소 또는 광범위한 URL 예외를 적용하지 마십시오.
특히, 로컬 보안 제품은 인증이 잘못된 경우에도 예외로 인해 메시지를 전달할 수 있습니다. 받은 편지함 배치뿐만 아니라 기본 인증 결과를 보존합니다. 안전한 링크, 스팸 필터링 또는 첨부 파일 액세스에 대한 변경 사항은 보안 효과가 더 광범위할 수 있으며 자체 검토가 필요할 수 있습니다. 이 가이드에서는 테스트가 성공한 것처럼 보이도록 이러한 컨트롤을 우회하는 방법을 규정하지 않습니다.
2025년 마이그레이션 일정을 재사용하지 마세요.
SolarWinds의 마이그레이션 공지는 2025년 3월 16일에 두 번째 단계가 진행된 전환에 대해 설명합니다. 이는 인증되지 않은 계정이 맞춤 응답 동작을 잃거나 맞춤 주소 없이 맞춤 이름을 유지할 수 있는 이유를 설명합니다. 해당 알림을 현재 기한이나 특정 테넌트가 마이그레이션을 완료했다는 증거가 아닌 기록 진단 컨텍스트로 사용하세요. SolarWinds 이메일 서비스 마이그레이션 공지
장기간 계정의 회신 주소가 예기치 않게 변경된 경우 현재 설정을 기록된 이전 구성과 비교하십시오. 인증 상태가 관련될 수 있지만 그것이 유일한 원인이라고 가정하지 마십시오. 계정이 재구성되었는지, 서비스 제공업체가 추가되었는지, 에이전트 ID가 변경되었는지 소유자에게 문의하세요. 무엇이든 복원하기 전에 실제 현재 경로를 문서화하십시오.
이전 DNS 레코드는 활성 계정을 설정한 후에만 제거해야 합니다. 선택자또는 메시지 경로가 이에 따라 다릅니다. 마이그레이션 알림의 기간은 안전한 삭제를 식별하기에 충분하지 않습니다. 확인되고 작동하는 발신자를 확보하는 즉각적인 작업과 별도로 정리 작업을 수행하세요.
상담원 메시지 및 자동 알림 확인
승인된 테스트 사건을 생성하고 범위 내 사용자 작업 및 자동 알림 경로를 실행합니다. 신뢰할 수 있는 수신자에게 원본 메시지를 캡처하세요. 표시되는 보낸 사람 주소와 표시 이름을 별도로 기록하고 회신, 봉투 ID 등을 모두 기록합니다. DKIM 도메인 및 선택기 서명, 신뢰할 수 있는 인증 결과. 메시지를 생성한 서비스 제공자 컨텍스트 및 이벤트를 포함합니다.
수신된 메시지에서 DKIM d= 및 s=를 읽고 게시된 구성과 비교합니다. 선택자의 존재는 레코드가 사용 가능하다는 것만 증명합니다. 메시지는 실제로 유효한 서명을 사용해야 합니다. 수신자가 둘 이상의 서명을 보는 경우 모든 관련 서명을 보존하십시오. DKIM RFC 6376
DMARC 표시되는 보낸 사람 도메인에 대해 통과 정렬 인증 경로가 필요합니다. 회신 및 표시 이름은 해당 ID를 대체하지 않습니다. 공급자 봉투 도메인에 대한 SPF 패스는 SPF 부족과 공존할 수 있습니다. 조정, 정렬된 DKIM 여전히 DMARC 충족할 수 있습니다. 효과적인 정책에 따라 실제 메시지를 평가합니다. DMARC RFC 9989
한 클래스는 통과하고 다른 클래스는 실패하는 경우 공유 DNS 변경하기 전에 발신자 ID를 비교하세요. 사용자 작업 메시지는 에이전트 주소를 사용할 수 있지만 자동 알림은 다른 ID를 따릅니다. 메일이 전혀 전송되지 않은 경우 알림 이벤트와 사용 가능한 전송 증거를 먼저 확인하세요. 인증 레코드는 트리거가 없거나 의도적으로 억제된 대상을 수정할 수 없습니다.
오해의 소지가 있는 표시 이름의 가상 예
허구의 서면 사례에만 해당: SW-01은 사용자 작업 메시지에 Alex Support가 표시된다고 가정하지만 실제 보낸 사람은 공급자 서비스 주소로 유지됩니다. 회신 주소는 help@example.org 입니다. 정확한 공급자 주소, DKIM 및 SPF 결과는 알 수 없습니다. 관리자는 개인화된 이름과 인증된 개인화된 주소를 구별한 다음 에이전트 작업, 자동 알림 및 사고 대응 경로를 별도로 테스트해야 합니다. 이 증거를 대체하기 위해 수신 허용 목록을 변경하지 마세요. 서비스 계정, 사건 또는 메시지가 검사되지 않았습니다.
구현 워크시트 및 릴리스 제한
- 계정 컨텍스트: Service Desk 제품, 데이터 센터, ITSM 또는 ESM, 조직 또는 서비스 공급자 및 소유자.
- ID 인벤토리: 에이전트 도메인, 자동 알림 보낸 사람 값, 표시 이름 설정 및 회신 주소.
- DNS : 생성된 세 가지 CNAME, 기존 데이터, 정확한 게시 이름, TTL, 조회 시간 및 확인된 상태.
- 정책: SPF 소유자 및 승인된 메커니즘, 효과적인 DMARC 정책, 별도로 승인된 로컬 수신 예외.
- 테스트: 사건 참조, 트리거링 작업, 수신자, 보낸 사람, 회신, 봉투 ID, DKIM d=/s= 값 및 정렬 결과.
- 복구: 이전에 지원되는 설정, 종속성 전달, 알림 일시 중지 소유자 및 정리 검토.
라이브 계정 구성, 마이그레이션 상태, DNS , 수신된 헤더 및 스크린샷은 확인되지 않았습니다. 시각적 검토, 인간 SME 승인 및 출판이 보류 중입니다. 이 미공개 후보는 현재 문서화된 서비스 데스크 경로를 다루고 있습니다. 레거시 구성과 테스트되지 않은 서비스 제공업체 컨텍스트는 그대로 유지됩니다.
실행 준비 상태에서 전달 메시지를 분리합니다.
RFC 9989 섹션 7.4에는 도메인 게시를 위한 유효한 DKIM 필요합니다. p=reject 간접 메일 상호 운용성에 대한 주의 사항입니다. 단일 정렬된 SPF 결과만으로는 거부 정책 출시를 정당화하지 않습니다. 이 공급자 설정과 별도로 모든 합법적인 경로와 정책 소유권을 검토하세요.