앱에서 이메일 보내는 방법 (받은편지함에 도착하도록)

앱에서 이메일을 안정적으로 보내려면 사용자 본인의 메일함이 아니라 이메일 발송 서비스를 쓰고, 내 도메인의 주소로 보내며, 서비스가 제공하는 DNS 레코드를 추가해 SPF, DKIM, DMARC가 모두 통과하도록 해야 합니다. 비밀번호 재설정, 영수증, 확인 메일처럼 트랜잭션 이메일은 마케팅 이메일과 분리하고, 각 메일은 받기를 예상하는 사람에게만 보내며, 반송과 수신거부를 처리하세요. 인증을 먼저 제대로 설정하는 것이 앱 이메일이 스팸함으로 가는 가장 흔한 원인을 막는 방법입니다.

트랜잭션 이메일과 마케팅 이메일

이 두 종류의 이메일은 코드로 보면 비슷해 보이지만, 받은편지함 서비스와 법률에서 매우 다르게 다룹니다.

둘을 분리해 두세요. 마케팅 캠페인이 스팸 신고를 받으면, 같은 채널의 비밀번호 재설정 메일까지 피해를 보게 됩니다. 흔한 방법은 서브도메인을 나누는 것입니다. 예를 들어 계정 메일에는 mail.example.com을, 뉴스레터에는 news.example.com을 씁니다. 일부 서비스는 내부적으로 둘을 분리하기도 합니다. 예를 들어 Postmark는 2026년 9월 기준으로 트랜잭션 메시지 스트림과 브로드캐스트 메시지 스트림을 별도의 발송 인프라에서 운영한다고 설명합니다.

발송 서비스 선택

앱이 자체 서버에서 직접 이메일을 보내서는 안 됩니다. 발송 서비스는 인프라, IP 평판, 재시도, 반송 처리를 대신 맡아 줍니다. 잘 알려진 선택지로는 Postmark, Resend, SendGrid, Amazon SES, Mailgun 등이 있습니다. 각각 HTTP API와 SMTP 접근을 제공하며, 가격과 요금제는 바뀔 수 있으니 각 사이트에서 직접 비교하세요.

비교할 항목은 다음과 같습니다.

• 초점. 트랜잭션 메일에 집중하는 서비스도 있고, 트랜잭션과 마케팅을 함께 제공하는 서비스도 있습니다.
• 개발자 경험. 명확한 API, 사용하는 언어의 공식 라이브러리, 메일이 전달되었는지, 반송되었는지, 스팸으로 표시되었는지 보여 주는 유용한 로그.
• 웹훅. 반송, 불만 신고, 전달 결과를 앱이 받아서 처리할 수 있도록 하는 기능.
• 템플릿. 서비스에 저장할지, 내 코드에 둘지. 코드에 두면 버전 관리와 테스트가 가능합니다.
• 리전과 데이터 처리 방식. 데이터가 어디에서 처리되는지에 대한 요구사항이 있다면 확인하세요.
• 내 발송량 기준의 비용. 무료 한도를 넘었을 때 어떻게 되는지 포함해서 계산하세요.

목록을 대상으로 뉴스레터를 보낸다면, 앱에 캠페인 기능을 직접 만들기보다 전용 뉴스레터나 이메일 마케팅 도구가 더 잘 맞는 경우가 많습니다.

발송 도메인 설정

hello@example.com처럼 내 도메인의 주소로 보내세요. Gmail이나 Outlook 주소를 쓰면 안 됩니다. 제3자 서비스를 통해 무료 메일함 주소로 보낸 메일은 인증 검사에 실패하고 걸러질 가능성이 큽니다.

발송 전용 서브도메인을 고려해 보세요. 예를 들어 Resend는 2026년 9월 기준으로 updates.example.com 같은 서브도메인에서 보내도록 권장하여 발송 평판을 분리합니다. 이렇게 하면 이메일용 DNS 레코드도 메인 사이트와 분리됩니다.

그다음 서비스가 제공하는 DNS 레코드를 도메인의 DNS 관리 화면에 추가하세요. DNS가 익숙하지 않다면 도메인과 DNS의 동작 원리에서 레코드부터 먼저 살펴보세요.

SPF

SPF(Sender Policy Framework)는 어떤 서버가 내 도메인 이름으로 메일을 보낼 수 있는지 나열한 TXT 레코드입니다. 수신 측은 발송 서버가 이 목록에 있는지 확인합니다.

• 도메인에는 SPF 레코드가 하나만 있어야 합니다. 서비스를 추가할 때는 두 번째 레코드를 만들지 말고, 기존 레코드에 합치세요.
• SPF 평가 시 DNS 조회는 최대 10번까지 허용됩니다. include: 항목이 길게 이어지면 이 한도를 넘어 실패할 수 있습니다.
• 많은 서비스는 여러분이 만들도록 요청하는 return-path 서브도메인에 SPF를 설정하므로, 메인 SPF 레코드는 건드리지 않아도 될 수 있습니다.

DKIM

DKIM(DomainKeys Identified Mail)은 각 메일에 암호화 서명을 추가합니다. 서비스가 비밀 키로 서명하고, 여러분은 짝이 되는 공개 키를 DNS 레코드(서비스에 따라 TXT 또는 CNAME)로 게시합니다. 수신 측은 서명을 확인해 메일이 승인된 발신자에게서 왔고 중간에 변조되지 않았는지 검사합니다.

서비스의 "도메인 확인" 단계는 대부분 DKIM과 관련된 것입니다. 건너뛰지 마세요.

DMARC

DMARC는 앞의 두 가지를 하나로 묶어 줍니다. _dmarc.yourdomain.com에 있는 TXT 레코드로, 수신 측에 다음을 알려 줍니다.

• 정렬(Alignment): 화면에 보이는 From 주소의 도메인이 SPF나 DKIM을 통과한 도메인과 일치해야 합니다.
• 정책(Policy): 인증에 실패한 메일을 어떻게 처리할지. p=none(보고만 함), p=quarantine(의심 메일로 격리, 보통 스팸함), p=reject(거부) 중 선택합니다.
• 리포트: 집계 보고서를 받을 주소(rua=). 내 도메인 이름으로 누가 메일을 보내고 있는지 확인할 수 있습니다.

현실적인 방법은 p=none과 보고 주소로 시작해서, 정상 메일이 통과하는지 확인한 뒤 quarantine으로 올리고, 마지막에 reject로 가는 것입니다. 엄격한 정책은 다른 사람이 내 도메인을 위조하기도 훨씬 어렵게 만듭니다.

Gmail의 요구사항

2026년 9월 기준으로 Google의 발신자 가이드라인은 다음과 같습니다.

• 모든 발신자가 개인 Gmail 계정으로 보낼 때는 SPF 또는 DKIM, 발송 서버의 유효한 정방향 및 역방향 DNS, TLS, 그리고 Postmaster Tools에서 확인되는 스팸 신고율 0.3% 미만이 필요합니다.
• 대량 발신자(Gmail로 하루 5,000통 초과)는 SPF 와 DKIM, DMARC 레코드(p=none 정책도 허용됨), From 도메인 정렬, 그리고 마케팅 및 구독 메일에 대한 원클릭 수신거부와 눈에 보이는 수신거부 링크가 필요합니다.

서버 쪽 작업은 서비스 제공업체가 처리합니다. DNS 레코드와 수신거부 처리는 여러분의 몫입니다. 하루 5,000통에 가깝지 않더라도, 대량 발신자 규칙을 지키는 것이 가장 간단하게 안전을 확보하는 방법입니다.

앱에 발송 기능 붙이기

발송 도메인 확인이 끝나면 다음을 따르세요.

1. API 키를 서버 측 비밀 값으로 저장하세요. 프론트엔드 코드에는 절대 넣지 마세요. 환경 변수와 비밀 값이란 무엇인가를 참고하세요.
2. 서버에서 보내세요. 메일을 유발하는 작업이 성공한 뒤에 발송합니다.
3. 사용자가 메일 발송을 기다리게 하지 마세요. 가장 단순한 앱을 넘어서면 발송을 큐에 넣고 일시적 실패는 재시도해서, 발송 서비스의 응답이 느려도 가입이 느려지지 않도록 하세요.
4. 결과를 기록하세요. 서비스의 메시지 ID와 상태를 남기되, API 키나 개인정보가 담긴 메일 본문 전체는 기록하지 마세요.
5. 반송과 불만 신고용 웹훅을 처리하세요. 영구 반송되었거나 스팸으로 신고한 주소에는 더 이상 보내지 않습니다.

기본을 담은 프롬프트 예시입니다.

[PROVIDER]를 사용해 트랜잭션 이메일을 보내 주세요. 서버 비밀 값은 [ENV_NAME]이고, 보내는 사람은 "Acme hello@mail.acme.com"입니다. 가입 후에는 환영 메일을, 예약이 저장되면 예약 확인 메일을 보내 주세요. 템플릿은 코드에 두고, HTML과 함께 텍스트 버전도 만들어 주세요. 발송은 큐에 넣고 일시적 실패는 최대 3번까지 재시도해 주세요. 실패는 서비스의 오류 내용과 함께 기록하되 API 키는 절대 기록하지 마세요. 영구 반송이나 불만 신고를 받으면 해당 주소를 발송 불가로 표시하고, 이후 발송에서 제외하는 웹훅 엔드포인트를 추가해 주세요.

인증 메일, 즉 인증 링크, 매직 링크, 비밀번호 재설정은 로그인 기능의 일부입니다. 앱에 로그인 기능을 추가하는 방법에서 이 흐름들이 어떻게 맞물리는지 설명합니다. 이 링크들은 한 번만 사용할 수 있고 유효 기간이 짧아야 합니다.

전달률을 높이는 습관

인증은 메일이 고려 대상이 되게 해 줍니다. 그다음을 지켜 주는 것은 행동입니다.

• 사람들이 기대하는 메일만 보내세요. 확인된 가입자, 마케팅 메일은 명확한 수신 동의를 받은 대상, 구매한 명단은 사용하지 않기.
• 엄격한 트랜잭션 메일이 아닌 메일에는 수신거부를 쉽게 하고, 요청이 오면 바로 반영하세요.
• 새 도메인은 점진적으로 키우세요. 완전히 새 도메인이 첫날부터 수천 통을 보내면 의심을 받습니다. 트랜잭션 메일로 시작해서 발송량을 천천히 늘리세요.
• 명단을 깨끗하게 유지하세요. 영구 반송 주소는 즉시 삭제하고, 오랫동안 아무것도 열어 보지 않은 사람은 제외를 고려하세요.
• 사람이 쓴 것처럼 작성하세요. 명확한 제목, 알아볼 수 있는 보내는 사람 이름, 텍스트 파트, 적은 이미지, 내 도메인으로 연결되는 링크. 단축 링크는 피하세요.
• 모니터링하세요. Google Postmaster Tools에 도메인을 등록하고, DMARC 리포트를 가끔 확인하세요.
• 실제로 읽는 답장 주소를 쓰세요. 답장은 좋은 신호이자 유용한 피드백입니다.

아무에게도 스팸을 보내지 않고 테스트하기

• 서비스에 테스트 모드나 샌드박스가 있다면 이를 사용하세요. 아니면 내가 소유한 주소로 보내세요.
• 개발 중에는 실제 사용자 대신 모든 메일을 받는 테스트 수신함으로 보내세요. 실제처럼 보이는 주소가 가득한 시드 데이터베이스는 실수로 낯선 사람에게 메일을 보내는 가장 쉬운 방법입니다.
• 템플릿은 여러 클라이언트에서 확인하세요. 웹의 Gmail, 휴대폰 메일 앱, Outlook, 그리고 다크 모드까지 살펴보세요.
• 테스트 메일의 헤더를 보세요. SPF, DKIM, DMARC가 통과했는지 나타납니다.

법적 기본 사항

규정은 나라마다 다릅니다. 대체로 마케팅 이메일은 많은 곳에서 동의가 필요하고, 보내는 사람을 밝혀야 하며, 작동하는 수신거부를 제공해야 합니다. 트랜잭션 이메일은 다르게 취급되지만, 마케팅을 슬쩍 끼워 넣는 데 쓰면 안 됩니다. 대기자 명단 페이지에서 주소를 받는다면, 각 사람이 언제 어떻게 가입했는지, 무엇을 보내고 저장할지 알려 주세요. 확신이 서지 않으면 사용자가 있는 곳의 규정을 확인하세요.

이메일 체크리스트

• 발송 서비스를 선택했고, API 키는 서버 비밀 값으로 저장됨
• 무료 메일함이 아니라 내 도메인 또는 서브도메인으로 발송
• SPF, DKIM, DMARC 레코드를 추가했고 통과함
• 트랜잭션 메일과 마케팅 메일을 분리함
• 발송은 큐에 넣고 재시도하며, 결과를 기록함
• 반송과 불만 신고 웹훅을 처리함
• 트랜잭션이 아닌 메일에는 수신거부가 있고 즉시 반영됨
• 템플릿을 여러 클라이언트에서 테스트했고, 테스트 메일이 실제 사용자에게 가지 않음

Mythex 앱에서 이메일 보내기

Mythex는 여러분이 만든 앱을 위한 이메일 발송 서비스를 기본으로 제공하지 않으므로, Resend, SendGrid, Postmark 같은 서비스를 직접 연결해야 합니다. 발송 서비스의 API 키는 프로젝트 비밀 값으로 저장하세요. 에이전트가 채팅의 비밀 값 카드를 통해 키를 요청할 수 있습니다. 그다음 필요한 메일을 평범한 말로 요청하면 됩니다. 앱에서 이메일 보내기 문서에 시작용 프롬프트가 있습니다. Pro 플랜에서 Mythex를 통해 도메인을 구매했다면, 도메인의 DNS 설정에서 서비스가 요구하는 TXT와 CNAME 레코드를 추가할 수 있습니다. 자세한 내용은 커스텀 도메인을 참고하세요.

자주 묻는 질문