AI 에이전트의 이메일을 스팸이 아닌 받은 편지함에 안착시키기

AI 에이전트에게 실제 메일함을 부여하고 첫 번째 이메일 배치를 보냈더니, 그중 절반이 스팸함으로 들어갔습니다. 에이전트는 잘못한 것이 없습니다. 도메인이 잘못되었습니다. 도메인이 새로 생성되었고, 발송 이력이 없으며, 메일 서비스 제공업체(Mailbox providers)는 갑자기 대량의 메일을 보내는 알 수 없는 도메인을 스패머와 동일하게 취급하기 때문입니다. 도달률(Deliverability)은 해당 메일이 정말 당신의 것임을 증명하고, 제공업체가 신뢰할 수 있는 속도로 발송하며, 수신자가 메일을 원하는지를 나타내는 신호들을 모니터링하는 작업입니다.

에이전트 계정(Agent Account)은 당신이 소유한 도메인에서 발송하므로, 그 편지함 배치(Inbox placement)는 회사의 다른 메일과 마찬가지로 당신이 관리해야 할 영역입니다. 이 포스트는 백엔드를 위한 HTTP API와 터미널을 위한 Nylas CLI라는 두 가지 측면에서, 에이전트를 받은 편지함에 안착시키고 유지하기 위한 실질적인 플레이북(Playbook)을 제공합니다. 저는 CLI를 담당하고 있으므로, 아래의 터미널 명령어들은 제가 모니터링을 연결할 때 사용하는 것들입니다.

도달률 체크리스트

다섯 가지 요소가 에이전트 계정이 받은 편지함에 도달할지를 결정하며, 대량 발송을 시작하기 전에 이 모든 항목에 조치를 취할 수 있습니다. 순서대로 진행하세요. 수신 서버가 메일이 당신의 것인지 확인할 수 없다면 다른 것은 아무런 의미가 없으므로 인증(Authentication)을 가장 먼저 해야 하며, 그 다음 메일이 흐르기 시작하면 속도(Pace)와 모니터링을 진행합니다.

도메인 인증 (Authenticate the domain): 도메인 검증의 일환으로 DKIM 및 SPF를 사용하여 인증합니다.
DMARC 설정: 인증에 실패한 메일을 제공업체가 어떻게 처리해야 하는지 알 수 있도록 DMARC를 설정합니다.
새 도메인 웜업 (Warm up a new domain): 대량 발송 전, 약 4주에 걸쳐 도메인을 예열합니다.
바운스 및 불만 사항 모니터링 (Monitor bounces and complaints): 도달률 웹훅(Deliverability webhooks)을 통해 바운스(Bounces)와 신고(Complaints)를 모니터링합니다.
바운스 및 불만 사항 임계값 유지: 발송을 중단시키는 바운스 및 불만 사항 임계값(Thresholds)을 넘지 않도록 유지합니다.

이 포스트의 나머지 부분에서는 이를 연결하기 위한 명령어와 요청 본문(Request bodies)과 함께 각 항목을 다룹니다.

DKIM 및 SPF를 통한 인증

인증(Authentication)은 기초이며, 에이전트 계정(Agent Account)의 경우 도메인 설정 중에 이미 게시하는 두 가지 레코드(records)를 기반으로 합니다. DKIM은 메시지가 변경되지 않았으며 실제로 귀하의 도메인에서 발송되었음을 증명하는 암호화 서명(cryptographic signature)을 추가합니다. SPF는 귀하를 대신하여 메시지를 보낼 수 있도록 송신 인프라(sending infrastructure)에 권한을 부여합니다. 커스텀 도메인이 계정을 호스팅하기 전에 두 가지 모두 검증되어야 하므로, 검증된 에이전트 계정 도메인은 이미 DKIM 및 SPF 인증을 마친 상태입니다.

CLI를 통해 도메인 등록 및 검증을 수행할 수 있습니다. nylas domains create는 도메인을 등록하고, nylas domains dns는 게시할 레코드를 보여주며, nylas domains verify는 레코드가 전파(propagate)된 후 검증을 트리거합니다:

nylas domains create agents.yourcompany.com
nylas domains dns agents.yourcompany.com
nylas domains verify agents.yourcompany.com

동일한 흐름이 Manage Domains API를 통해서도 실행되며, 이 API는 DNS 제공업체에 복사할 각 레코드의 호스트(host), 유형(type), 값(value)을 반환합니다. 검증은 보통 몇 분 이내에 성공하지만, DNS는 레코드의 TTL(Time To Live)에 따라 최대 24시간이 걸릴 수 있습니다. DNS 설정 가이드에서는 각 제공업체에서 레코드를 게시하는 방법을 단계별로 안내합니다. 도메인이 검증되면 DKIM 및 SPF 설정은 완료됩니다. 남은 하나의 인증 계층은 DMARC이며, 이는 직접 추가해야 합니다.

단계별 DMARC 설정

DMARC는 귀하의 도메인에서 발송된 것으로 주장하는 메시지가 인증에 실패했을 때 수신 서버가 어떻게 처리해야 하는지를 알려주며, 누가 귀하를 사칭하여 보내고 있는지 보고합니다. DMARC는 DKIM과 SPF를 기반으로 구축됩니다. 메시지가 DKIM 또는 SPF 중 하나를 통과하고 가시적인 From 주소의 도메인과 일치(align)하면 DMARC를 통과하게 됩니다. 에이전트 계정은 귀하의 도메인 DKIM 키로 서명하고 검증된 도메인에서 발송하므로, DMARC 레코드를 게시하는 즉시 일치(alignment)가 작동합니다.

모든 인증이 정상적으로 작동하는지 확인하기 전에 합법적인 메일이 차단되는 것을 방지하려면 세 단계에 걸쳐 점진적으로 적용하십시오. _dmarc.yourdomain.com에 TXT 레코드를 하나 추가한 다음, 보고서가 깨끗하게 들어오는 것을 확인하며 몇 주에 걸쳐 정책을 강화하십시오.

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; pct=100

p=none으로 모니터링하십시오. 메일은 정상적으로 전달되지만, 서비스 제공업체가 귀하의 rua 주소로 집계 보고서 (aggregate reports)를 보내므로 에이전트의 메일이 인증 및 일치 (alignment)되는지 확인할 수 있습니다.
p=quarantine으로 격리하십시오. 보고서가 깨끗해 보이면 인증에 실패한 메일을 스팸으로 보냅니다. pct=25를 사용하여 인증에 실패한 메일의 4분의 1에만 정책을 적용하며 점진적으로 도입한 후, 이를 100으로 높이십시오.
p=reject로 거부하십시오. 최종 단계로, 수신 서버가 DMARC 인증에 실패한 메일을 즉시 거부합니다.

정책을 강화하기 전에 각 단계마다 몇 주 동안 깨끗한 보고서가 유지되는지 확인하십시오. DMARC는 도메인 검증 (domain verification)의 일부가 아닙니다. API를 통해서가 아니라 DNS에서 직접 관리하는 별도의 레코드이지만, 스푸핑 (spoofing)에 대응하기 위해 추가할 수 있는 가장 효과적인 보호 수단입니다. rua 주소는 실제로 확인하는 메일함이나 모니터링 서비스로 지정하십시오.

새 도메인 워밍업 (Warm up)

완전히 새로운 도메인은 평판 (reputation)이 없으므로, 갑작스러운 메일 발송 급증은 스팸으로 간주되어 필터링됩니다. 워밍업 (Warming up)이란 실제 수신자가 메일을 열고 답장하는 동안 약 4주에 걸쳐 발송량을 점진적으로 늘리는 것을 의미합니다. 에이전트 계정 (Agent Account)이 구축하는 평판은 해당 도메인과 연결되어 있으므로, 새로운 커스텀 도메인을 출시하거나 여러 도메인으로 트래픽을 분산할 때 워밍업이 가장 중요합니다. 평판은 도메인 간에 전이되지 않으므로 각 도메인을 개별 일정에 따라 워밍업하십시오.

다음은 일일 목표 메시지 수 500~~1,000건을 향해 일주일 동안 매일 10~~20%씩 증가시키는 대표적인 램프업 (ramp) 예시입니다:

주차	일일 이메일 수	비고
1주차	5 ~ 15	매우 낮은 수치로 시작하여, 참여도가 높은 수신자에게 집중
...

숫자만큼 중요한 두 가지 사항이 있습니다. 모든 메시지를 한꺼번에 발송하기보다는 자연스러운 패턴을 모방할 수 있도록 메시지 사이에 지연 시간을 두어 업무 시간 동안 분산하여 발송하십시오. 그리고 이메일을 기다리고 참여할 수신자에게만 발송하십시오. 왜냐하면 오픈(opens), 클릭(clicks), 특히 답장(replies)은 생성할 수 있는 가장 강력한 긍정적 신호이기 때문입니다. 웜업 (warm-up) 기간 중의 발송은 일반적인 에이전트 계정 (Agent Account) 발송과 동일합니다. 즉, 평소에 사용하는 POST /v3/grants/{grant_id}/messages/send 또는 터미널에서의 nylas email send와 같습니다:

nylas email send \
  --to engaged-recipient@example.com \
  --subject "Your booking confirmation" \
...

웹훅 (webhooks)으로 전달 모니터링하기

nylas webhook create \
  --url https://yourapp.example.com/webhooks/nylas \
  --triggers message.delivered,message.bounced,message.complaint,message.rejected

API를 통한 동일한 구독은 트리거 (triggers)와 콜백 URL (callback URL)을 포함하는 POST /v3/webhooks입니다. 각 이벤트의 페이로드 스키마 (payload schema)에 대해서는 에이전트 계정 웹훅 알림 (Agent Account webhook notifications) 참조를 확인하십시오:

curl --request POST \
  --url "https://api.us.nylas.com/v3/webhooks" \
  --header "Authorization: Bearer <NYLAS_API_KEY>" \
...

이것들을 귀하의 자체 로직에 연결하십시오. message.delivered는 메시지가 수신자의 서버에 도달했음을 확인하며, message.bounced는 하드 바운스 (hard bounce)이고, message.complaint는 수신자가 이를 스팸으로 표시했음을 의미하며, message.rejected는 webhook notifications reference에 따라 첨부 파일에 바이러스가 포함되었을 때 발생합니다. 바운스 (bounce)나 컴플레인 (complaint)이 증가하면 아웃바운드 (outbound)를 일시 중지하거나 속도를 늦추고, 하드 바운스 (hard-bounce)가 발생하는 주소로는 메일 발송을 중단하십시오. 귀하의 텔레메트리 (telemetry)를 통해 문제를 포착하는 것이 발송을 중단시키는 임계값 (thresholds) 아래로 유지하는 방법입니다.

바운스 및 컴플레인 임계값 아래로 유지하기

Nylas는 각 에이전트 계정 (Agent Account)에 대해 이동 평균 바운스율 (rolling bounce rate)과 컴플레인율 (complaint rate)을 추적하며, 두 임계값 중 하나라도 넘으면 결과가 따릅니다. 바운스율은 하드 바운스 (hard bounces) — 즉, 존재하지 않는 주소이며 일시적인 소프트 바운스 (soft bounces)가 아님 — 를 최근 발송량으로 나눈 값입니다. 컴플레인율은 스팸 신고 횟수를 최근 발송량으로 나눈 것이며, 발신자에게 컴플레인을 다시 보고하는 수신자 도메인에 대해서만 계산됩니다. 분모는 최근 발송량 윈도우 (volume window)이므로, 하루에 백 개의 메시지를 보내든 백만 개를 보내든 비율은 유의미하게 유지됩니다.

각 비율에 따른 계정 상태는 다음과 같습니다:

바운스율 (Bounce rate)	상태 (State)	발생하는 일
2% 미만	정상 (Healthy)	일반적인 발송
...
컴플레인율 (Complaint rate)	상태 (State)	발생하는 일
---	---	---
0.1% 미만	정상 (Healthy)	일반적인 발송
...

컴플레인 임계값은 0.1%로 매우 낮기 때문에, 단 몇 명의 수신자가 귀하의 메일을 신고하는 것만으로도 발송량이 적은 계정이 검토 대상 (under review)이 될 수 있습니다. 검토 대상 상태는 귀하의 애플리케이션에는 별도로 알림이 가지 않으며, 일시 중지 (pause) 상태가 되면 발송 호출 시 즉각적인 피드백이 반환됩니다.

코드에서 일시 중지가 어떻게 보이는가

제재가 시작되면 귀하의 발송 요청은 실패하기 시작하며, 상태 코드 (status code)를 통해 어떤 문제가 발생했는지 알 수 있습니다. 귀하가 보게 될 세 가지 유형은 다음과 같으며, 각각 다른 처리가 필요합니다:

상태 (Status)	원인 (Cause)	조치 사항 (What to do)
`400 Bad Request`	평판(Reputation) 집행으로 인해 전송 중단됨	해당 계정에서의 전송을 중단하고, 바운스(bounce) 또는 불만(complaint)의 원인을 해결하십시오
...

설계 시 고려해야 할 한 가지 사항은, 평판 중단(reputation pause)은 타이머에 의해 자동으로 해제되지 않는다는 점입니다. 재개를 위해서는 Nylas 측에서 이를 해제해야 하므로, 바운스 또는 불만 원인과 적용한 해결책을 포함하여 고객 지원팀(support)에 문의해야 합니다. 이는 속도를 늦추는 즉시 해제되는 429 오류와는 정반대입니다. 남용 제한(abuse restriction)은 본문에 send blocked by abuse restriction이라는 메시지와 함께 403을 반환하며, 이 또한 대기하는 것이 아니라 고객 지원팀을 통해 해제됩니다.

전달 가능성(Deliverability)과 상호작용하는 전송 제한

평판 외에도 몇 가지 엄격한 제한(hard limits)이 에이전트의 전송 방식을 결정하며, 이를 초과하면 429가 반환됩니다. 각 에이전트 계정(Agent Account)에는 일일 전송 할당량(daily send quota)이 있습니다. 무료 플랜의 경우 하루 200개의 메시지로 제한되며, 유료 플랜은 기본적으로 일일 상한선이 없습니다. 조직(organization)은 초당 전송률(per-second rate)도 공유합니다. 모든 샌드박스(sandbox) 애플리케이션은 초당 1개의 요청으로 풀링(pool)되며, 모든 프로덕션(production) 애플리케이션은 초당 5개로 풀링됩니다. 단일 메시지는 to, cc, bcc를 통틀어 최대 50명의 수신자에게 전달되어야 하며, 전체 크기는 25MB 이하여야 합니다.

이러한 제한 사항들은 놓치기 쉬운 방식으로 웜업(warm-up) 과정과 상호작용합니다. 캘린더 초대(Calendar invitations)도 일일 전송 할당량에 포함됩니다. 계정이 할당량을 초과하면 이벤트는 여전히 저장되지만 초대는 조용히 건너뛰어집니다. 따라서 이메일 발송과 일정 예약을 모두 수행하는 에이전트는 사람들에게 알림을 보내는 것을 조용히 중단할 수 있습니다. 대규모 수신자 그룹은 50명 이하의 그룹으로 배치(batch)하고, 초당 전송률을 풀링된 상한선 미만으로 유지하여 웜업 도중에 급증(burst)으로 인해 429가 반환되지 않도록 하십시오.

유의 사항

에이전트가 실제로 전송을 시작한 후 전달 가능성 범위(deliverability envelope) 내에 머물게 하려면 몇 가지 습관을 지키는 것이 중요합니다. 각 습관은 평판이 하락하는 특정 경로를 차단합니다.

**전송 전 주소 유효성 검사(Validate addresses before sending)**를 수행하고, 이전에 하드 바운스(hard-bounce)된 주소는 건너뛰십시오. 하드 바운스는 계정이 중단되는 가장 빠른 길입니다.
**네 가지 도달 가능성 트리거(deliverability triggers)를 모두 연결(Wire up)**하고, bounced(반송), complaint(불만 신고), 또는 rejected(거부) 비율이 상승하면 자체적인 아웃바운드(outbound)를 일시 중단하십시오. Nylas가 알려주기 전에 여러분의 텔레메트리(telemetry)에서 이를 먼저 확인할 수 있을 것입니다.
From 도메인을 계정이 인증된 도메인과 일치하게 유지하여 DMARC 정렬(alignment)이 유지되도록 하십시오. 전달(Forwarding)은 SPF를 깨뜨리지만 DKIM은 이를 유지하며, 이것이 바로 DMARC가 둘 중 하나로부터 통과(pass)를 수락하는 정확한 이유입니다.
각 도메인을 개별적으로 워밍업(warm-up)하십시오. 평판(Reputation)은 전이되지 않으므로, 첫 번째 도메인의 기록이 아무리 좋아도 두 번째 도메인은 0에서 시작합니다.

마무리하며

에이전트의 도달 가능성(Deliverability)은 다른 발신자와 동일한 규율을 따르지만, 도메인을 엔드 투 엔드(end to end)로 직접 소유한다는 장점이 있습니다. 먼저 인증을 수행하고, 단계적으로 DMARC를 레이어링하며, 4주 동안 도메인을 워밍업하고, 네 가지 도달 가능성 웹후크(webhook)가 여러분의 자체적인 '일시 중단 및 속도 조절(pause-and-slow)' 로직에 데이터를 공급하게 하십시오. 임계값은 엄격합니다. 반송(bounce) 10% 또는 불만 신고(complaint) 0.5%는 계정을 일시 중단시키지만, 이 임계값에 영향을 주는 모든 신호는 Nylas가 개입해야 하기 전에 여러분이 실시간으로 모니터링하고 조치할 수 있는 것들입니다.

다음 단계:

에이전트 계정을 위한 이메일 도달 가능성 (Email deliverability for Agent Accounts) — DMARC 설정, 정렬 및 보고서 읽기
도메인 워밍업 가이드 (Domain warm-up guide) — 전체 램프업(ramp) 일정 및 일일 발송 스크립트
에이전트 계정 사용 제한 (Agent Account usage limits) — 할당량(quotas), 임계값 및 발송 중단 요인
에이전트 계정 웹후크 알림 (Agent Account webhook notifications) — 전달(delivery), 반송(bounce), 불만 신고(complaint) 및 거부(rejection) 이벤트에 대한 스키마(schemas)