도메인 메일 설정, 홈페이지와 메일을 같이 쓰기

웹과 메일은 서로 다른 레코드를 씁니다

같은 도메인으로 홈페이지와 메일을 함께 쓰려면 두 종류의 레코드가 필요합니다. 홈페이지는 주소를 알려 주는 레코드를 쓰고, 메일은 수신 서버를 알려 주는 레코드를 씁니다. 두 레코드는 서로 간섭하지 않으므로 홈페이지를 다른 곳으로 옮겨도 메일은 그대로 유지됩니다. 문제는 전달 유형 레코드를 루트 도메인에 쓰려고 할 때 생깁니다. 그 유형은 같은 이름에 다른 레코드와 함께 둘 수 없기 때문에, 루트에 그것을 두면 메일 수신 레코드가 무시될 수 있습니다. 그래서 루트 도메인은 주소 유형으로 두는 것이 안전합니다.

발신 인증은 세 레코드가 한 묶음입니다

메일이 상대에게 도착하려면 수신 설정만으로는 부족합니다. 우리 도메인 이름으로 보낸 메일이 진짜인지 확인받는 발신 인증이 필요합니다. 여기에 세 가지가 들어갑니다. 첫째는 어느 서버가 우리 이름으로 보낼 수 있는지 적는 레코드입니다. 둘째는 메일에 서명을 넣고 그 확인 열쇠를 공개하는 레코드입니다. 셋째는 앞의 두 검사가 실패했을 때 상대가 어떻게 처리할지 알려 주는 레코드입니다. 세 번째를 거부 정책으로 바로 올리면 정상 메일도 반송될 수 있으므로, 처음에는 관찰 정책으로 두고 보고서를 받아 확인한 뒤 단계적으로 올립니다.

레코드 수를 세고 사고 비용과 비교합니다

학습용 가정으로 계산합니다. 가정값은 메일 수신 레코드 2개, 발신 허용 레코드 1개, 서명 열쇠 레코드 2개, 처리 정책 레코드 1개로 총 6개를 둔다고 하겠습니다. 설정 뒤 각 레코드를 확인하는 작업은 길지 않습니다. 이것이 중간 계산값입니다. 최종 판단은 사고 비용과 비교해서 합니다. 메일 수신이 하루 끊겨 업무 8시간이 막히고 내부 시간 비용을 시간당 30,000원으로 가정하면 240,000원입니다. 레코드 1개당 40,000원의 위험을 지고 있는 셈이므로, 6개 전부를 설정 직후에 확인하는 것이 합리적입니다.

외부 서비스를 추가할 때마다 다시 봐야 합니다

결론을 뒤집는 조건은 발신 서비스의 추가입니다. 메일 발송을 대행하는 서비스나 고객 안내 메일 도구를 새로 붙이면, 그 서비스도 우리 이름으로 메일을 보내게 됩니다. 발신 허용 레코드에 그 서비스를 추가하지 않으면 그쪽에서 보낸 메일이 스팸으로 처리됩니다. 그래서 외부 도구를 추가할 때마다 이 레코드를 갱신하는 절차를 운영 문서에 넣습니다. 두 번째 조건은 허용 항목 수 제한입니다. 발신 허용 레코드는 조회 횟수에 제한이 있어 서비스를 계속 추가하면 한도에 걸려 검사가 실패합니다. 그래서 쓰지 않는 서비스는 목록에서 바로 지웁니다.

웹호스팅 실행 전 점검표

• 루트 도메인을 주소 유형으로 두어 메일 레코드와 충돌을 피했다
• 발신 허용·서명 열쇠·처리 정책 세 레코드를 모두 등록했다
• 처리 정책을 관찰 단계로 시작해 보고서를 확인했다
• 외부 발송 도구 추가 시 허용 레코드를 갱신하는 절차를 넣었다