DMARC 레코드 빌더

DMARC는 이메일 인증의 고리를 닫는 레코드입니다. SPF와 DKIM은 각자 메시지에 대해 무언가를 말해 주고, DMARC는 둘 중 어느 것도 독자가 실제로 보는 주소와 맞아떨어지지 않을 때 수신 측이 무엇을 해야 하는지, 그리고 그에 대한 보고서를 어디로 보낼지를 말합니다. 이 빌더는 익숙한 경로를 따라갑니다. p=none으로 관찰하고, p=quarantine으로, 다시 p=reject로 나아가며, 실제 운영에서 기대는 정렬 모드·하위 도메인 정책·비율 롤아웃을 함께 다룹니다. 레코드는 _dmarc.내도메인에 TXT로 게시합니다.

DMARC를 가질 가치가 있게 만드는 개념은 정렬이고, 가장 놓치기 쉬운 부분도 그것입니다. SPF는 봉투 발신자를, DKIM은 메시지에 서명한 도메인을 인증하는데, 둘 중 어느 것도 사람이 읽는 From: 주소라는 보장이 없습니다. DMARC는 그중 하나가 화면에 보이는 그 도메인과 일치할 것을 요구합니다. 완화 모드는 조직 도메인의 아무 하위 도메인이나 받아들이고, 엄격 모드는 정확한 일치를 요구합니다. 외부 서비스로 보낸 메일이 SPF를 통과하고 DKIM도 통과하면서 DMARC에서 실패하는 이유가 이것입니다. SPF가 인증한 것은 그 서비스 자신의 반송 도메인이고, 그것은 내 도메인이 아닙니다.

p=none에서 시작하되 진심으로 그렇게 하세요. 이 정책은 배달에 대해 아무것도 바꾸지 않습니다. 하는 일은 누가 내 이름으로 보내고 있는지 알려 주는 집계 보고서를 켜는 것뿐이고, 무언가를 조이기 전에 필요한 정보가 바로 그것입니다. 첫날부터 rua 주소를 함께 게시하세요. 정책은 있는데 보고 주소가 없는 레코드는 가시성 없는 집행만 남깁니다. 그 주소가 다른 도메인에 있다면 수신 도메인 쪽이 자기 DNS 레코드로 승인해 주어야 합니다. 내도메인.com._report._dmarc.상대도메인.com 형태이고, 이것이 없으면 보고서가 조용히 오지 않게 됩니다. ruf 실패 보고서는 다른 이야기입니다. 대형 수신 업체 대부분은 개인정보 문제로 아예 보내지 않으므로, ruf 사서함이 비어 있는 것은 설정 오류가 아니라 정상입니다.

실무적인 메모 둘. pct=는 집행을 약화하는 것이 아니라 표본을 추출합니다. pct=10에 p=reject이면 실패한 메일의 10분의 1을 거부하고 나머지는 격리합니다. 그대로 두는 설정이 아니라 조여 올리는 래칫입니다. 그리고 2024년 초부터 구글과 야후는 대량 발송자에게 DMARC 레코드 게시 자체를 요구하고 있으므로, 어느 정도 물량을 보내는 도메인이라면 이것은 더 이상 선택적인 위생 조치가 아닙니다.