[ SPF ]

하나의 수신자 네트워크에 집중된 SPF 오류

한 수신자 네트워크의 오류를 해결하기 위해 SPF 변경하기 전에 실제 SMTP 경로, 평가된 ID 및 DNS 증거를 비교하십시오.

EmailAuth 연구팀 제공 · 3분 읽기

[ 핵심사항 ]

  • 인증을 변경하기 전에 실제 소스, ID, 정책을 비교하세요.
이 페이지에서

안 SPF 하나의 수신자 네트워크에만 국한된 것처럼 보이는 사건은 비교 문제입니다. 먼저 해당 네트워크가 성공적인 제어와 동일한 전송 IP, 봉투 도메인 및 DNS 정책을 평가했는지 여부를 설정하십시오. 광범위한 승인 변경을 통해 귀하의 도메인을 사용하여 보낼 수 있는 사람을 늘리면서 차이점을 숨길 수 있습니다.

일치된 비교 구축

동일한 애플리케이션과 대략적인 시간에서 실패한 거래와 성공한 거래를 선택하세요. IPv4 또는 IPv6 주소, SMTP 를 연결하여 UTC 시간을 기록합니다. 메일 보낸 사람, HELO 이름, 수신자 네트워크, 정확한 SMTP 응답, 메시지가 승인된 경우 신뢰할 수 있는 인증 결과. SMTP 중에 거부된 메시지에는 검사할 전달된 헤더가 없을 수 있습니다. 대신 보낸 사람의 트랜잭션 로그를 보존하세요. 식별자와 메시지 콘텐츠를 제한된 운영 증거로 처리합니다.

SPF 일반적으로 MAIL FROM 도메인을 평가합니다. null 역방향 경로의 경우 해당 MAIL FROM ID는 postmaster 및 HELO 도메인을 사용하여 구성됩니다. 보이는 보낸 사람 주소는 조회 명령이 아닙니다. 전달 서비스는 최종 수신자가 보는 연결 IP를 변경할 수도 있습니다. RFC 7208 , 섹션 2.3–2.4 및 10.3.

실패 클래스를 분리하세요.

명시적인 실패는 클라이언트에 권한을 부여하지 않은 평가된 경로를 가리킵니다. 퍼머러 정책 구문 검사가 필요합니다. SPF 레코드, 재귀 종속성 및 평가 한계. 일시적 오류 임시 조회 또는 처리 문제에 대한 조사가 필요합니다. 없음은 명시적인 금지가 아니라 사용 가능한 평가 도메인이 없거나 적용 가능한 SPF 레코드가 발견되지 않았음을 의미합니다. 중립은 정책이 명확한 승인 주장을 하지 않음을 의미합니다. softfail 실패보다 약한 부정적인 주장을 표현합니다. SPF 통과도 아닙니다. 일반적인 "인증 문제" 티켓을 해석하기 전에 결과를 캡처하세요.

신뢰할 수 있는 DNS 답변을 재귀 답변 및 타임스탬프와 비교하세요. 해당 IP에 대해 도달한 정확한 소유자 이름과 모든 종속성을 쿼리합니다. 평가된 SPF 의 10년 제한에는 a, mx, ptr이 포함되며 존재하는 메커니즘과 리디렉션 수정자, 모든 DNS 패킷이나 TXT 조각이 아닌 중첩 평가를 포함합니다. ip4, ip6 및 모든 메커니즘은 해당 기간 예산을 소비하지 않습니다. 다른 DNS 작업에는 별도의 제한이 적용될 수 있습니다. 따라서 정적 도구 스캔과 수신기의 실제 경로가 일치하지 않을 수 있습니다. RFC 7208 , 섹션 4.5–4.6.4 및 8.

통제된 예시를 통해 작업하기

예시 시나리오: 발신자는 인증된 IPv4 주소를 통해 네트워크 A에 도달하지만 목록에 없는 IPv6 주소를 통해 네트워크 B에 도달합니다. 애플리케이션 이름과 보낸 사람 주소가 동일해 보입니다. 유용한 개입은 IPv6 경로의 소유권과 의도된 사용을 확인한 다음 적절한 경우 이를 제한적으로 승인하거나 사용을 중지하는 것입니다. SPF 에 수신자 네트워크를 추가하면 연결의 잘못된 쪽이 해결됩니다.

두 번째 가능성은 전달입니다. 네트워크 B는 원래 아웃바운드 호스트가 아닌 중개자로부터 수신합니다. 정책에 임의 전달자를 추가하지 마십시오. 전달경로 확인, 생존 정렬 DKIM 그리고 수신자의 정책. 통과한 SPF 결과는 여전히 정렬되지 않을 수 있습니다. DMARC. RFC 9989 , 섹션 4.4.

재현 가능한 증거로 종결

소유자, 저장된 이전 값 및 롤백 조건으로 하나의 제어된 변경을 수행합니다. 사용된 두 주소군을 포함하여 영향을 받은 경로를 통해 일치 테스트를 반복합니다. SPF , 정렬된 인증, SMTP 처리를 별도로 확인하세요. 동일한 입력 및 정책이 여전히 다른 결과를 낳는 경우 수신 운영자를 위해 수정된 증거 패킷을 준비합니다. 전체 네트워크에 문제가 있다는 라벨을 붙이는 대신 해결되지 않은 구현 차이점을 기록하세요.

일치하는 증거 워크시트 사용

  • 실패/제어 쌍: 둘 다에 대해 UTC 시간, 애플리케이션 및 수신자 네트워크를 기록합니다.
  • 연결: 실제 IPv4 또는 IPv6 소스와 전달 홉을 비교합니다.
  • 신원: MAIL FROM, HELO 및 수신자가 실제로 확인한 도메인을 비교합니다.
  • 정책: 날짜가 적힌 TXT 답변과 평가된 종속성 경로를 유지합니다.
  • 결과: 실패, softfail , 중립, 없음, temperror 또는 permerror 와 SMTP 응답을 정확하게 보존합니다.
  • 조치: 검증된 차이점만 수정하십시오. 동일한 경로를 반복하고 에스컬레이션을 위해 해결되지 않은 차이점을 보관합니다.

[ 테이크아웃 ]

한 수신자 네트워크의 오류를 해결하기 위해 SPF 변경하기 전에 실제 SMTP 경로, 평가된 ID 및 DNS 증거를 비교하십시오.

[ 역할별 ]

이것이 당신에게 의미하는 바

실용적인 다음 단계를 위해 역할을 선택하세요.

IT/메일 관리자

SMTP IP 및 봉투 ID를 캡처합니다.

IP, MAIL FROM, HELO , 타임스탬프 및 DNS 스냅샷과 함께 쌍을 이루는 거래 기록을 유지하세요. 성공적인 대시보드 확인은 실제 실패한 경로 재생을 대체할 수 없습니다.

다음 단계

  1. SMTP IP 및 봉투 ID를 캡처합니다.
  2. IPv4 , IPv6 및 전달 경로를 비교하십시오.
  3. 변경 후 정확히 실패한 경로를 다시 테스트하십시오.

CISO/SecOps

새로 승인된 주소의 소유권을 확인하세요.

새 주소 범위에 대해 명명된 소유자를 요구하고 변경 전 정책을 유지합니다. 수신자 집중은 유용한 사고 증거이지만 관련되지 않은 네트워크를 승인하는 것을 정당화하지는 않습니다.

다음 단계

  1. 새로 승인된 주소의 소유권을 확인하세요.
  2. 이전 권한 집합을 유지합니다.
  3. 해결되지 않은 수신자 차이점을 문서화하세요.

창립자 / 비기술자

영향을 받는 고객 워크플로를 식별합니다.

어떤 비즈니스 메시지가 영향을 받았는지, 실패한 경로가 성공한 경로와 다른지 물어보세요. 보낸 사람 권한을 전면적으로 완화하는 대신 좁은 범위의 복구 변경을 승인합니다.

다음 단계

  1. 영향을 받는 고객 워크플로를 식별합니다.
  2. 하나는 실패했고 하나는 성공한 비교를 요청합니다.
  3. 정당하고 제한된 복구 변경만 승인합니다.

[ 자주 묻는 질문 ]

자주 묻는 질문

한 수신자에게는 실패가 표시되고 다른 수신자에게는 통과가 표시되는 이유는 무엇입니까?

그들은 서로 다른 연결 IP, 전달 경로, ID, 캐시된 DNS 데이터 또는 평가 동작을 볼 수 있습니다. 결론을 내리기 전에 이러한 입력을 비교하십시오.

수신자 네트워크를 SPF 에 추가해야 합니까?

아니요. SPF 평가된 도메인에 대해 승인된 전송 호스트를 설명합니다. 수신자 네트워크는 자동으로 아웃바운드 발신자가 되지 않습니다.

IPv6 차이점을 설명할 수 있습니까?

예. 정책이 IPv4 소스만 승인하는 동안 경로는 IPv6 를 통해 전송할 수 있습니다. 수정하기 전에 실제 연결 주소와 의도한 서비스를 확인하세요.

실패한 메시지에 헤더가 없으면 어떻게 되나요?

SMTP 트랜잭션 로그와 정확한 거부 응답을 사용하세요. 배달 전에 거부된 메시지에는 검사할 수신자 측 사본이 없을 수 있습니다.

permerror 소스 IP가 승인되지 않았음을 의미합니까?

이는 정책을 성공적으로 해석하거나 평가할 수 없음을 의미합니다. 정상적인 실패로 처리하기보다는 원인을 진단하십시오.

현재 DNS 조회를 통해 어제 발생한 일이 입증됩니까?

아니요. 동시 답변과 구성 기록을 유지하세요. 현재 DNS 문제를 재현하는 데 도움이 되지만 수신자의 이전 보기와 다를 수 있습니다.

SPF 실패에도 불구하고 DMARC 통과할 수 있나요?

예, 유효한 DKIM 서명이 작성자 도메인과 일치하는 경우 가능합니다. 수신기 처리 및 기타 요구 사항은 별도로 유지됩니다.

에스컬레이션에는 어떤 증거가 포함되어야 합니까?

수정된 시간, 연결 주소, 평가된 ID, 정확한 결과 또는 SMTP 응답, 정책 스냅샷 및 일치하는 성공 제어를 제공합니다.

[ 출처 ]

출처

  1. RFC7208

    섹션 §2.3–2.4; 4.5–4.6.4; 8; 10.3

  2. RFC8601

    섹션 §1.2; 7.1

  3. RFC9989

    섹션 §4.4

[ 어휘 ]

어휘

SPF
연결 IP 주소가 평가된 SMTP 도메인을 사용할 권한이 있는지 확인합니다.
메일 보낸 사람
배달 오류 처리 및 일반적으로 SPF 평가에 사용되는 SMTP 역방향 경로 ID입니다. 표시되는 From 헤더와는 다릅니다.
DMARC 정렬
From의 작성자 도메인과 성공적으로 인증된 SPF 또는 DKIM 도메인 간의 필수 관계입니다.

기업 출처

최고의 금융 기관과 정부가 필요한 이유 이메일 보안 대시보드를 폐기했습니다.

기존 이메일 인증 플랫폼은 대시보드를 판매하고 엔지니어에게 작업을 요청합니다. 위험이 높은 환경에서 수동 감독은 시행 지연, 구성 드리프트 및 모니터링되지 않는 섀도우 도메인을 의미합니다.

EmailAuth 는 에이전트 이메일 출처 플랫폼입니다. 우리 대리인은 집행합니다 p=reject, 제3자 발신자를 정렬하고 도메인을 전체로 이동하세요. RFC 9989 인간 참여형 감사 기능을 갖춘 새로운 DMARC 표준을 준수합니다.

정부 대기업 1등급 금융기관

SaaS · 전용 테넌시 · Air-Gapped 온프레미스 · BYOK 암호화

기술 자료