인보이스 알림, 견적서, 또는 월간 뉴스레터를 보냈는데 고객이 이메일을 받지 못한 적이 있나요? 반송도 없고, 오류 메시지도 없이 그저 침묵뿐입니다. 스팸으로 분류된 것입니다.
이런 경험이 있다면 혼자가 아닙니다. Gmail, Yahoo, Outlook은 이제 SPF, DKIM, DMARC라는 세 가지 DNS 레코드를 설정하지 않은 도메인에서 보낸 메일을 거부하거나 스팸 폴더로 분류합니다. 2024년 2월부터 대량 발신자(Gmail 계정으로 하루 약 5,000건 이상 발송하는 경우)는 세 가지 모두 인증을 받고, 원클릭 구독 취소를 제공하며, 스팸 신고율을 0.3% 미만으로 유지해야 합니다. 2025년까지 규정이 강화되었고, 2026년에는 소규모 발신자도 영향을 받게 됩니다. 인증을 설정하지 않으면 견적서, 인보이스, 알림 메일이 스팸으로 분류될 가능성이 훨씬 높아집니다.
좋은 소식은 설정에 약 1시간이 걸리며, 비용은 들지 않고, 전달성을 영구적으로 개선한다는 것입니다. 각 레코드가 무엇을 하는지, 어떻게 설정하는지, 그리고 소기업 이메일이 스팸 폴더에 머무는 이유를 알아보겠습니다.
SPF, DKIM, DMARC가 실제로 하는 일
이 세 가지 레코드를 메시지를 수신하는 서버가 전달 전에 확인하는 신원 확인증으로 생각하면 됩니다. 각각은 다른 질문에 답합니다.
SPF: 어떤 서버가 당신의 도메인으로 메일을 보낼 수 있는가
SPF(Sender Policy Framework)는 도메인의 DNS에 있는 TXT 레코드로, 해당 도메인으로 메일을 보낼 수 있는 서버를 지정합니다. Gmail이 [email protected]에서 보낸 것으로 표시된 메시지를 받으면 SPF 레코드를 조회하여 발송 서버의 IP가 목록에 있는지 확인합니다.
Google Workspace와 인보이스 도구를 사용하는 비즈니스용 SPF 레코드 예시:
v=spf1 include:_spf.google.com include:servers.mcsv.net ~allv=spf1은 레코드를 SPF로 식별합니다.- 각
include:는 특정 서비스 제공업체의 서버를 승인합니다. ~all(소프트 실패)은 수신자가 의심스러운 메일을 처리하도록 하고,-all(하드 실패)은 완전히 거부하도록 지시합니다.
SPF만으로는 충분하지 않습니다. SPF는 봉투의 Return-Path만 검증하며, 전달된 메일은 깨질 수 있습니다. 그래서 DKIM이 필요합니다.
DKIM: 변조 방지 서명
DKIM(DomainKeys Identified Mail)은 각 메시지 헤더에 암호화 서명을 추가합니다. 발신자는 개인 키를 보유하고, 수신자가 확인할 수 있도록 DNS에 공개 키를 TXT 레코드로 게시합니다. 서명은 전달 과정에서도 유지되므로 메시지가 변조되지 않았는지 확인할 수 있습니다.
Google Workspace, Microsoft 365, Mailchimp 등 대부분의 발신 플랫폼에서 DKIM 서명을 활성화한 후, 해당 서비스가 제공하는 선택자 레코드(예: google._domainkey)를 DNS에 추가하면 됩니다.
DMARC: 최종 정책 계층
DMARC는 SPF와 DKIM을 연결하여 수신자의 From 주소 도메인과 SPF/DKIM 검증 결과가 일치하는지 확인합니다. _dmarc TXT 레코드에 정책을 게시합니다.
p=none으로 시작해 모니터링한 후 p=quarantine, p=reject로 강화하는 것이 안전합니다. 정렬 실패는 흔한 오류로, 뉴스레터가 자체 도메인이 아닌 발송 서비스 도메인을 사용할 때 발생합니다.
2026 Gmail 및 Yahoo 발신자 요구사항
벌크 발송 여부와 관계없이 모든 비즈니스 발신자는 다음을 준수해야 합니다:
- SPF 및 DKIM 인증
- From 도메인과 일치하는 정렬(alignment)
- 0.3% 미만의 스팸 신고율 (권장: 0.1% 미만)
- 마케팅 메일의 원클릭 수신 거부 제공
- 유효한 정방향 및 역방향 DNS
- Gmail 헤더 위조나 구매한 수신자 목록 사용 금지
1시간 안에 설정하는 방법
도메인 등록처 또는 네임서버 관리 콘솔에 접근할 수 있어야 합니다. 절차는 다음과 같습니다.
1단계: 이메일을 보내는 모든 서비스 파악
메일박스, 웹사이트 문의 양식, 인보이싱 도구, 뉴스레터 시스템 등 도메인에서 이메일을 보내는 모든 서비스를 나열하세요. 각각 SPF에 포함하거나 DKIM으로 서명해야 합니다. 하나라도 빠뜨리면 그 시스템의 메일이 스팸 처리될 수 있습니다.
2단계: 10회 조회 제한을 넘지 않도록 SPF 게시
SPF는 DNS 조회 10회 제한이 있습니다. 각 include:가 여러 조회를 발생시킬 수 있으므로, 서비스 제공업체를 쌓다 보면 조용히 한도를 초과할 수 있습니다. 이 경우 레코드가 실패로 처리됩니다.
- 제공업체에서 제공하는 단일 SPF TXT 레코드를 루트 도메인에 게시하세요.
- 블로그에서 복사한 임의의 스니펫을 병합하지 마세요.
- 계속 진행하기 전에 SPF 검사 도구로 검증하세요.
일반적인 제공업체 include 값:
| 제공업체 | include |
|---|---|
| Google Workspace | include:_spf.google.com |
| Microsoft 365 | include:spf.protection.outlook.com |
| 뉴스레터/마케팅 도구 | include:servers.mcsv.net |
3단계: 발송하는 모든 곳에서 DKIM 활성화
각 발신 제공업체(Workspace, Microsoft 365, Mailchimp 등)의 콘솔에서 DKIM 서명을 켜고, 제공된 선택자 레코드를 DNS에 게시하세요. 각 제공업체마다 고유한 선택자가 있습니다. 콘솔에서 활성 상태를 확인하고, 테스트 이메일의 Authentication-Results 헤더에서 dkim=pass를 확인하세요.
4단계: DMARC를 모니터링 모드로 게시
_dmarc TXT 레코드를 게시합니다:
v=DMARC1; p=none; rua=mailto:[email protected]DMARC 보고서를 읽는 무료 도구를 사용하여 어떤 발신자가 실패하는지 확인하세요. 인증되지 않은 발신자를 수정한 후에만 정책을 p=quarantine으로 강화하고, 마지막으로 p=reject로 설정합니다.
인증을 망치는 7가지 실수
- SPF, DKIM, DMARC가 전혀 없는 경우
- SPF 레코드가 두 개인 경우 (DNS에서 병합해야 함)
- 조회 제한을 초과한 SPF 레코드
- DKIM 서명은 켰지만 DNS에 공개 키를 게시하지 않은 경우
- From 도메인과 정렬되지 않은 SPF/DKIM (DMARC 실패 원인)
- DMARC 보고서를 아무도 읽지 않아 문제를 놓치는 경우
- Gmail/Yahoo 벌크 발신자 규칙(0.3% 스팸 임계값 및 원클릭 수신 거부)을 무시하는 경우
이 모든 것이 인보이스와 재무와 무슨 관련이 있나요?
인보이스가 스팸 폴더에 들어가면 고객이 지불하지 않고, 고객 서비스에 "인보이스를 다시 보내달라"는 전화가 걸려오며, 매출 채권(AR) 노화 보고서에 "지불 지연"으로 표시됩니다. 이메일 전달성은 단순한 IT 문제가 아니라 현금 흐름 문제입니다.
인증을 설정하면 인보이스가 받은 편지함에 도달하여 지불 주기가 빨라지고, 추적에 드는 시간이 줄어듭니다. 발신 평판은 시간이 지남에 따라 향상되어 모든 거래 이메일의 전달률이 개선됩니다.
마무리
정기적으로 게시된 SPF, DKIM, DMARC 레코드는 스팸 폴더를 피하는 가장 확실한 방법입니다. 설정하는 데 약 1시간이 걸리며, 비용은 들지 않고, 혜택은 영구적입니다. 개별 제공업체의 인증 지침을 항상 참조하고, 발신 평판을 모니터링하며, 도메인을 추가하거나 제공업체를 변경할 때마다 DNS 설정을 검토하세요.
재무 관리를 간소화하세요
인보이스가 안정적으로 받은 편지함에 도달하면 다음 단계도 깔끔하게 유지하세요. 발행, 결제, 미결제 금액에 대한 명확한 기록을 유지하는 것입니다. Beancount.io는 투명성과 통제력을 제공하는 일반 텍스트 회계 솔루션을 제공합니다 — 블랙박스도, 벤더 종속도 없습니다. 지금 무료로 시작하세요 모든 달러를 인보이스에서 원장까지 추적할 수 있습니다.
