자동 발송 메일이 스팸함으로 갈 때 — 내 도메인의 인증 레코드를 직접 조회해 보기

자동화 도구로 보낸 메일이 스팸함으로 들어가기 시작하면 대개 제목과 본문부터 고치게 돼요. 그런데 그 앞에 볼 것이 하나 있어요. 받는 쪽 서버가 메일을 열어 보기 전에 먼저 확인하는 것은 내 도메인의 DNS 레코드거든요.

이 글은 SPF나 DMARC를 새로 설정하는 방법이 아니라, 지금 내 도메인이 어떤 상태인지 명령 한 줄로 읽어 내는 방법을 다뤄요. 발송 도구를 바꾸든 문구를 다듬든, 현재 상태를 모르면 무엇이 달라졌는지 잴 수가 없으니까요.

아래 조회는 전부 2026년 8월 12일 14시 45분 한국시간에 두 리졸버로 직접 돌렸어요. 하나는 구글 퍼블릭 DNS(8.8.8.8)의 nslookup, 다른 하나는 클라우드플레어의 DoH 주소(https://cloudflare-dns.com/dns-query, application/dns-json)예요. 두 리졸버의 결과는 모든 항목에서 일치했어요.

조회는 두 줄이면 끝나요

윈도우 명령 프롬프트에서 이렇게 쳐요. example.com 자리에 내 도메인을 넣으세요.

nslookup -type=TXT example.com 8.8.8.8
nslookup -type=TXT _dmarc.example.com 8.8.8.8

첫 줄이 SPF, 둘째 줄이 DMARC예요. 뒤에 붙인 8.8.8.8은 리졸버를 지정하는 부분이라 빼도 되지만, 회사망이나 공유기가 응답을 손대는 경우를 배제하려면 붙여 두는 편이 좋아요.

명령창이 부담스럽다면 브라우저 주소창으로도 같은 조회를 할 수 있어요. 구글 퍼블릭 DNS의 JSON 주소에 이름과 종류를 붙이면 JSON으로 답이 와요.

https://dns.google/resolve?name=_dmarc.example.com&type=TXT

클라우드플레어의 https://cloudflare-dns.com/dns-query도 같은 조회를 하지만 accept: application/dns-json 헤더가 필요해서 주소창에 그냥 붙여 넣으면 400이 떠요. 이 글의 대조표는 그 헤더를 붙인 요청으로 조회했어요.

여기서 미리 알아 둘 것이 하나 있어요. TXT 레코드는 한 도메인에 여러 줄이 함께 살아요. 실제로 네이버 도메인을 조회하면 일곱 줄이 나오는데 그중 SPF는 한 줄뿐이고 나머지는 구글·페이스북·야후 같은 서비스의 소유권 확인 문자열이에요. 카카오 쪽은 열두 줄, 메일침프 쪽은 서른세 줄이 나왔고요. v=spf1로 시작하는 줄만 골라 보면 돼요.

SPF에서 진짜 봐야 하는 것은 맨 끝 두 글자예요

SPF 레코드는 길지만 읽는 순서는 단순해요. 앞은 허용 목록이고 맨 끝이 "목록에 없는 서버는 어떻게 하라"는 부분이에요.

RFC 7208은 메커니즘 앞에 붙는 한정자를 네 가지로 정의해요. 더하기는 pass, 빼기는 fail, 물결표는 softfail, 물음표는 neutral이고, 한정자를 생략하면 더하기가 기본값이에요. 같은 문서가 두 결과를 이렇게 갈라 적어요.

A "fail" result is an explicit statement that the client is not authorized to use the domain in the given identity. A "softfail" result is a weak statement by the publishing ADMD that the host is probably not authorized. It has not published a stronger, more definitive policy that results in a "fail".

곧 -all은 권한이 없다는 명시적 진술이고, ~all은 아마도 권한이 없다는 약한 진술이에요. 실측에서도 이 차이가 그대로 갈렸어요. 네이버·다음·한메일·네이트·카카오·스티비·메일침프는 ~all로 끝났고, 대한민국 정책브리핑·국세청·정부24 도메인은 -all로 끝났어요.

~all을 쓰는 쪽이 느슨해서라기보다는, 목록에 빠진 발송 경로가 있을 때 메일이 통째로 막히는 사고를 피하려는 선택이기도 해요. 자동화 도구를 새로 붙였는데 그 도구의 발송 서버를 SPF에 넣지 않았다면, -all인 도메인에서는 그 사고가 즉시 드러나요.

DMARC 레코드는 태그 네 개만 읽으면 돼요

DMARC 레코드는 v=DMARC1로 시작해 세미콜론으로 구분된 태그가 이어지는 형태예요. RFC 9989 원문에서 자주 보게 되는 네 태그의 정의를 확인했어요.

표 캡션: DMARC 표준은 2026년 5월 RFC 9989(IETF Standards Track)로 갱신됐고, 이 문서가 RFC 7489(2015년 3월, Independent Submission·Informational)를 폐기했어요. 위 태그 정의는 두 문서 모두에서 확인한 내용이에요.

p 값 셋의 뜻도 두 문서가 직접 적는데, 여기서는 문언이 갈려요. none은 현행 RFC 9989가 "도메인 소유자가 선호를 표명하지 않는다"로, 앞선 RFC 7489가 "도메인 소유자가 메시지 전달과 관련해 특정 조치를 취하지 말 것을 요청한다"로 적어요. quarantine은 인증에 실패한 메일을 의심스러운 것으로 다뤄 달라는 요청이에요. RFC 9989는 "메일이 유효할 가능성도 있지만 그 실패가 상당한 우려를 낳는다고 도메인 소유자가 본다"로 적고, 앞선 RFC 7489는 여기에 "스팸 폴더에 넣기"를 예로 들었어요. reject는 거부해 달라는 요청이고, RFC 9989는 거부가 SMTP 세션 중에 이뤄지는 쪽이 낫다고 적어요.

여기서 자주 어긋나는 자리를 짚을게요. p=none은 "설정을 안 한 상태"가 아니에요. 레코드는 게시돼 있고, 그 안에서 소유자가 요청하는 것이 "특정 조치 없음"인 상태예요. 그래서 p=none인 도메인의 메일이 스팸함에 간다면 그건 DMARC 정책 때문이 아니라 다른 신호 때문이에요.

rua가 붙어 있는지도 함께 봐야 해요. 실측에서 스티비 도메인은 v=DMARC1; p=none;으로 끝나 rua가 아예 없었어요. RFC 문언대로면 집계 리포트가 생성되지 않는 상태라, 정책은 게시했지만 강제는 요청하지 않고 리포트도 받지 않는 셈이에요. 반대로 지메일 도메인은 p=none이면서 sp=quarantine이라, 도메인 자체에는 조치를 요청하지 않지만 하위 도메인에는 격리를 요청해요.

이런 신호를 주기적으로 다시 재고 싶다면 자동화 쪽으로 넘기는 방법도 있어요. 폴링 주기와 즉시 실행이 어떻게 갈리는지는 자동화가 바로 안 도는 이유에 정리해 뒀고, 결과를 메일 대신 다른 채널로 받고 싶다면 카카오톡 나에게 보내기 API로 알림 채널 만들기 쪽이 참고가 돼요.

DKIM은 셀렉터를 모르면 조회 자체가 안 돼요

SPF와 DMARC는 조회할 이름이 정해져 있어요. SPF는 도메인 자체, DMARC는 _dmarc.도메인이에요. DKIM만 이름이 도메인마다 달라요. 형식은 <셀렉터>._domainkey.도메인인데, 셀렉터는 발송 서비스가 정하는 이름 조각이라 밖에서는 알 수가 없어요.

실측으로 이 구조를 확인했어요.

같은 도메인인데 셀렉터를 바꾸니 결과가 뒤집혔어요. 스티비 도메인은 google 셀렉터로는 아무것도 안 나왔지만 k1 셀렉터로는 키가 나왔어요. 그러니 셀렉터를 찍어 보고 결과가 없다고 해서 "이 도메인에는 DKIM이 없다"로 쓰면 틀려요. 정확한 문장은 "이 셀렉터로는 조회되지 않는다"예요.

내 도메인의 셀렉터를 확인하는 가장 확실한 방법은 발송 서비스가 나에게 등록하라고 준 DNS 레코드를 다시 보는 것이에요. 그 레코드의 이름 앞부분이 곧 셀렉터예요.

국내 주요 도메인 실측 대조표

같은 시각, 같은 두 리졸버로 조회한 값이에요.

표 캡션: 2026년 8월 12일 14시 45분 한국시간 조회. 리졸버는 구글 퍼블릭 DNS(8.8.8.8)와 클라우드플레어 DoH 두 곳이고 두 결과가 일치했어요. DNS 레코드는 언제든 바뀌므로 이 표는 조회 시점의 값이에요.

표에서 눈에 띄는 것은 p=reject가 한 곳뿐이라는 점이에요. 메일 서비스를 파는 회사인 메일침프가 그쪽이고, 값이 조회된 나머지는 전부 none이었어요. 두 곳은 값이 없는 게 아니라 레코드 자체가 조회되지 않았는데, 그 둘은 바로 다음 절에서 갈라 볼게요. 정책을 세게 거는 일이 그만큼 조심스럽다는 뜻으로 읽는 편이 맞아요. 잘못 걸면 내 정상 메일이 거부되니까요.

결과가 비었을 때, 두 가지를 갈라야 해요

nts.go.kr과 gov.kr은 둘 다 DMARC가 "없다"로 보이지만 응답이 달랐어요.

• _dmarc.nts.go.kr — DoH 응답 Status=0(정상), 답변 0건, 권한 구역에 ns.gcc.go.kr의 SOA만. nslookup도 오류 없이 SOA 정보만 출력했어요. 이름은 있는데 이 종류의 레코드가 없는 상태예요.
• _dmarc.gov.kr — DoH 응답 Status=3(NXDOMAIN), nslookup은 "존재하지 않는 도메인"이라고 출력했어요. 이름 자체가 없는 상태예요.

그리고 이런 부정 결과를 쓰기 전에 양성 대조를 세워 두세요. 같은 스크립트, 같은 시각에 _dmarc.gmail.com, _dmarc.naver.com, _dmarc.mailchimp.com은 모두 레코드를 반환했어요. 도구와 네트워크가 정상이라는 확인이 있어야 "안 나온다"는 결과를 믿을 수 있어요.

한 가지 더 갈라 둘게요. DMARC가 조회되지 않는다고 인증 설정 전체가 없다고 읽으면 틀려요. 같은 nts.go.kr 도메인은 SPF가 -all로 끝나는 레코드를 갖고 있었고, default 셀렉터로 DKIM 조회를 했더니 RSA 공개키가 그대로 나왔어요. 곧 이 도메인에서 조회되지 않은 것은 DMARC 정책 레코드 하나예요. 부정 실측은 언제나 "무엇을 어느 이름으로 찾았는가"의 함수라서, 찾은 범위를 함께 적어야 문장이 정확해져요.

구글이 요구하는 최소선과 Gmail 하루 5,000통 경계

구글 공식 발신자 가이드라인은 2024년 2월 1일부터 Gmail 계정으로 메일을 보내는 발신자에게 적용되는 요건을 두 층으로 나눠 적어요. 기준은 총 발송량이 아니라 Gmail 계정으로 가는 양이에요.

경계에서 갈리는 것이 두 가지예요. 하나는 SPF 또는 DKIM에서 SPF와 DKIM으로 바뀐다는 것, 다른 하나는 직접 보내는 메일에 일치 요구가 새로 붙는다는 것이에요. 자동화 도구로 Gmail 계정에 가는 발송량을 늘리다 보면 이 경계를 넘는 순간이 오는데, 그때 조회해서 확인할 것이 바로 이 글의 두 명령이에요.

문구와 개인화 쪽 이야기는 이 글에서 다루지 않았어요. 그쪽은 AI 콜드메일 개인화와 발송·회신 관리에 따로 정리돼 있어요. 이 글은 그 앞단, 곧 레코드가 지금 어떤 상태인지 읽는 자리만 봐요.

이 블로그 도메인도 조회해 봤어요

남의 도메인만 재고 끝내면 재미가 없으니 이 블로그가 서 있는 도메인도 같은 명령으로 조회했어요. 결과를 그대로 적을게요.

• how-toai.com의 TXT 레코드는 구글 사이트 소유권 확인 문자열 두 줄뿐이고, v=spf1로 시작하는 줄이 없어요.
• _dmarc.how-toai.com은 NXDOMAIN이에요.
• google._domainkey.how-toai.com과 selector1._domainkey.how-toai.com도 NXDOMAIN이에요.

지금은 이 도메인으로 메일을 보내지 않으니 당장 무엇이 잘못된 상태는 아니에요. 다만 오늘 자동화 도구를 붙여 발송을 시작한다면, 구글이 Gmail로 보내는 모든 발신자에게 요구하는 첫 항목부터 채우지 못한 채로 나가게 돼요. 발송을 시작하기 전에 조회해 보라는 말이 이런 뜻이에요.

조회 결과를 읽는 여섯 문항

1. TXT 결과에서 v=spf1로 시작하는 줄을 정확히 한 줄 골라냈나요? 나머지는 소유권 확인 문자열이에요.
2. 그 줄의 맨 끝이 ~all인가요 -all인가요? 지금 쓰는 발송 도구의 서버가 앞쪽 목록에 들어 있나요?
3. _dmarc.도메인 조회 결과가 NXDOMAIN인가요, 아니면 정상 응답에 답변만 비어 있나요? 둘은 다른 상태예요.
4. p 값을 "설정 안 함"으로 읽지 않았나요? none은 게시된 정책이고 그 내용이 "특정 조치 없음"이에요.
5. rua가 있나요? 없으면 RFC 문언대로는 집계 리포트가 생성되지 않아요.
6. DKIM을 확인할 때 셀렉터를 발송 서비스가 준 값으로 넣었나요? 아무 이름이나 넣고 나온 결과를 부재의 증거로 쓰지 마세요.

이 글에서 확인하지 못한 것

솔직하게 남길게요.

첫째, 실제 배달 결과와의 관계예요. 이 글은 레코드가 어떤 값인지까지만 재고, 그 값이 특정 수신 서버에서 실제로 어떤 처리를 낳는지는 측정하지 않았어요. RFC의 문언은 요청이고 처리는 받는 쪽이 정해요.

둘째, 각 도메인이 왜 그 값을 골랐는지예요. ~all과 -all, p=none과 p=reject의 선택 이유는 운영 사정에 달린 것이라 조회로는 알 수 없어요.

셋째, DKIM 셀렉터 전수예요. 위 표는 흔히 쓰이는 몇 개를 찍어 본 결과라, 표에서 NXDOMAIN이 나온 도메인이 다른 셀렉터로는 키를 갖고 있을 수 있어요.

넷째, RFC 9989 이후의 갱신이에요. 이 글은 RFC 9989·RFC 7489·RFC 7208 원문을 열어 확인했지만, RFC 9989가 새로 넣은 np·psd·t 태그까지는 다루지 않았어요.

정리

• 메일이 스팸함에 갈 때 문구보다 먼저 볼 것은 DNS 레코드예요. 조회는 nslookup 두 줄이면 끝나요.
• SPF는 맨 끝 두 글자가 핵심이에요. -all은 명시적 fail, ~all은 약한 softfail이라고 RFC 7208이 적어요.
• DMARC의 p=none은 설정 안 함이 아니에요. 게시된 정책이고 내용이 "특정 조치 없음"이에요.
• rua가 없으면 집계 리포트가 생성되지 않아요. 실측에서 그런 도메인이 있었어요.
• DKIM은 셀렉터를 모르면 조회가 안 되는 구조예요. 결과 없음을 부재로 읽지 마세요.
• 결과가 비었을 때 NXDOMAIN과 정상 응답의 빈 답변은 다른 상태예요. 판정 전에 양성 대조를 세우세요.
• 구글 요건은 Gmail로 하루 5,000개 경계에서 한 단계 올라가요. SPF 또는 DKIM에서 둘 다로, 그리고 직접 보내는 메일에 도메인 일치 요구가 붙어요.

레코드를 읽을 줄 알게 되면 스팸함 문제를 "느낌"이 아니라 상태로 다룰 수 있어요. 오늘 값을 적어 두고, 무엇을 바꾼 뒤에 다시 조회해 보세요.

확인한 자료: RFC 9989(DMARC, IETF Standards Track, 2026년 5월. RFC 7489를 폐기)와 그 이전 판 RFC 7489(Independent Submission, Informational, 2015년 3월), RFC 7208(SPF, Standards Track, 2014년 4월) 원문을 rfc-editor.org에서 직접 내려받아 태그·한정자 정의를 축자 확인. 구글 「이메일 발신자 가이드라인」(support.google.com/a/answer/81126). DNS 조회는 구글 퍼블릭 DNS(8.8.8.8, nslookup)와 클라우드플레어 DoH(cloudflare-dns.com/dns-query, application/dns-json)로 2026년 8월 12일 14시 45분 한국시간에 직접 실행했어요.