이 도구는 서버에서 실행됩니다.
작동 방식
이메일 프로토콜은 발신자를 검증하지 않습니다. 어떤 서버든 발신자에 내 도메인을 넣을 수 있습니다. 세 가지 DNS 레코드가 이 문을 닫습니다. SPF는 도메인 이름으로 보낼 수 있는 서버를 나열합니다. DKIM은 각 메시지를 개인 키로 서명하고 공개 키를 DNS에 게시합니다. DMARC는 둘을 묶어, 적어도 하나가 통과하고 눈에 보이는 발신자 도메인과 일치해야 한다고 요구하며, 실패한 메일을 어떻게 처리할지 수신 측에 알리고, 내 이름으로 보낸 모든 메일에 대한 보고서를 요청합니다.
2024년 2월부터 Gmail과 Yahoo는 자사 사용자에게 하루 5,000건 넘게 보내는 발신자에게 SPF, DKIM, DMARC를 요구하며, 하나라도 없으면 메일이 거부되거나 스팸함으로 갑니다. 그래서 세 가지를 함께 확인하는 것이 좋습니다. 완벽한 SPF도 DMARC 없이는 별 효과가 없고, DKIM을 잘못 게시한 채 DMARC를 reject로 두면 내 메일까지 막힙니다.
확인은 일반 메일 서버와 마찬가지로 저희 서버에서 공개 DNS 조회로 수행합니다. SPF는 모든 include와 redirect를 따라가며 완전히 평가해 DNS 조회 횟수를 셉니다. 10회 한도를 넘으면 레코드 전체가 무효가 되기 때문입니다. MX 레코드와 선택 사항인 MTA-STS, TLS-RPT, BIMI 레코드도 조회합니다.
예시
github.comSPF · 10 / 10공급자 include 8개(Microsoft, Google, Zendesk, Salesforce, Mailchimp, SendGrid…)와 그들이 다시 include하는 것들이 평가를 정확히 DNS 조회 10회 한도까지 끌어올립니다. 공급자가 하나만 늘어도 SPF 전체가 영구 오류를 냅니다.example.comMX 0 . · v=spf1 -all · v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s메일을 보내지도 받지도 않는 도메인의 올바른 설정입니다. 널 MX, 아무도 허용하지 않는 SPF, reject로 설정한 DMARC로, 위조의 흔한 표적인 파킹 도메인을 보호합니다.v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.comquarantine · 25 %점진적 도입입니다. 실패한 메시지 네 통 중 한 통만 스팸함으로 가고, 보고서는 rua에 지정한 메일함으로 와서 아직 인증되지 않은 정상 발신자를 찾아낼 수 있습니다.활용 사례
- 도메인의 메일이 스팸함으로 가거나 Gmail, Outlook, Yahoo에서 거부되는 원인 진단하기.
- CRM이나 뉴스레터 플랫폼 같은 새 발송 공급자를 추가하기 전에 SPF가 DNS 조회 10회를 넘지 않는지 확인하기.
- 공급자의 DKIM 키가 설정 후 제대로 게시되었는지 확인하기.
- 정상 메일을 막지 않고 DMARC를 none에서 quarantine, reject로 옮기는 계획 세우기.
- 고객사나 인수한 회사의 도메인을, 메일을 보내면 안 되는 파킹 도메인까지 포함해 감사하기.
- 피싱을 분석하면서 의심스러운 발신자의 설정을 살펴보기.
자주 묻는 질문
도메인이 메일에 서명하는데 왜 DKIM을 찾지 못했다고 나오나요?
DKIM은 도메인의 키 목록을 나열할 수 없기 때문입니다. 키는 각각 <selector>._domainkey.<domain>에 있으며, 조회하려면 선택자를 알아야 합니다. 이 도구는 가장 흔한 선택자를 시도하지만, 많은 공급자가 자체 이름이나 날짜가 들어간 이름을 씁니다. 도메인에서 보낸 메일을 열어 DKIM-Signature 헤더의 s= 값을 복사하세요. 그 선택자로 하면 정확히 확인할 수 있습니다.
SPF가 DNS 조회 10회를 넘으면 어떻게 되나요?
RFC 7208은 수신 측이 영구 오류(permerror)를 반환하도록 규정하며, DMARC에서는 이것이 SPF 실패로 간주됩니다. 조회를 소비하는 것은 include, a, mx, ptr, exists 메커니즘과 redirect 수정자이며, 각 include 안에 있는 것도 포함됩니다. ip4와 ip6은 소비하지 않습니다. 횟수를 줄이려면 더 이상 쓰지 않는 공급자를 빼거나, include를 ip4 범위로 바꾸거나, 자체 SPF를 가진 하위 도메인에서 보내세요.
~all와 -all 중 무엇이 좋을까요?
DMARC가 켜져 있으면 차이는 작습니다. 수신 측은 SPF 한정자가 아니라 DMARC 정책을 적용합니다. ~all이 일반적인 이유는 일부 수신 측이 -all이면 DKIM을 평가하기 전에 바로 거부해, DKIM이 살릴 수 있었던 전달 메일을 잃을 수 있기 때문입니다. DMARC가 없다면 허용되지 않은 메일의 거부를 요청하는 방법은 -all뿐입니다.
메일을 잃지 않고 DMARC를 none에서 reject로 바꾸려면?
p=none과 rua 주소로 시작해 몇 주 동안 집계 보고서를 읽으세요. 보고서에는 내 도메인으로 보내는 모든 서버와 그 서버가 SPF나 DKIM을 통과하는지가 나옵니다. 빠진 정상 발신자를 인증하고, 낮은 pct로 quarantine으로 옮긴 뒤 pct를 조금씩 올려 reject로 마무리하세요. 곧장 reject로 가면 청구 시스템, CRM, 아무도 기억하지 못한 내부 시스템이 막히기 쉽습니다.
1024비트 DKIM 키로 충분한가요?
동작은 합니다. RFC 8301은 수신 측이 1024~4096비트 키를 받아들이도록 요구하지만, 같은 표준은 서명하는 쪽에 최소 2048비트를 권장합니다. 1024비트 미만 키는 유효하지 않은 것으로 봅니다. 2048로 바꾸는 방법은 간단합니다. 새 키를 다른 선택자로 게시하고 서명을 전환한 뒤, 이전 키는 p를 비워 폐기하세요.
MTA-STS, TLS-RPT, BIMI는 무엇에 쓰나요?
MTA-STS(RFC 8461)는 보내는 서버가 내 MX로 배달할 때 TLS를 필수로 쓰도록 요구해, 연결을 평문으로 떨어뜨리는 공격을 막습니다. TLS-RPT(RFC 8460)는 그런 배달이 실패하면 보고서를 보내 줍니다. BIMI는 지원하는 클라이언트에서 발신자 옆에 브랜드 로고를 보여 주며, DMARC가 quarantine이나 reject일 때만 동작합니다. 셋 다 필수는 아니지만 모두 도움이 됩니다.