> ## Documentation Index
> Fetch the complete documentation index at: https://supastack.dev/llms.txt
> Use this file to discover all available pages before exploring further.
> For the full documentation corpus in one file, fetch: https://supastack.dev/llms-full.txt

# Resend 이메일 추가

무료 Resend 계정을 만들고 발신 도메인을 확인한 후 EMAIL_PROVIDER를 전환하여 코드와 영수증이 실제 받은 편지함에 도달하도록 합니다.

## 초보자 연습

전제 조건: 로컬에서 실행 중인 앱(5분 만에 출시). 무료로 시작하세요—카드 없이, Resend의 무료 등급은 개발 볼륨을 커버합니다.

용어 정리: `EMAIL_PROVIDER=local`이 기본값입니다—메시지는 내장 `/mail-preview` 페이지에 기록되고 머신을 떠나지 않아 빌드하는 동안 완벽합니다. Resend는 실제 받은 편지함에 전달하는 어댑터입니다. `EMAIL_FROM`은 템플릿이 사용하는 발신자 ID이며 그 주소는 Resend가 확인한 도메인에 있어야 합니다. DNS 레코드는 수신 사서함이 발신자를 신뢰하도록 등록 기관이나 Cloudflare에 붙여넣는 줄입니다.

만드는 것: Resend 계정, 확인된 발신 도메인, API 키 하나—도메인 단계가 유일한 대기 부분으로 DNS 전파는 몇 분에서 몇 시간까지 걸립니다.

[데이터베이스 설정](https://supastack.dev/ko/docs/web/setup-database.md)


## Resend 계정 만들기

1. [resend.com](https://resend.com) → Sign up을 열고 이메일을 확인하면 대시보드에 도달합니다.

2. 무료 등급으로 시작하세요—도메인을 소유하기 전에도 Resend의 공유 발신자에서 테스트 메일을 보낼 수 있으며 이는 다음 섹션에서 다룹니다.


## 발신 도메인 확인

빠른 시도, 도메인 불필요: `onboarding@resend.dev` 주소는 `EMAIL_FROM`으로 즉시 작동합니다—하지만 가입한 이메일로만 전달되고 사용자에게는 절대 전달되지 않습니다. 파이프라인이 작동하는 것을 보는 데 사용한 후 실제 설정을 진행하세요.

1. Domains → Add Domain을 열고 발신할 도메인을 입력합니다(예: `yourdomain.com`; `mail.yourdomain.com` 같은 하위 도메인도 작동하며 레코드를 깔끔하게 유지합니다).

2. Resend가 생성할 DNS 레코드를 나열합니다—DKIM TXT 레코드와 계정 연령에 따른 MX/SPF 또는 CNAME 항목입니다. 각 항목을 DNS 호스트에 추가합니다: 등록 기관의 DNS 페이지 또는 네임서버를 옮겼다면 Cloudflare입니다. Cloudflare에서는 메일 레코드의 프록시 구름을 회색(DNS only)으로 유지하세요—프록시된 레코드는 절대 확인되지 않습니다.

3. Resend로 돌아가 Verify를 클릭합니다. 예상 결과: 도메인이 Verified로 바뀝니다. 전파는 몇 분에서 하루까지 다양하며 도메인 페이지가 아직 확인되지 않은 정확한 레코드를 지명합니다.

확인되면 해당 도메인의 모든 주소가 발신자로 작동합니다—`hello@`, `no-reply@`, `EMAIL_FROM`이 사용하는 모든 것—주소별 등록이 필요하지 않습니다.


## API 키 만들기

1. API Keys → Create API Key를 엽니다.

2. Permission: Sending access면 충분합니다—킷은 보내기만 합니다. 환경에 맞게 키 이름을 지정하고(`production`, `local`) 유출된 개발 키를 프로덕션을 건드리지 않고 취소할 수 있게 합니다.

3. `re_…` 키를 지금 복사하세요—한 번만 표시됩니다. 잃어버리면 다른 키를 만들면 됩니다.


## 앱에 값 추가

아래 줄을 `apps/web/.env.local`에 설정합니다. `RESEND_API_KEY`는 서버 전용입니다—`NEXT_PUBLIC_`/`EXPO_PUBLIC_`에 넣지 말고 커밋도 하지 마세요. `EMAIL_PROVIDER`와 `EMAIL_FROM`은 일반 구성입니다. 편집 후 개발 서버를 재시작하세요.

`EMAIL_FROM`은 확인된 도메인에 있어야 합니다: `onboarding@resend.dev`는 본인의 가입 주소로만 도달하고 확인되지 않은 도메인은 Resend에서 403 거부를 받습니다.

```
# apps/web/.env.local
EMAIL_PROVIDER=resend
EMAIL_FROM="Your Product <hello@yourdomain.com>"
RESEND_API_KEY=re_…
```


## 확인 및 문제 해결

재시작하고 `/auth`를 열어 본인이 제어하는 실제 받은 편지함으로 로그인 코드를 요청합니다. 예상 결과: 메시지가 도착하고 Resend → Emails에 녹색 상태로 전달이 표시됩니다—해당 로그는 바운스와 오류 이유가 있는 곳이기도 합니다.

발송되지 않았나요? `apps/web/.env.local`에 `EMAIL_PROVIDER=resend`가 실제로 저장되었는지 확인하고 재시작하세요. 서버 로그의 403은 `EMAIL_FROM`이 확인된 도메인에 없음을 의미합니다—또는 `onboarding@resend.dev`가 본인이 아닌 사람에게 발송된 것입니다.

나중에 다른 공급자로요? `EMAIL_PROVIDER`는 `ses`(AWS 키와 함께)와 `postmark`, `sendgrid`, `mailgun`, `smtp`, `brevo` 전송도 허용합니다—같은 `EMAIL_FROM` 계약에 env 이름만 다르며 모두 `.env.example`에 나열되어 있습니다. 이메일 가이드가 이들을 비교합니다.

[이메일 공급자 비교](https://supastack.dev/ko/docs/web/setup-email.md)

[다음으로 나머지 공급자 키 수집](https://supastack.dev/ko/docs/web/provider-keys.md)


설정을 계속하려면 [Amazon SES 이메일 설정](https://supastack.dev/ko/docs/web/aws-ses.md) 가이드를 읽어보세요.


## 다음

[Amazon SES 이메일 설정](https://supastack.dev/ko/docs/web/aws-ses.md)