올바른 계정 및 DNS 액세스 수집
Flodesk의 현재 수동 프로세스에는 사용자 정의 도메인 이메일 주소, Flodesk 계정에 대한 액세스 및 도메인의 DNS 관리자에 대한 액세스가 필요합니다. 등록자가 활성 영역을 호스팅한다고 가정하기보다는 누가 권한 있는 DNS 제어하는지 식별하십시오. 변경하기 전에 현재 기록, 특히 다른 마케팅 도구나 일반 사서함에서 사용되는 기록을 보존하십시오.
도메인 소유자가 수동 워크플로를 사용할지 아니면 자동 Entri 통합을 승인할지 결정합니다. 이는 다른 인증 프로토콜이 아닌 필수 레코드를 게시하는 대체 방법입니다. 검증이 보류 중이라는 이유만으로 두 가지를 반복적으로 실행하지 마세요.
계정의 수동 레코드 세트 사용
내 계정 > 도메인 설정을 열고 도메인 카드에서 지금 인증을 선택한 후 수동 옵션을 선택하세요. 현재 문서에서는 두 가지 가능한 세트를 설명합니다. 즉, 하나의 레코드로 구성된 5개의 레코드입니다. SPF, 삼 DKIM 그리고 하나 DMARC 레코드또는 각각 하나로 구성된 세 개의 레코드입니다. 계정에 따라 적용되는 세트가 결정됩니다. 고정된 개수를 복사하지 마십시오. 선택자 관련없는 튜토리얼에서.
정확한 소유자와 값을 얻으려면 각 복사 컨트롤을 사용하십시오. Flodesk는 지정합니다 CNAME SPF 및 DKIM 항목에 대한 기록과 TXT 레코드 ~을 위한 DMARC. 표시된 유형을 유지합니다. CNAME 은 다른 이름에 대한 DNS 별칭입니다. 기존 SPF 문자열 안에 붙여넣는 텍스트 메커니즘이 아닙니다.
특히 Flodesk는 SPF CNAME 을 기존 SPF TXT 정책과 결합하지 않고 별도의 레코드로 추가한다고 말합니다. 이는 한 소유자가 두 개의 v=spf1 정책을 게시하는 것이 안전하다는 의미는 아닙니다. 생성된 CNAME 에는 자체 소유자와 기능이 있습니다. 해당 소유자가 이미 호환되지 않는 데이터로 점유된 경우 다른 서비스를 덮어쓰는 대신 DNS 관리자와의 충돌을 중지하고 해결하십시오.
기존 DMARC 결정을 보존합니다.
수동 지침에는 DMARC 레코드가 이미 존재하지 않는 경우에만 표시된 DMARC TXT 레코드를 추가하라고 나와 있습니다. 표시된 정책은 정책이 없는 회원을 위한 것입니다. 두 번째 DMARC 레코드를 생성하거나 설정된 거부 또는 격리 정책을 설정 예시로 바꾸지 마세요.
도메인 관리자에게 정확한 정책 소유자와 현재 구성을 확인하세요. 인증이 성공하려면 해당 모드에서 유효하게 정렬된 SPF 또는 DKIM 경로가 필요합니다. 정책을 게시한다고 해서 캠페인이 정책을 충족한다는 증거는 아닙니다. 조직의 보고 및 집행 결정을 Flodesk에서 생성된 기록을 추가하는 메커니즘과 별도로 유지하십시오.
불필요한 재시작 없이 확인 완료
레코드를 게시한 후 Flodesk로 돌아가서 다음 및 완료를 완료합니다. 이 서비스는 DNS 자동으로 모니터링합니다. 문서에는 명시된 최대 48시간 동안의 보류 및 부분 확인 상태가 설명되어 있습니다. 모든 DNS 오류가 2일 후에 저절로 해결된다는 보편적인 보장은 아니지만 이를 공급자 지침으로 간주하십시오.
다른 레코드가 표시되는 동안 부분적인 상태가 발생할 수 있습니다. 먼저 신뢰할 수 있는 답변을 계정의 정확한 기록 세트와 비교하십시오. 중복된 도메인 접미사, 잘못된 레코드 유형, 잘못된 CNAME 대상 및 비활성 DNS 호스트에서 이루어진 편집 내용을 확인하세요. 올바른 기록이 표시되지만 문서화된 기간을 넘어 상태가 해결되지 않은 상태로 남아 있는 경우 인증을 반복적으로 다시 시작하는 대신 지원을 위해 기록 세트 및 상태를 수집하세요.
자동 대안 이해
자동 흐름은 도메인 설정에서도 시작됩니다. 자동 인증을 선택하고 Entri를 통해 도메인 공급자를 연결하세요. 소유자는 Entri가 DNS 레코드를 추가하는 데 필요한 액세스 권한을 승인합니다. 승인하기 전에 요청된 액세스 권한과 의도된 변경 사항을 검토하세요. 통합은 단순히 DNS 편집기의 다른 보기가 아닌 제3자입니다.
Flodesk는 지원되지 않는 공급자가 수동 옵션으로 이어진다고 말합니다. 자동 설정이 완료되지 않는 경우, 방법을 전환하기 전에 실제로 생성된 것이 무엇인지 확인하세요. 정책이 중복되거나 실수로 작업 기록이 교체되는 것을 방지하세요. 나중에 DNS 호스트를 변경하려면 새로 권한이 있는 영역에서 이러한 레코드를 보존해야 합니다. 등록기관 변경만으로는 DNS 이동되었거나 기록이 손실되었다는 증거가 아닙니다.
도메인 카드뿐만 아니라 캠페인도 확인하세요
생산 워크플로를 통해 원본 헤더를 검사할 수 있는 사서함으로 제어된 이메일을 보냅니다. 표시되는 보낸 사람 도메인, 봉투 도메인, 모든 DKIM 서명 도메인 및 선택기, 신뢰할 수 있는 수신자의 인증 결과를 기록합니다. 통과 경로를 확인하세요. 조정 검증된 카드가 향후 모든 경로를 보장한다고 가정하는 대신.
Flodesk 관찰이 아닌 예시 사례: From은 hello@example.com 이고 DKIM d=example.com. 이는 정확한 DKIM 정렬을 제공합니다. 관련되지 않은 봉투 도메인이 SPF 통과하는 경우 해당 결과만으로는 example.com 과 일치하지 않습니다. 나중에 서명 실패가 관련 없는 SPF 통과로 숨겨지지 않도록 두 결과를 모두 보존합니다.
복구 기록을 유지하고 DNS 호스트 마이그레이션이 완료되었다고 선언하기 전에 테스트하세요. 인증은 받은편지함 배치를 보장하지 않습니다. 평판, 메시지 내용, 수신자 결정은 별도로 유지됩니다. 이 가이드에는 자사 문서와 종합적인 예제만 포함되어 있습니다. 실제 DNS 변경, 테넌트 유효성 검사 또는 수신된 캠페인이 실행되지 않았으며 인간 생산 승인이 보류 중입니다.
목표물을 추측하지 않고 기록 충돌을 해결하세요
서면 사례 FL-01의 경우 Flodesk 패널이 여기에 bounce.example.com 으로 표시되는 생성된 소유자에게 CNAME 을 요청하지만 DNS 인벤토리에 동일한 소유자가 이미 작업 중인 것으로 표시된다고 가정합니다. 기록 관련없는 서비스에 대해. 이 소유자는 실제 Flodesk 생성 라벨이 아닌 예시용입니다. 요청한 CNAME 대상을 알 수 없습니다. A 레코드를 덮어쓰거나 대상을 루트 SPF TXT 에 붙여넣지 마십시오. DNS 소유자는 계속 진행하기 전에 종속성을 식별하고 공급자와 지원되는 충돌 해결 방법에 동의해야 합니다. 기존 DMARC 정책을 변경하지 않고 캠페인을 확인하지 않은 상태로 유지합니다. 이 경우에는 DNS 응답, 계정 부여 또는 메시지가 획득되지 않았습니다.
시행 경계 유지
RFC 9989 섹션 7.4에서는 도메인 게시를 위해 SPF 단독이 아닌 유효한 DKIM 필요합니다. p=reject, 간접 메일과 메일링 목록 상호 운용성에 대해 경고합니다. 단일 성공적인 직접 메시지 테스트가 모든 합법적인 경로가 더 강력한 정책을 수용할 준비가 되어 있다는 증거는 아닙니다. 실제 격차를 진단하는 동안 기존에 승인된 보호를 유지합니다. 모든 정책 변경에는 자체 결정이 필요합니다.