Google Workspace DMARC 설정에는 4개의 연결된 단계가 있습니다. 도메인에 보낸 사람을 확인하고 해당하는 항목을 게시합니다. SPF 그리고 DKIM 기록하고, 선택한 도메인에 대해 DKIM 서명을 시작하고, DMARC 정책을 사용하기 전에 결과 메시지를 확인하세요.
DNS 게시와 서명은 별도의 관찰입니다. 서비스가 아직 서명되지 않은 동안 DKIM 키가 표시될 수 있으며, 웹사이트나 청구 애플리케이션이 다른 공급자를 사용하는 동안 직원 메일이 올바르게 인증될 수 있습니다. 각 중요한 서비스에 대한 전체 경로를 따르십시오.
선택한 도메인과 기존 구성을 확인하세요.
선택한 도메인, 해당 도메인의 신뢰할 수 있는 DNS 호스트, 현재 레코드 및 작업에 필요한 Google 관리 권한을 확인하세요. 기존 구성을 저장합니다.
유효한 SPF 정책과 작동 중인 사용자 지정 도메인 DKIM 서명이 이미 존재하는지 확인하세요. 단지 첫 번째 단계부터 새로운 지침을 따르기 위해 작동 키를 재생성하거나 기존 정책을 교체하지 마세요.
직원 메일, 별칭 또는 보조 도메인, 게이트웨이 및 외부 애플리케이션에 대한 경로 목록을 만듭니다. 각각의 중요한 ID에 대해 별도의 수신 메시지 테스트를 계획하세요.
Workspace 외부로 전송하는 서비스 포함
웹사이트, 회계 시스템, 지원 플랫폼에서는 다른 제공업체를 이용하는 반면 Google Workspace 직원 메일을 처리할 수 있습니다. 작업공간 설정은 소유권을 자동으로 설정하거나 조정 그 서비스를 위해.
팀에 고객을 대면하는 각 발송인과 비즈니스 소유자의 이름을 물어보세요. 로그인 링크, 결제 영수증 등 용량은 적지만 중요한 메일을 포함하세요. 그런 다음 Gmail 테스트에 성공했다고 가정하기보다는 실제 애플리케이션에서 확인 결과를 요청하세요.
누군가 도메인의 DNS 계정과 보고 대상을 소유하고 있는지 확인하세요. 이전 계약자가 기록을 통제하거나 아무도 읽지 않는 사서함에 보고서가 도착하면 인증을 유지하기가 어려워집니다.
적절한 SPF 정책 게시
** Google Workspace 통해서만 ** 전송하는 도메인에 대한 Google의 현재 문서화된 예는 다음과 같습니다.
v=spf1 include:_spf.google.com ~all가정이 맞는 경우에만 사용하십시오. 혼합 서비스 도메인의 경우 단일 SPF 정책을 변경하기 전에 기존 권한과 실제 봉투 ID를 검토하세요. 공급자의 자체 봉투 도메인을 사용하는 별도의 애플리케이션에는 지원되는 다른 정렬 접근 방식이 필요할 수 있습니다.
그만큼 ~all 한정자는 일치하지 않는 소스에 대해 SPF softfail 생성합니다. Softfail은 DMARC 에 대한 SPF 통과 결과가 아니며 모든 수신자가 메시지를 스팸에 넣도록 강제하지 않습니다. 수신자 처리 및 별도의 DMARC 결정은 여전히 유효합니다.
중첩된 종속성을 포함하여 SPF 평가 경로를 확인하세요. 최상위 레코드에 표시되는 포함 수를 계산하는 것만으로는 충분하지 않습니다.
선택한 도메인의 DKIM 키 생성 및 게시
Google 관리 콘솔에서 앱, Google Workspace , Gmail , 이메일 인증으로 이동합니다. 올바른 도메인을 선택하세요. 새로운 서명 설정인 경우 새 레코드 생성 및 지원되는 키 설정을 사용하세요.
Google은 2048비트 키 DNS 공급자가 지원하는 경우. 기본값 선택자 ~이다 Google; 기존 선택기 충돌에는 덮어쓰기보다는 지원되는 다른 선택기가 필요합니다.
콘솔에서 생성된 DNS 호스트 이름과 공개 키 값을 복사합니다. 해당 ** TXT ** 레코드를 권한 있는 DNS 영역에 게시합니다. 일반적인 친척 소유자 이름은 다음과 같습니다. Google. _domainkey, 그러나 선택한 도메인의 생성된 값과 DNS 편집기의 명명 모델을 사용합니다.
개인 키는 DNS 에 게시되지 않습니다. 기사의 단축된 샘플 키를 붙여넣거나, 다른 도메인의 키를 재사용하거나, 다른 서비스의 선택기를 자동으로 교체하지 마세요.
결과 이름에서 공개 답변을 확인하세요.
TXT google._domainkey.example.com +짧게 살펴보기이 명령은 예시입니다. 도메인과 해당하는 경우 선택기를 바꿉니다. 공개 TXT 답변은 Workspace가 서명을 시작했다는 의미가 아니라 주요 게시를 보여줍니다.
서명 시작 및 수신된 메시지 검사
키를 공개하고 확인한 후 선택한 도메인의 이메일 인증 설정으로 돌아가 인증을 시작하세요. 결과 상태를 검토합니다.
Google 안내에서는 자신에게 메시지를 보내는 대신 다른 Gmail 또는 Google Workspace 수신자와 함께 테스트하는 방법을 설명합니다. 수신자 측에서 원본 메시지를 열어 신뢰할 수 있는 인증 결과를 검사하고 DKIM-Signature.
서명 도메인, 선택기 및 표시되는 보낸 사람 도메인과의 정렬을 확인하세요. 다른 도메인에 대한 패스는 도메인의 정렬 경로를 설정하지 않습니다. 관련 별칭, 보조 도메인, 게이트웨이 및 애플리케이션 경로에 대해 테스트를 반복합니다.
- 레이어: DNS ; 대답할 질문: 생성된 공개 키가 의도한 이름으로 게시됩니까?
- 레이어: 작업 공간; 답변할 질문: 선택한 도메인에 대해 서명이 활성화되어 있습니까?
- 레이어: 받은 메일; 대답할 질문: 관련 서명이 전체 경로 이후에 확인되고 정렬됩니까?
- 레이어: 비즈니스 작업흐름; 답변할 질문: 서비스 사용자가 보낸 메시지가 실제로 의존했습니까?
- ovider 설정 및 DNS 캐싱에는 시간이 걸릴 수 있습니다. Google은 또한 새로 활성화된 Gmail 서비스의 키 생성 전 준비 지연을 문서화합니다. 실제 상태와 현재 지침을 사용하십시오. 하나의 보편적인 완료 시간을 약속하지 마십시오.
DMARC 정책 게시 및 확인
새로 모니터링되는 도메인의 경우 동일한 도메인 보고 예는 다음과 같습니다.
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com해당하는 곳에 게시하세요. _dmarc 이름을 입력하고 승인된 실제 수집 주소를 사용하고 보고서 도착 및 처리를 확인하세요. Google은 현재 DMARC 설정 단계 전에 SPF / DKIM 작업을 최소 48시간 허용할 것을 권장합니다. 그 준비 기간 자체만으로는 더 강력한 정책을 시행할 준비가 되어 있지 않습니다.
도메인에 이미 정책이 있는 경우 자동으로 모니터링으로 교체하는 대신 정책을 평가하세요. 그만큼 DMARC 레코드 워크플로에서는 DNS 확인을 실제 메시지 증거에 연결하는 방법을 설명합니다.
서비스가 변경되더라도 보장을 유지하세요
발신자 인벤토리 및 중요 흐름 테스트에 대한 구현을 검토합니다. 하나의 도메인에 대한 설정이 모든 보조 도메인이나 외부 알림 서비스의 상태를 증명하지는 않습니다.
Workspace 및 DNS 관리 계정에 대한 명확한 액세스가 필요합니다. 기록 승인된 변경 사항, 유지 관리된 선택자 목록 및 책임 있는 보고서 검토 프로세스. 팀이 새로 도입된 애플리케이션이나 중단된 서비스를 처리하는 방법을 정의합니다.
도메인 인증과 계정 보안을 구분하세요. 손상된 인증 계정은 인증된 메시지를 보낼 수 있습니다. 또한 DMARC 패스는 받은 편지함 배치를 보장하거나 비즈니스 요청이 적법하다는 것을 입증하지 않습니다.
실용적인 테이크아웃
DNS 증거, 서명 상태 및 수신된 메시지 결과를 동일한 수락 기록에 유지합니다. 이를 통해 게시 문제와 서명 문제 또는 여전히 구성이 필요한 별도의 응용 프로그램을 구별할 수 있습니다.
프로젝트 종료로 인한 부분적인 성공 유지
서면 사례 GW-01에서 user@example.com 에 s=google을 사용하는 d=example.com 전달 서명이 있다고 가정합니다 s=google. 규정된 메시지에는 정렬된 DKIM 경로가 있습니다. 동일한 보낸 사람 도메인을 사용하는 송장 애플리케이션에는 아직 신뢰할 수 있는 수신 메시지 증거가 없습니다. DKIM 및 SPF 결과는 아직 알려지지 않았습니다. 가정된 사례 내에서만 조건부로 입증된 직원 메일을 표시하고 청구서 경로를 해당 응용 프로그램 소유자에게 해결되지 않은 상태로 둡니다. 이 가이드에서는 Google 테넌트, 메시지, DNS 레코드 또는 서명 작업이 테스트되지 않았습니다.
시행 경계 유지
RFC 9989 섹션 7.4에서는 도메인 게시를 위해 SPF 단독이 아닌 유효한 DKIM 필요합니다. p=reject, 간접 메일과 메일링 목록 상호 운용성에 대해 경고합니다. 단일 성공적인 직접 메시지 테스트가 모든 합법적인 경로가 더 강력한 정책을 수용할 준비가 되어 있다는 증거는 아닙니다. 실제 격차를 진단하는 동안 기존에 승인된 보호를 유지합니다. 모든 정책 변경에는 자체 결정이 필요합니다.