우리는 고객에게 이메일 계정을 판매하는 데 사용하는 메일 서버(Mailenable)를 보유하고 있습니다. 특정 도메인에 이메일을 보낼 수 없는 클라이언트가 하나 있는데 도메인의 이메일 서버에서 다음 오류가 수신됩니다.
이유: ourclientcompanyname.com 도메인 이름에 DNS 레코드가 없기 때문에 메시지를 배달할 수 없습니다.
이메일을 위해 우리를 사용하는 회사는 도메인에 대한 DNS 레코드를 가지고 있지 않습니다.ourclientcompanyname.com
MX 레코드는 양호하지만 도메인에 다른 DNS 레코드가 없습니다. 가능한 오류인가요? 클라이언트는 어떤 DNS 레코드를 추가해야 합니까?
답변1
MX 레코드는 fin이지만 도메인에 DNS 레코드가 전혀 없습니다. 가능한 오류인가요? 클라이언트가 추가해야 하는 DNS 레코드는 무엇입니까?
예, 일부 메일 서버는 이메일을 받으면 보내는 서버뿐만 아니라 보내는 사용자의 도메인에 DNS 레코드가 있는지 확인합니다. 내 생각에 그것은 약간 어리석고 스팸을 확인하는 데에는 적합하지 않지만 그것이 바로 그것입니다. 귀하의 고객은 Aourclientcompanyname.com apex 도메인에 대한 기록을 입력하기만 하면 됩니다 . 좋은 평가를 위해 5달러짜리 호스팅 계정과 단일 페이지 정보 웹사이트를 제공하세요.
편집하다:
이전 RFC 5321에 묻혀 있으며 섹션 2.3.5에 다음과 같이 나와 있습니다.
도메인 이름이 SMTP에서 사용되는 경우 확인 가능한 FQDN(정규화된 도메인 이름)만 허용됩니다.
안돼! 나는 여전히 그것을 스팸 억제 수단으로 생각하는 것이 어리석고 상관관계/인과관계의 혼동이라고 생각합니다. 그러나 적어도 그것은 문서화된 표준이고 이를 따르면 스팸 폴더에 긍정적인 부작용이 있습니다! 엄지손가락이 두 개 있고 방금 RFC 교육을 받은 사람이 누구입니까?
답변2
RFC 5321 섹션 2.3.5이메일에 사용된 도메인 이름을 주소로 확인할 수 있어야 합니다.
관련 부분에서:
도메인 이름이 SMTP에서 사용되는 경우 확인 가능한 FQDN(정규화된 도메인 이름)만 허용됩니다. 즉, MX RR 또는 주소(예: A 또는 AAAA) RR(섹션 5에서 설명)로 확인될 수 있는 이름이 허용되며, 대상이 MX 또는 주소 RR로 확인될 수 있는 CNAME RR도 허용됩니다. . 지역 별명이나 자격이 없는 이름은 사용하면 안 됩니다. FQDN을 요구하는 규칙에는 두 가지 예외가 있습니다.
- EHLO 명령에 제공된 도메인 이름은 기본 호스트 이름(주소 RR로 확인되는 도메인 이름)이거나 호스트에 이름이 없는 경우 섹션 4.1.3에 설명되고 추가 설명에서 설명하는 주소 리터럴이어야 합니다. 섹션 4.1.4의 EHLO 논의.
이는 새로운 요구 사항이 아닙니다.RFC 2821 섹션 2.3.5(2001)도 비슷한 언어를 사용했습니다.
이 문서와 [22]에 설명된 대로 도메인 이름은 완전한 정규화된 이름(종종 "FQDN"이라고도 함)입니다. FQDN 형식이 아닌 도메인 이름은 로컬 별칭에 지나지 않습니다. 로컬 별칭은 SMTP 트랜잭션에 표시되어서는 안 됩니다.
메일 서버에서 EHLO company.examplecompany.example을 주소로 확인할 수 없다고 표시되면 해당 연결을 거부하는 것이 완전히 유효합니다. 보낸 사람과 받는 사람 주소에 사용되는 도메인 이름도 마찬가지입니다(도메인 이름이 전혀 필요하지 않은 postmaster는 제외).
(RFC 2821 이전의 관리 표준은 1980년대까지 거슬러 올라가는 RFC 821 및 RFC 974였으며 더 이상 존재하지 않는 많은 비인터넷 네트워크를 수용해야 했기 때문에 표준은 훨씬 덜 제한적이었습니다.)
답변3
메일이 제대로 작동하려면 세 가지 DNS 레코드가 필요합니다.
A 레코드 - 호스트 이름과 IP 주소 매핑
MX 레코드 - MX 레코드는 메일 서버의 A 레코드에 바인딩됩니다.
역방향 조회 - 역방향 조회를 위해 IP 주소를 A 레코드에 바인딩해야 합니다(스팸 방지).
또한, 메일 서버의 공용 IP(소스 IP)가 역방향 조회와 일치하도록 방화벽의 PAT 주소를 메일 서버에 설정해야 합니다.
일반적으로 ISP에 연락하여 공용 측에서 사용 중인 IP 주소를 소유한 경우 역방향 조회를 생성하도록 해야 합니다.
참고: 전달 확인 역방향 DNS에 관한 RFC는 없습니다. 그것은 단순히 모범 사례입니다.