고객이 비밀번호 재설정 메일을 받지 못했다고 합니다. 거래처는 청구서를 스팸함에서 찾습니다. 대개 메일은 정상적으로 발송됐습니다. 받는 쪽 메일 서버가 그 메일이 정말 여러분에게서 왔는지 확인하지 못했을 뿐입니다.
Gmail, Outlook 등 메일 서비스는 메시지를 신뢰하기 전에 도메인의 DNS 레코드 세 가지, 즉 SPF, DKIM, DMARC를 확인합니다. 이 레코드가 없거나 잘못 설정된 것은 정상적인 업무 메일이 스팸으로 분류되는 가장 흔한 원인 중 하나이며, 가장 쉽게 고칠 수 있는 원인이기도 합니다.
각 레코드가 하는 일
SPF는 여러분의 도메인으로 메일을 보낼 수 있는 서버 목록입니다. v=spf1로 시작하는 TXT 레코드 하나로 되어 있습니다.
DKIM은 메시지마다 서명을 붙입니다. 받는 서버는 DNS에 공개된 공개 키로 그 서명을 확인하며, 이를 통해 메시지가 변경되지 않았고 여러분의 키를 가진 쪽에서 보냈다는 것을 알 수 있습니다.
DMARC는 메시지가 이런 확인을 통과하지 못했을 때 받는 쪽이 어떻게 처리할지, 그에 대한 보고서를 어디로 보낼지 알려 줍니다. 또한 보낸 사람 줄에 보이는 도메인이 SPF나 DKIM으로 확인된 도메인과 일치해야 한다고 요구합니다.
SPF는 초대 명단, DKIM은 편지의 서명, DMARC는 둘 다 통과하지 못한 사람을 어떻게 할지 알려 주는 경비원 지침이라고 생각하면 쉽습니다.
예전보다 더 중요해진 이유
Gmail은 이제 모든 발신자에게 SPF나 DKIM 설정을 요구하며, Gmail 주소로 하루 5,000통 넘게 보내는 발신자에게는 SPF, DKIM, DMARC를 모두 갖추고 보낸 사람 도메인을 일치시키도록 요구합니다.Google의 발신자 가이드라인에는 스팸 신고율 0.3% 미만 유지를 포함한 모든 요건이 나와 있습니다. 다른 대형 메일 서비스도 비슷한 규칙을 적용합니다.
발송량이 적다고 필터링에서 빠지는 것은 아닙니다. 이 레코드가 없는 도메인은 필터가 판단할 때 신뢰할 근거가 적을 뿐입니다.
가장 자주 보는 실수
SPF 레코드가 두 개
한 도메인에는 SPF 레코드가 하나만 있어야 합니다. 새 서비스를 위해 기존 레코드에 합치지 않고 두 번째 레코드를 만들면 모든 발송에서 SPF가 실패합니다. 발송에 쓰는 모든 서비스를 포함한 레코드 하나로 정리하는 것이 해결책입니다.
조회 횟수 초과
SPF는 확인 과정에서 DNS 조회를 최대 10번까지만 허용합니다. 메일 서비스, CRM, 뉴스레터 도구의 include마다 최소 한 번, 많게는 여러 번의 조회가 필요합니다. 한도를 넘으면 모든 서비스가 등록돼 있어도 SPF가 오류를 냅니다.
DKIM 없이 여러분 이름으로 보내는 서비스
웹사이트, 예약 시스템, 청구서 도구가 여러분의 주소로 메일을 보내고 있을 수 있습니다. 그 서비스가 SPF에 없고 여러분 도메인으로 DKIM 서명도 하지 않으면 그 메일은 확인에 실패합니다. 서비스마다 설정 방법이 있으며, 대개 DNS 레코드 몇 개를 복사하면 됩니다.
아무도 읽지 않는 DMARC
p=none과 보고서 주소를 넣은 DMARC 레코드는 좋은 출발점입니다. 하지만 누군가 보고서를 읽고, 실패하는 서비스를 찾아 고친 다음, 정책을 quarantine이나 reject로 올려야 비로소 효과가 있습니다.
1분 만에 도메인 확인하기
제가 무료로 제공하는이메일 전달률 검사는 현재 DNS를 읽어 메일 서비스, SPF 레코드와 조회 횟수, 찾을 수 있는 DKIM 선택자, DMARC 정책과 보고서, MTA-STS, TLS 보고, 그리고 도메인이 주요 차단 목록에 올라 있는지를 보여 줍니다. 결과마다 무엇을 바꾸면 되는지 쉽게 설명합니다.
메일함 내부나 받는 사람의 스팸 필터까지는 볼 수 없습니다. 내용, 발송량, 신고율도 전달에 영향을 줍니다. 인증은 DNS에서 직접 관리할 수 있는 부분이므로, 시작하기에 알맞은 곳입니다.
안전하게 고치는 순서
여러분의 도메인으로 메일을 보내는 서비스를 모두 적어 보세요. 메일함 서비스, 웹사이트, 쇼핑몰, 예약 도구, 뉴스레터, 청구서 발송 등입니다.
이를 하나의 SPF 레코드로 합치고 조회 한도를 넘지 않게 유지하세요.
서비스마다 DKIM을 켜고 안내받은 레코드를 게시하세요.
p=none과 보고서 주소로 DMARC를 게시하고, 몇 주 동안 보고서를 읽어 보세요.
정상 메일이 모두 통과하면 DMARC를 quarantine으로, 그다음 reject로 올리세요.
이 레코드를 부주의하게 바꾸면 도메인 전체의 메일이 멈출 수 있습니다. 한 번에 하나씩 바꾸고 단계마다 확인하세요.
도움을 요청해야 할 때
검사에서 문제가 여러 개 나오거나, 어떤 서비스가 여러분 이름으로 메일을 보내는지 잘 모르겠다면도메인과 사용 중인 서비스를 보내 주세요. 필요한 레코드와 변경 순서를 정리하고, 애플리케이션의 메일 발송도 처음부터 이런 확인을 통과하도록 설정해 드릴 수 있습니다.