잘못된 도메인 오류는 하나의 오류에 대한 표준화된 설명이 아니라 조사하기 위한 진단입니다. 이름은 구문이 잘못되었거나, 구문이 유효하지만 존재하지 않거나, 일시적으로 확인할 수 없거나, 메일 라우팅에 적합하지 않거나, 서버의 로컬 ID 정책에 의해 거부될 수 있습니다. DNS 편집하기 전에 전체 진단과 그것이 참조하는 필드를 보존하십시오. 잘못된 이름을 변경하면 오류를 해결하지 못한 채 메일 작업이 중단될 수 있습니다.
분야와 문법을 파악하세요
참고자료: RFC 5321 §2.3.5, RFC 5321 §4.1.2.
거부된 값이 다음 위치에 있는지 기록합니다. EHLO, 메일 보낸 사람, RCPT TO, 표시되는 헤더 또는 DNS 레코드입니다. 이러한 컨텍스트는 하나의 보편적인 문법을 공유하지 않습니다. 일반 SMTP 도메인 이름의 경우 RFC 5321 레이블 규칙을 정의하고 주소 리터럴을 별도로 논의합니다. _dmarc 또는 _domainkey 와 같은 특수 DNS 소유자 이름에 밑줄이 사용된다는 이유만으로 SMTP 호스트 이름의 밑줄이 유효해지지 않습니다.
RFC 5321 섹션 2.3.5 및 4.1.2 SMTP 도메인 구문의 적절한 시작점입니다. 모든 이메일 주소, 국제화된 주소 또는 DNS 레코드의 유효성을 검사하기 위해 단순한 호스트 이름 정규식을 사용하지 마십시오. 로컬 고정 장치는 의도적으로 제한된 ASCII 문자-숫자-하이픈 이름 하위 집합만 포함하고 해당 제한을 보고합니다.
구문과 분리된 해상도
참고자료: RFC 1035 §4.1.1, RFC 5321 §5, RFC 7505 §3.
구문적으로 유효한 이름은 NXDOMAIN 반환할 수 있으며, 이는 쿼리된 이름이 해당 DNS 응답에 존재하지 않음을 나타냅니다. SERVFAIL 과 같은 일시적인 해결 실패는 존재하지 않는 것과 동일하지 않으며 새로운 방법을 고안하여 복구해서는 안 됩니다. SPF 레코드. 쿼리된 소유자, 유형, 확인자, 응답 상태, 답변 및 타임스탬프를 보존합니다. 권한이 있는 경우 조직의 정상적인 진단 프로세스를 통해 권한 있는 데이터 및 위임을 확인합니다.
수신자 라우팅의 경우 도메인에 웹사이트가 있는지 여부만 테스트하기보다는 MX 및 해당 SMTP 대체 규칙을 검사하세요. 도메인은 메일을 수락하지 않고도 웹용으로 확인할 수 있습니다. null MX 도메인이 메일을 허용하지 않음을 명시적으로 나타냅니다. 그것은 실종이 아니다 MX 레코드 임의로 교체합니다. RFC 7505 이 구별을 정의합니다. 호스트의 A 또는 AAAA 기록 메일 서비스가 작동하고 있다는 증거가 아닙니다.
레코드 파서 오류를 별도로 유지
참고자료: RFC 7208 §4.5, RFC 7208 §4.6, RFC 7208 §6.
인증 레코드에는 DNS 소유자 이름이 유효하지만 잘못된 메커니즘, 충돌하는 레코드 또는 지원되지 않는 구성이 있을 수 있습니다. 그것은 기록 해석 문제입니다. 중복된 SPF 레코드는 잘못된 도메인 라벨이 아닙니다. 반대로 올바른 모습 SPF 값은 클라이언트가 사용하는 잘못된 호스트 이름을 복구할 수 없습니다. 일반 도메인 검사기를 최종 권한으로 사용하는 대신 특정 레코드에 대한 파서 및 사양을 따르세요.
유지된 오프라인 픽스처는 좁은 호스트 이름 문법에서 mail.example .test를 유효한 것으로 분류하고, bad_name.example.test 및 - bad.example .test를 잘못된 것으로 분류하고, missing.example .test를 구문적으로 유효한 것으로 분류합니다. 별도의 합성 DNS 매핑은 누락된 이름 NXDOMAIN , 다른 이름 SERVFAIL 및 예제 MX 응답을 null MX 로 표시합니다. 공개 DNS 쿼리나 프로덕션 수정은 수행되지 않습니다. 이 연습에서는 이러한 상태가 하나의 빨간색 표시기로 축소되어서는 안 되는 이유를 보여줍니다.
확인된 원인만 수리
참고자료: RFC 5321 §4.2.
구문의 경우 생성 중인 애플리케이션 또는 구성된 ID를 수정하세요. DNS 존재하는 경우 레코드를 추가하기 전에 소유권과 의도한 서비스를 확인하세요. 일시적인 DNS 오류의 경우 확인자 또는 신뢰할 수 있는 가용성을 조사하세요. SMTP 정책의 경우 전체 서버 응답 및 현재 공급자 설명서를 읽어보세요. 오류를 침묵시키기 위해 유효한 ID를 관련 없는 도메인으로 바꾸지 마십시오.
변경 후에는 동일한 트랜잭션이나 쿼리를 반복하고 두 결과를 모두 유지합니다. 유효한 구문 결과, 성공적인 DNS 응답 및 수락된 SMTP 명령은 별도의 체크포인트입니다. 원래 실패한 작업이 의도한 보안 및 라우팅 정책에 따라 작동하는 경우에만 인시던트를 종료합니다.
실제 SPF 파서 결과 비교
참고자료: RFC 7208 §4.5, RFC 7208 §4.6, RFC 7208 §6.
2026년 11월 7일에 유지된 파서 테스트는 원래 토큰 화이트리스트 대신 pyspf 2.0.14를 사용합니다. DNS 조회 후크는 parser.test에 대한 고정 TXT 응답을 제공하고 네트워크 조회를 수행하지 않습니다. 주석이 달린 긍정적인 레코드는 v=spf1 ip4:127.0.0.2 -all 입니다. 버전은 SPF 선택하고 ip4는 제어된 원본 주소를 승인하며 -all 다른 호스트에 실패합니다. 파서는 127.0.0.2 의 쿼리에 대해 패스를 반환합니다.
메커니즘을 가짜 반품으로 교체 permerror 알려지지 않은 메커니즘이 무시되지 않기 때문입니다. 선택된 v=spf1 레코드 두 개를 반환하면 호스트 승인 여부와 관계없이 permerror 반환됩니다. 긍정적인 레코드에 future=abc 추가하면 패스가 반환됩니다. 이는 구문적으로 유효한 알 수 없는 수정자이며, RFC 7208 섹션 6에서는 평가자가 무시하도록 요구합니다. 네 가지 경우 모두 레코드 주석과 정확한 입력, 예상 결과, 실제 결과 및 파서 설명이 유지됩니다. RFC 7208 섹션 4.5, 4.6 및 6을 참조하세요.
이러한 관찰은 잘못된 메커니즘, 여러 개의 선택된 레코드 및 알 수 없는 수정자를 지원되지 않는 하나의 레이블로 축소하는 대신 분리합니다. 이는 공개 DNS 관찰이나 철저한 SPF 적합성 제품군이 아닌 제어된 DNS 입력을 사용한 파서 테스트입니다. 또한 호스트 이름 구문 결과를 변경하지 않습니다. 레코드 의미와 레코드를 포함하는 도메인 이름은 별개의 레이어입니다. 원본 화이트리스트는 이러한 표준 기반 결론의 소스가 아닌 레이블이 지정된 역사적 하위 집합 예시로만 유지됩니다.