입찰 통지서는 진짜일 수 있지만 계정 손상 후 승인되지 않은 은행 세부 정보 변경이 포함될 수 있습니다. 인증은 도메인 ID를 평가하는 데 도움이 됩니다. 조달 권한은 승인된 프로세스와 책임 있는 사람들로부터 나옵니다. 하나가 다른 것을 대체할 수 없도록 서로를 강화하도록 두 개의 수표를 설계합니다.
통지를 조달 기록에 매핑
입찰 공시, 공급자 공지 및 위임된 조달의 경우 기록 시스템, 공지 식별자, 승인된 발송인 및 책임 있는 계약 역할을 기록합니다. 통지는 공급업체가 알려진 채널을 통해 권위 있는 조달 기록을 찾는 데 도움이 되어야 합니다. 예상치 못한 메시지의 링크를 동일한 메시지에 대한 독립적인 확인으로 간주하지 마세요.
애플리케이션 테넌트, From 도메인, 봉투 도메인, DKIM 도메인과 선택자 각 경로마다. 아웃소싱 조달 포털에는 해당 기관의 직원 메일과 별도의 전송 인프라가 있을 수 있습니다. 브랜드 바닥글이나 회신 주소는 정렬된 인증 경로를 설정하지 않습니다. 진짜 통지는 회신을 다른 운영 사서함으로 보낼 수 있으므로 경로 맵에서 회신 처리를 유지하세요.
자체 승인 뒤에 결과적 변경 사항 유지
수신자에게 무엇을 요청하는지에 따라 통지를 분류합니다. 공개 공개 발표, 마감일 수정, 낙찰 통지 및 지불 세부 사항 요청은 운영상의 결과가 다릅니다. 이 가이드에서는 분쟁 대상 이메일에 제공된 전화번호가 아닌 확립된 연락처 기록을 사용하여 민감한 공급업체 또는 은행 변경 사항에 대해 별도의 조달 및 재정 확인을 권장합니다.
DMARC 입찰 조건을 검사하거나 누가 낙찰을 승인했는지 결정하지 않습니다. 또한 통과 서명이 은행 계좌가 의도한 공급업체에 속한다는 사실을 입증하지도 않습니다. 변경 권한, 승인된 기록 및 독립적인 검증 결과를 조달 시스템에 보관합니다. 이는 작업 흐름 권장 사항이며 관할권의 조달 법률에 대한 설명이 아닙니다.
마감일 전에 위임된 발신자 테스트
허구의 입찰 세부정보와 함께 최초 통지, 수정 및 취소를 위해 승인된 샘플을 실행합니다. 의도한 From 신원, 서명 결과, 해당 여부를 확인합니다. 조정, 응답 대상 및 공식 기록에 대한 성공적인 액세스. 서명 테스트에서는 통지가 법적 기한 이전에 도착했음을 입증할 수 없습니다. 관련 전달 및 출판 증거를 별도로 보존합니다.
계약자가 활성 입찰 중에 플랫폼을 변경하는 경우 승인된 전환 및 대기열 처리가 이해될 때까지 이전 경로를 유지하십시오. 실패한 통지에 대한 소유자와 문서화된 대체 통지 프로세스를 설정합니다. 통합이 실패했기 때문에 새 ID를 통해 알림을 자동으로 다시 제출하지 마세요. 이러한 변경은 공급업체를 혼란스럽게 할 수 있으므로 조달팀이 승인한 커뮤니케이션 프로세스에 따라 처리되어야 합니다.
공급업체와의 경계 재평가
부서의 전체 메일량뿐만 아니라 조달 서비스별로 보고서를 검토합니다. 겉보기에 정상인 집계는 적은 양의 수정안 보낸 사람을 숨길 수 있습니다. 예상치 못한 서명 도메인, 새로운 회신 대상 및 소유되지 않은 공급업체 계정을 에스컬레이션하세요. 도메인 또는 선택기를 폐기하기 전에 해당 도메인 또는 선택기에 여전히 의존하는 입찰 기록과 반복 알림을 설정하세요. 인증 증거는 조달 감사 기록을 대신하는 것이 아니라 옆에 속합니다.
세 가지 서면 경로 기록을 통해 작업
이러한 예약된 예제 도메인, 선택기, 역할 및 DKIM 전제 전달은 가상입니다. 이러한 경우에는 서명된 메시지, 키, 암호화 확인, DNS 조회, SMTP 트랜잭션 또는 라이브 서비스 테스트가 제공되거나 실행되지 않습니다. 아래 추론을 검사하는 데는 테스트 코드나 외부 표본이 필요하지 않습니다.
- 입찰 게시: 도메인 입찰에서 볼 수 있습니다 tenders.civic.example ; DKIM d=tenders.civic.example; 선택기 데모1; 이 서면 케이스에 대해서만 DKIM 통과를 가정합니다. SPF 메일 보낸 사람 신원 및 결과는 알 수 없음; 다른 서명은 알려져 있지 않습니다. 실제 정책 발견 및 전달은 알 수 없습니다. 제안 소유자: 조달 책임자. 다음 작업: 이 테넌트에 대해 승인된 샘플과 신뢰할 수 있는 수신자 결과를 얻습니다.
- 공급자 공지: 도메인 suppliers.civic.example 에서 볼 수 있습니다. DKIM d=suppliers.civic.example; 선택기 데모2; 이 서면 케이스에 대해서만 DKIM 통과를 가정합니다. SPF MAIL FROM 신원 및 결과는 알 수 없습니다. 다른 서명은 알려져 있지 않습니다. 실제 정책 발견 및 전달은 알 수 없습니다. 제안된 소유자: 공급업체 커뮤니케이션 소유자. 다음 작업: 첫 번째 경로의 결과를 상속하는 대신 이 별도의 경로와 해당 비즈니스 이벤트를 확인합니다.
- 위임된 조달: 도메인 contracts.civic.example 에서 표시됩니다. DKIM d=provider.example.net; 선택기 데모3; 이 서면 케이스에 대해서만 DKIM 통과를 가정합니다. SPF MAIL FROM 신원 및 결과는 알 수 없습니다. 다른 서명은 알려져 있지 않습니다. 실제 정책 발견 및 전달은 알 수 없습니다. 제안 소유자: 계약 당국. 다음 작업: 이 테넌트가 지원하는 정렬된 서명 경로에 대해 확인된 공급업체에 문의하세요. 전체 네트워크로 인증을 확대하지 마십시오.
처음 두 개의 규정된 서명의 경우 d=는 From 도메인과 정확히 동일하므로 식별자는 엄격한 정렬과 완화된 정렬을 모두 충족합니다. 규정된 성공적인 DKIM 결과를 바탕으로 해당 가상 메시지에 대해 정렬된 인증 경로가 존재합니다. 세 번째 서명자는 의도적으로 작성자 도메인과 관련이 없으며 정렬된 경로를 제공할 수 없습니다. 세 번째 메시지를 DMARC 실패라고 부르지 마세요: SPF 정렬 또는 다른 정렬 통과 DKIM 서명 여전히 메커니즘을 만족할 수 있으며 해당 입력은 알 수 없습니다. 어떤 행에서도 실제 배포나 받은 편지함 배치를 추론하지 마세요.
암호화 서명은 모든 명령의 진실성이나 승인이 아니라 서명 도메인의 책임을 인증합니다. 해당 정규화된 바이트를 변경하면 서명이 무효화될 수 있습니다. 눈에 보이는 모든 편집 내용이 반드시 서명된 입력을 변경하는 것은 아닙니다. 인증과 애플리케이션 수준 승인은 별도로 유지됩니다.
공지사항별 수락카드 사용
가상 입찰 T-01 수정 버전 2의 경우 승인된 기록 버전, 승인된 계약 역할, 신원 확인, 응답 대상, 게시 시간 및 수신자 알림 증거가 필요합니다. 인증이 통과되었지만 공식 기록이 버전 1로 유지되는 경우, 수정 사항을 중지하고 조달과 조정하십시오. 승인된 라벨을 붙이지 마십시오. 기록은 정확하지만 통지가 실패하는 경우 이미 승인된 대체 통지 프로세스를 호출하고 시기적 증거를 보관하십시오. 변경된 수혜자는 결과에 관계없이 별도의 재정 확인 프로세스를 시작합니다. 이는 조달법 요구 사항이나 완료된 테스트가 아닌 제안된 결정입니다.
준수를 주장하지 않고 표준을 적용합니다.
RFC 9989 섹션 4.4 및 5.3.5 정렬 및 메커니즘 구별을 지원합니다. 섹션 7.4에서는 간접 메일 상호 운용성에 대해 경고합니다. p=reject SPF 만 사용하는 것이 아니라 유효한 DKIM 사용해야 하며, 범용 메일링 리스트를 사용하려면 특별한 주의가 필요합니다. 경로 인벤토리 자체는 거부를 시행할 수 있는 권한이 아닙니다. RFC 6376 섹션 3.4–3.7 및 6.1 서명된 입력 및 확인을 설명합니다. RFC 9990 섹션 3.1 수신자별 도착 증명이 아닌 보고 컨텍스트를 제공합니다. RFC 5321 섹션 4.2.5 서버 승인 책임과 이후 전달 결과를 구별합니다. 여기에서 선택한 부문 워크플로는 편집자 권장 사항입니다. 법적 범위, 요소 적합성 및 현지 승인에는 책임 있는 자체 검토가 필요합니다.