자체 도메인으로 메일 보내기
봇은 여러분의 도메인 주소(예: noreply@example.com)로 고객에게 메일을 보낼 수 있습니다. 다만 실제로 메일을 보내는 것은 저희 서버입니다. 그래서 첫 발송 전에 도메인의 DNS에 세 가지 레코드를 한 번 추가해야 합니다. 아래에서 왜 필요한지, 정확히 무엇을 추가하는지, 그 다음에 무슨 일이 일어나는지 설명합니다.
DNS 레코드가 없으면 메일이 도착하지 않는 이유
받는 쪽 — Gmail, Outlook, 또는 고객사의 메일 서버 — 의 눈으로 보십시오. 여러분 도메인에서 왔다고 주장하는 메일이, 그 도메인 소유가 아닌 서버에서 도착합니다. 이는 위조와 똑같은 모습입니다. 피싱이 바로 이렇게 작동합니다.
받는 쪽이 둘을 구분할 방법은 하나뿐입니다. 도메인 자신에게 "이 발신자가 정말 당신을 대신하고 있습니까?"라고 묻는 것입니다. 그 답을 여러분은 도메인의 DNS에 게시합니다. DNS는 오직 여러분만 통제하는 유일한 장소이고, 그래서 받는 쪽이 믿는 유일한 장소입니다.
그 답이 없는 동안 성실한 메일 서버는 그 메일을 의심스럽게 취급할 수밖에 없습니다. 잘해야 스팸함, 나쁘면 거부되어 수신자는 메일의 존재조차 알지 못합니다.
그러므로 아래 세 레코드는 형식이나 화면의 체크 표시가 아닙니다. 그것이 바로 여러분의 허가입니다.
세 레코드와 각각의 역할
DKIM — 진짜임을 증명하는 서명
DKIM은 나가는 모든 메일에 붙는 암호 서명입니다. 플랫폼이 도메인용 키 쌍을 만들어, 개인 키는 저희 쪽에 남아 메일에 서명하고 공개 키는 여러분이 DNS에 게시합니다. 받는 쪽은 여러분의 DNS에서 공개 키를 가져와 서명을 검증합니다. 맞으면 그 메일은 개인 키를 가진 쪽이 보냈고, 내용이 도중에 바뀌지 않았다는 뜻입니다.
DKIM이 없으면: 서명을 검증할 근거가 없습니다. 메일은 서명되지 않은, 신뢰할 수 없는 것으로 보이며 다른 어떤 설정으로도 만회되지 않습니다. 셋 중 DKIM이 가장 중요합니다.
SPF — 여러분 이름으로 보낼 수 있는 서버 목록
SPF는 다른 질문에 답합니다. "이 도메인의 메일은 애초에 어떤 서버에서 와야 정상인가"입니다. 발신원 목록으로, 호스팅의 메일 서버, 이미 쓰고 있는 발송 서비스, 그리고 봇이 메일을 보내도록 저희 발송 서버가 들어갑니다.
SPF가 없으면: 메일이 도메인이 "모르는" 서버에서 옵니다. 필터에게는 전형적인 위조 신호이며, 다른 모든 의심에 더해집니다.
DMARC — 검증에 실패했을 때 받는 쪽이 할 일
DKIM과 SPF는 "메일이 진짜인가"에 답합니다. DMARC는 그다음, 진짜가 아니면 어떻게 할까에 답합니다. 아무것도 하지 말고 보고서만 보내라, 스팸으로 보내라, 거부하라 — 받는 쪽에 대한 여러분의 지시입니다. 동시에 DMARC는 여러분 이름으로 오간 메일에 대한 집계 보고서(제3자의 위조 시도 포함)를 받는 주소이기도 합니다.
가장 완만한 정책인 "보고서만"으로 시작하세요. 강화는 나중에, 모든 정상 발신자(회계, CRM, 뉴스레터, 이 봇)가 검증을 통과함을 확인한 뒤에 하십시오. 너무 이르게 켠 엄격한 정책은 여러분 자신의 메일부터 잘라내기 시작합니다.
DMARC가 없으면: 받는 쪽마다 제각각 판단하고, 여러분은 자기 이름의 메일에 무슨 일이 일어나는지 결코 알 수 없습니다.
어떤 레코드를 추가하나
먼저 관리 화면에서 도메인을 등록합니다. Email 섹션 → "Sending domains" → "Add domain" 버튼. 대화 상자에는 입력란이 셋 있습니다. 도메인 자체(예: shop.example.com), 주소의 로컬 부분(@ 앞부분, 보통 noreply), 그리고 수신자가 주소 대신 보게 되는 발신자 이름입니다. 저장하면 DNS 레코드가 화면에 나타납니다.
셋 다 도메인 DNS의 TXT 레코드입니다. 도메인을 관리하는 곳(등록기관 관리 화면 또는 DNS 제공자)에서 추가합니다.
아래 값은 example.com을 예로 든 것이니 자신의 도메인으로 바꾸세요. 도메인별 정확한 값은 관리 화면의 도메인 카드에 표시되므로 거기서 복사하십시오. 특히 DKIM은 값에 여러분 고유의 공개 키가 들어 있어 도메인마다 다르며, 문서에서 가져올 수 없습니다.
화면에서 각 레코드는 "Host" 와 "Value" 두 개의 별도 입력란으로 나뉘어 있고, 각각 "Copy" 버튼이 있습니다. DNS 제공자의 해당 칸에 하나씩 복사해 넣으세요. 두 부분을 한 덩어리로 붙여넣을 수는 없습니다.
| 유형 | 레코드 이름(host) | 값 |
|---|---|---|
| TXT | mybot._domainkey.example.com | v=DKIM1; k=rsa; p= 뒤에 관리 화면의 긴 키 |
| TXT | example.com(도메인 루트) | v=spf1 include:esp.getmybot.dev ~all |
| TXT | _dmarc.example.com | v=DMARC1; p=none; rua=mailto:dmarc@example.com |
가장 많이 걸려 넘어지는 두 가지:
- 많은 관리 화면이 이름에 도메인을 자동으로 덧붙입니다. 이름 칸에 이미 ".example.com"이 보인다면 전체 이름이 아니라
mybot._domainkey만 입력하세요. 그러지 않으면mybot._domainkey.example.com.example.com이 됩니다. - DKIM 값은 길고, 키 내부에 줄바꿈이나 공백이 있으면 안 됩니다. 마우스로 끌어 선택하지 말고 복사 버튼을 쓰세요.
이미 SPF 레코드가 있다면
도메인에는 SPF 레코드가 하나만 있을 수 있습니다. 호스팅, CRM, 다른 뉴스레터 서비스로 이미 메일을 보내고 있다면 그 레코드는 존재합니다. 두 번째를 만들지 말고, 기존 레코드의 마지막 ~all 앞에 include를 하나 더 적으세요.
v=spf1 include:spf.your-provider.kr include:esp.getmybot.dev ~all
한 도메인에 SPF 레코드가 둘인 상태는 하나도 없는 것과 같은 오류입니다. 받는 쪽이 어느 쪽을 믿어야 할지 알 수 없어 검증이 통과되지 않습니다.
참고: 남의 레코드를 통해 "커버"되는 것으로는 충분하지 않습니다. 지금 쓰는 업체가 자기 SPF에 우리를 포함하고 있더라도, 우리 include는 여러분 레코드에 직접 있어야 합니다. 이유는 아래 도메인 확인 절을 보세요.
SPF에 IP 주소가 아니라 include를 쓰는 이유
가장 흔한 실수는 메일 헤더나 게시판에서 본 IP 주소를 붙여 넣는 것입니다. 그렇게 하지 마세요.
include:esp.getmybot.dev는 저희가 직접 관리하는 발송 서버 목록을 가리키는 포인터입니다. 지금 이 이름 뒤에는 중계 서버 한 대가 있습니다. 앞으로 대수가 늘거나, 옮겨 가거나, 교체될 수 있습니다. 그때 저희가 저희 쪽 목록을 갱신하면 여러분의 레코드는 아무것도 손대지 않아도 계속 동작합니다. 요점이 바로 이것입니다. 주소는 한 곳에서만 바뀌고, 고객마다의 DNS에서 바뀌지 않습니다.
손으로 적은 IP 주소는 그 순간부터 사실과 어긋납니다. 메일은 아무런 경고 없이 SPF를 통과하지 못하기 시작합니다. 관리 화면에 오류도, 알림도 없습니다. "아무것도 못 받았다"는 고객을 통해 알게 됩니다.
정확히 include:esp.getmybot.dev라고만 적고, 여기에 무엇도 덧붙이지 마세요.
도메인 확인
도메인 확인은 플랫폼이 직접 여러분 도메인의 DNS를 조회해 세 레코드가 모두 제대로인지 확인하는 절차입니다. 셋 다 통과하면 도메인은 확인됨 상태가 되고 발송이 허용됩니다. 하나라도 통과하지 못하면 대기 상태로 남습니다.
확인하는 것은 "레코드가 있는가"에 그치지 않습니다.
| 레코드 | 실제로 확인하는 내용 |
|---|---|
| DKIM | 레코드가 게시되어 있고 여러분 자신의 공개 키를 담고 있는지. 남의 DKIM이나 이전 키에서 남은 낡은 값은 통과하지 못합니다. |
| SPF | 레코드가 존재하고 직접 include:esp.getmybot.dev를 담고 있는지. include:esp.getmybot.dev.other-domain.example 같은 비슷한 값은 인정되지 않습니다. |
| DMARC | 레코드가 게시되어 있고 v=DMARC1으로 시작하는지. 정책 자체(p=, rua=)는 확인하지 않습니다. 그것은 여러분의 결정이지 우리에 대한 허가가 아니기 때문입니다. |
DMARC를 느슨하게 확인하는 이유: DMARC는 DKIM과 SPF 결과를 받는 쪽이 어떻게 처리할지를 지시할 뿐, 우리에게 여러분 이름으로 보낼 권한을 주지 않습니다. 그 권한은 앞의 두 레코드만이 주며, 둘 다 내용까지 온전히 확인됩니다.
남의 include는 인정되지 않습니다
include:esp.getmybot.dev는 여러분 자신의 SPF 레코드에 있어야 합니다. 여러분의 SPF가 제3의 업체를 include하고 그 업체의 레코드가 다시 우리를 include하더라도 확인은 이를 받아들이지 않습니다. 플랫폼은 남의 include 사슬을 따라가지 않습니다. 이유는 단순합니다. "바로 이 도메인이 우리를 허가했는가"라는 물음의 답을 흐리지 않기 위해서입니다.
실무적으로는, "업체를 통해 커버된다"고 확신하더라도 우리 include를 여러분 레코드에 직접 넣으십시오. 화면 자체의 SPF 설명에도 같은 말이 있습니다. 도메인에 이미 SPF 레코드가 있다면 레코드를 통째로 바꾸지 말고 그 안에 include:... 값을 추가하라는 것입니다. 그 도메인은 우리 말고 다른 경로로도 메일을 보낼 수 있기 때문입니다. 이 안내는 항상 표시되며, 확인이 실패한 뒤에야 나타나는 것이 아닙니다.
DNS는 즉시 갱신되지 않습니다. 등록기관에서 저장한 뒤 레코드가 네임서버로 퍼져야 합니다. 보통 몇 분, 때로는 몇 시간, 드물게는 하루까지 걸립니다. 제공자와 TTL에 따라 다릅니다. 이는 정상이며 저희가 앞당길 수 없습니다.
그렇다고 가만히 기다릴 필요는 없습니다. 플랫폼은 대기 중인 도메인을 한 시간에 한 번 스스로 다시 확인하지만, 도메인 카드에는 "Verify now" 버튼이 있습니다. 같은 확인을 즉시 실행하고 결과를 바로 화면에 보여 줍니다. 레코드를 저장한 직후에 누르세요. 오타가 있으면 한 시간 뒤가 아니라 1초 만에 알 수 있습니다. 몇 번이든 눌러도 됩니다.
도메인 상태는 카드에 표시됩니다. "Pending verification", "Verified", "Not verified" 중 하나입니다. 확인되기 전까지는 카드에 "Sending from this domain is disabled until it is verified."라는 경고도 함께 표시됩니다.
결과는 단순한 "실패"가 아닙니다. 세 레코드는 각각 화면에서 자기 상태 — "Passing", "Not passing", "Not checked yet" — 와 무엇이 잘못됐는지 설명하는 줄을 갖습니다.
SPF에 대해서는 화면이 두 가지 상황을 구분하며, 이것이 전체 절차에서 가장 중요한 구분입니다.
- 도메인에 SPF 레코드가 아예 없는 경우. 위 표의 값으로 하나 게시하세요.
- SPF 레코드는 있지만 우리 include가 없는 경우. 이미 있는 레코드에 include를 덧붙이세요. 두 번째를 만들지 말고, 통째로 교체하지도 마세요. 같은 메시지가 사슬 사례도 명시적으로 다룹니다. include가 다른 업체의 SPF 레코드를 거쳐서만 우리에게 닿는다면 인정되지 않습니다. 사슬은 따라가지 않기 때문입니다.
두 번째 경우가 이 절차에서 가장 헷갈리는 순간입니다. 레코드는 이미 있고, 방금 직접 읽어 보기까지 했는데 확인은 계속 거부합니다. 이제 오류 메시지는 레코드 옆에 항상 표시되는 안내와 똑같은 말을 합니다. 이미 있는 것에 우리 include를 덧붙이라는 것입니다.
확인이 통과되지 않으면:
- 셋 중 어느 레코드가 "Not passing"인지, 그 설명에 뭐라고 쓰였는지 읽고 그에 따라 조치하세요.
- 레코드가 정말 게시되었는지 확인하세요. 많은 관리 화면은 "변경 사항 적용"을 따로 눌러야 합니다.
- 레코드 이름에 도메인이 두 번 들어갔는지 확인하세요(위 설명 참조).
- SPF 레코드가 하나뿐인지, 그리고 우리 include가 바로 그 레코드 안에 있는지 확인하세요.
- 잠시 기다렸다가 다시 확인하세요. 변경이 아직 퍼지지 않았을 수 있습니다.
확인 전에는 발송이 동작하지 않습니다 — 의도된 동작입니다
도메인이 확인되기 전까지 메일은 발송되지 않습니다. "발송되었는데 스팸으로 갔다"가 아니라 아예 나가지 않습니다. 시도는 미확인 도메인 오류로 끝나고, 기록에 남습니다.
이는 의도된 설계이지 장애가 아닙니다. 스스로를 보증하지 않은 도메인에서 나간 메일은 스팸 신고로 이어지고, 신고는 플랫폼의 모든 고객이 공유하는 발송 인프라의 평판을 해칩니다. 메일 한 통을 보내지 않는 편이, 보내고 나서 반년 동안 차단 목록에서 빠져나오는 것보다 쌉니다. 그래서 경고가 아니라 금지입니다.
이 오류를 보면 지원팀에 문의하기 전에 DNS 레코드를 확인하고 확인 버튼을 누르세요. 대부분은 레코드 이름의 오타입니다.
수신 거부, 신고, 배달 실패
미리 알지 못하면 놀라게 되는 세 가지 규칙입니다.
모든 마케팅 메일에는 한 번의 클릭으로 되는 수신 거부가 들어갑니다. 플랫폼이 메일 하단의 수신 거부 링크와, 메일 앱이 발신자 주소 옆에 "수신 거부" 버튼을 그리는 데 쓰는 기술 헤더를 스스로 넣습니다. 설정으로도, 메일 디자인으로도 없앨 수 없습니다. 수신 거부는 메일을 열지 않아도, 확인 단계 없이 즉시 적용됩니다. Gmail을 비롯한 대형 서비스가 대량 발신자에게 요구하는 사항으로, 이것이 없는 메일은 확실히 스팸으로 갑니다.
수신 거부는 최종적이며 관리 화면에서 되돌릴 수 없습니다. 거부한 주소는 이 봇의 메일을 더 이상 받지 않습니다. "복구" 버튼도 없고, 목록을 다시 가져오는 우회로도 없습니다. 본인의 뜻을 건너뛰고 취소되는 일은 없습니다. 돌아오는 것은 본인만 할 수 있으며, 여러분의 구독 양식에 주소를 다시 남기는 방법뿐입니다.
더 엄격한 경우도 있습니다. 메일 앱에서 **"스팸으로 신고"**를 누른 경우 주소는 영구히 닫힙니다. 여러분의 양식으로 다시 구독해도 열리지 않습니다. 지난 시도가 어떻게 끝났는지 이미 알고 있고, 그런 주소로 다시 보내는 것이 도메인 평판을 가장 빨리 무너뜨리기 때문입니다. 법적 요청으로 수동 차단된 주소도 동일합니다.
영구 배달 실패는 주소를 영원히 차단합니다. 수신자의 메일 서버가 그런 사서함이 없다고 답하면 주소는 배달 불가로 표시되어 이후 발송에서 제외됩니다. 일시적인 상태가 아닙니다. 존재하지 않는 사서함을 계속 두드리는 것은 나머지 모든 주소까지 함께 스팸 필터에 걸리는 가장 빠른 길입니다.
일시적 실패(사서함 가득 참, 서버 일시 장애)는 주소를 닫지 않습니다. 발송은 계속됩니다.
열람 수가 실제보다 낮게 나오는 이유
메일 통계에는 열람 수가 있는데, 언제나 실제보다 작습니다. 집계 오류가 아니라 열람을 측정하는 방식 자체 때문입니다.
열람은 메일 앱이 메일을 표시할 때 서버에서 아주 작은 추적 이미지를 불러오면 기록됩니다. 요즘 앱은 기본적으로 원격 이미지를 불러오지 않습니다. 불러오는 앱(Apple Mail 등 프라이버시 기능)은 메일을 한 번도 열지 않은 사람 몫까지 미리 일괄로 불러옵니다. 앞의 경우 열람이 사라지고, 뒤의 경우 있지도 않은 사람에게 열람이 기록됩니다. 메일 열람을 이보다 정확히 세는 방법은 저희에게도, 다른 누구에게도 없습니다.
그래서 화면에서는 이 숫자 옆에 단서를 붙여 둡니다. 이것은 하한값이지 정확한 수치가 아닙니다. 같은 왜곡이 모든 메일에 똑같이 적용되므로 메일끼리 비교하는 데는 쓸 수 있지만, "몇 명이 읽었는가"의 답으로는 쓸 수 없습니다.
믿을 만한 참여 지표가 필요하면 "Link clicks" 를 보세요. 링크 클릭은 실제 사람의 실제 행동이며, 누구도 대신 미리 눌러 주지 않습니다. "Delivered", "Unsubscribes", "Complaints", "Bounces" 도 정확히 집계됩니다. 이들은 메일 서버가 보고하는 것이지 메일 속 이미지가 아니기 때문입니다. 모두 같은 Email 화면의 "Sending stats" 블록에 있습니다.