[ DNS 및 도메인 ]

이메일을 허용하지 않는 도메인에 대한 Null MX 레코드

이메일을 보낼 수 없거나 해당 하위 도메인이 선언을 상속한다는 뜻을 실수로 암시하지 않고 도메인이 이메일을 수락하지 않는다고 선언합니다.

EmailAuth 연구팀 제공

[ 핵심사항 ]

  • 유일한 MX 0 점은 이 정확한 도메인이 메일을 허용하지 않음을 선언합니다.
  • Absent MX 와 Null MX SMTP 라우팅 동작이 다릅니다.
  • 재고 수령 요구 사항을 검토하고 발송 관리를 별도로 검토합니다.
이 페이지에서

없는 도메인 MX 레코드 반드시 메일을 거부하는 도메인은 아닙니다. MX 데이터가 없을 경우 SMTP 주소 조회로 대체될 수 있습니다. Null MX 도메인이 이메일을 허용하지 않고 모호한 대체를 피하기 위해 존재합니다.

명시적인 서비스 불가 답변 게시

참고자료: RFC 7505 §3.

RFC 7505 Null MX 기본 설정 0과 루트 도메인을 교환으로 사용하는 단일 MX 레코드로 정의합니다. example.com . 300 입력 MX 0 .. 점은 의미가 있습니다. 호스트 이름에 대한 자리 표시자가 아니며 로컬호스트 동일하지 않습니다. Null MX 광고하는 도메인은 다른 MX 레코드도 광고하면 안 됩니다.

해당 도메인의 주소가 메일을 수신할 필요가 없음을 확인한 후에만 Null MX 사용하십시오. 계정 복구, 조달, 법적 고지, 역할 계정 및 소량 운영 주소를 인벤토리에 포함합니다. 명백히 비활성 도메인이라도 누군가의 복구 주소가 될 수 있습니다.

수신과 송신 제어를 분리

참고자료: RFC 7505 §4.2, RFC 7208 §5.1, RFC 9989 §4.10.1.

Null MX 는 수신 선언입니다. 아웃바운드 메일을 인증하지 않으며, SPF 정책을 적용하거나 도메인을 가장으로부터 면역되게 만듭니다. RFC 7505 수신자가 해당 메일을 거부할 수 있으므로 SMTP MailFrom 또는 메시지 보낸 사람 주소에 사용되는 도메인에서 Null MX 권장하지 않습니다. Null MX 무해한 아웃바운드 설정으로 취급하는 대신 합법적인 발신자를 위해 검토된 수신 및 반송 주소 설계를 사용합니다.

보내거나 받지 않는 도메인의 경우 명시적인 아웃바운드 제어를 별도의 변경 사항으로 평가합니다. SPF v=spf1 -all 보낸 사람이 승인되지 않은 경우 정확한 SPF 신원을 거부하는 예시입니다. 에이 DMARC 정책에는 정책 범위, 하위 도메인 및 보고에 대한 명시적인 평가가 필요합니다. 인벤토리 전송이 불완전한 도메인에 일반 제어 세트를 붙여넣지 마십시오.

의도적으로 부정적인 경로를 테스트하십시오.

참고자료: RFC 5321 §5.1, RFC 7505 §3.

격리된 구역에서 조명기 A는 noreceive.example . IN MX 0 . 그리고 기록 웹사이트를 위해. 예상되는 메일 라우팅은 해당 웹 주소로 돌아가는 대신 Null MX 인식합니다. Fixture B에는 A 레코드가 있지만 MX 없습니다. SMTP 의 암시적 MX 동작은 다른 경우입니다. Fixture C는 Null MX 일반 교환과 결합하며 지원되는 장애 조치 설계가 아닌 유효하지 않은 구성입니다.

질문 @AUTH noreceive.example 파헤쳐 보세요. MX +재귀 없음 각 유효한 고정 장치에 대해 완전한 답변을 유지하십시오. Null MX 사례가 의도한 단일 레코드를 정확히 반환하는지 확인합니다. 그런 다음 제어된 SMTP 발신자를 사용하여 원치 않는 트래픽을 관련 없는 인프라로 보내지 않고 처리를 검사합니다. 여기서 DNS 사례는 테스트 사양입니다. 실제 발신자 동작은 실행 보류 상태로 유지됩니다.

정확한 범위를 확인하세요

참고자료: RFC 4592 §3.3, RFC 8767 §4.

Null MX example.com 자동으로 MX 레코드가 아닙니다. sub.example.com. 와일드카드 및 위임된 분기를 포함하여 이름을 별도로 테스트합니다. DNS 부재, 와일드카드 합성 및 명시적 기록은 다른 경로로 이어질 수 있습니다.

사업주와 함께 비수신 결정을 문서화하고 해당되는 경우 두 번째 검토자가 비송신 제어 계획을 확인하도록 하십시오. 이 가이드는 그러한 승인이 발생했다고 주장하지 않습니다. 필요한 주소가 발견되면 승인된 DNS 프로세스를 통해 롤백하여 캐시된 레코드를 허용합니다. 폐쇄에는 성공적인 DNS 저장뿐만 아니라 의도된 게시 경로와 독립적으로 검토된 인벤토리가 필요합니다.

보관된 조회 및 검토 가능한 제어 계획

이 검토를 위해 검사되었지만 다시 실행되지 않은 2026년 11월 7일의 보관된 기록 캡처에는 합성에 대한 신뢰할 수 있는 루프백 UDP 쿼리가 기록되어 있습니다. noreceive.example MX 정확히 반환됨 0 .; 보관된 캡처에는 쿼리, 유선 응답, UTC 시간 및 권한 엔드포인트가 포함됩니다. 함께 제공되는 구체적인 비 전송 계획은 해당 MX 와 하나의 SPF 결합합니다. -all 합법적인 메일이 없는 것으로 명시적으로 가정된 고정물에 대한 정책 및 예시적인 DMARC 거부 정책. 여기에는 복구 주소 및 하위 도메인 실행 전 검사, 보고 데이터 제한, 수신기 테스트 제한 및 롤백이 나열되어 있습니다. 해당 계획에 대한 독립적인 평가는 사업주 승인이 아닌 검토 관문입니다. 실제 고객 인벤토리와 공개 배포는 확인되지 않은 상태로 유지됩니다.

증거 범위를 명시적으로 유지하세요.

과거 Null MX 응답은 와이어 바이트 및 루프백 엔드포인트와 함께 보존됩니다. 관련 비발송 계획은 재고 가정이 포함된 종합 제안으로 남아 있습니다. 보존이나 이 콘텐츠 검토는 고객 승인을 제공하지 않으며 실제 수신자 처리를 테스트하지도 않습니다.

[ 테이크아웃 ]

유일한 MX 0 점은 이 정확한 도메인이 메일을 허용하지 않음을 선언합니다. Absent MX 와 Null MX SMTP 라우팅 동작이 다릅니다. 재고 수령 요구 사항을 검토하고 발송 관리를 별도로 검토합니다.

[ 역할별 ]

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

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

IT/메일 관리자

명확한 경로 게시

Null MX 유일한 MX 여야 하며 하위 도메인에는 자체 평가가 필요합니다.

다음 단계

  1. 정확히 하나의 MX 0 도트 레코드를 게시합니다.
  2. 암시적 MX 및 명시적 null 사례를 테스트합니다.
  3. 각 관련 하위 도메인을 검토하세요.

CISO/SecOps

미발송 계획 검토

수신 선언은 아웃바운드 인증 제어를 대체하지 않습니다.

다음 단계

  1. 별도의 수신 및 사칭 통제.
  2. 독립적으로 검토된 발송 재고가 필요합니다.
  3. 정책 범위와 예외를 기록합니다.

창립자 / 비기술자

간과된 수신 요구 사항 확인

복구 및 소규모 비즈니스 주소는 유휴 도메인을 중요하게 만들 수 있습니다.

다음 단계

  1. 재고 복구 및 사업장 주소.
  2. 미수신 결정을 승인합니다.
  3. 명명된 롤백 소유자를 유지합니다.

[ 자주 묻는 질문 ]

자주 묻는 질문

Null MX 와 동일한 MX 가 없습니까?

아니요. MX 가 없으면 SMTP 주소 대체를 허용할 수 있습니다.

RFC 5321 §5.1

정확한 Null MX 값은 무엇입니까?

선호도 0과 점 교환은 MX 0 으로 표시됩니다.

RFC 7505 §3

백업 MX 보관할 수 있나요?

아니요. Null MX 해당 도메인의 다른 MX 레코드와 공존해서는 안 됩니다.

RFC 7505 §3

Null MX 아웃바운드 스푸핑을 중지합니까?

아니요. 인증 전송과 도메인 정책에는 별도의 제어가 필요합니다.

도메인에서 여전히 웹사이트를 호스팅할 수 있나요?

예. Null MX HTTP 서비스가 아닌 메일 수신과 관련이 있습니다.

RFC 7505 §1

상위 설정에 하위 도메인이 포함되나요?

자동으로 아닙니다. 각 관련 DNS 이름과 해당 기록을 확인하세요.

RFC 4592 §3.3

복구 주소를 먼저 확인해야 합니까?

예. 소량의 운영 및 복구 계정은 놓치기 쉽습니다.

제안된 비발송 계획이 이 가이드에서 승인되었습니까?

아니요. 독립적인 검토와 도메인 소유자 승인이 여전히 필요합니다.

[ 출처 ]

출처

  1. RFC 5321

    섹션 §5.1

  2. RFC 7505

    섹션 §1 · §3 · §4.2

  3. RFC 7208

    섹션 §5.1

  4. RFC 9989

    섹션 §4.10.1

  5. RFC 8767

    섹션 §4

  6. RFC 4592

    섹션 §3.3

[ 어휘 ]

어휘

널 MX
도메인이 메일을 허용하지 않는다고 선언하는 기본 설정 0과 교환 점이 있는 유일한 MX .

RFC 7505 §3

암시적 MX
해당 호스트를 가리키는 암시적 교환으로 존재하지 않는 MX RRset를 SMTP 처리합니다. 명시적인 Null MX 와는 다릅니다.

RFC 5321 §5.1

기업 출처

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

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

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

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

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

기술 자료