SPF, DKIM, DMARC 이메일 인증 설정 순서

SPF, DKIM, DMARC 이메일 인증은 업무 메일의 중요한 기반입니다. 도메인이 신원을 입증할 신호를 제공하지 않으면 수신자의 신뢰가 낮아질 수 있습니다. 다만 전달 결과는 다른 요소에도 좌우됩니다.

문제는 순서를 잘못 잡거나 강한 정책을 너무 일찍 적용해 자체 메일을 막는 경우에도 생깁니다. 기본 비즈니스 이메일 결정을 먼저 마친 뒤 인증을 구성하세요.

실무에서는 발신자 조사, SPF, DKIM, DMARC 순으로 단계적으로 진행할 수 있습니다. 이는 유용한 안전 절차이지 모든 환경의 유일한 방법은 아닙니다.

TrekMail은 현재 요금제와 설정에 따라 DNS 상태 확인, 사용자 지정 도메인, IMAP, catch-all, 전달, 마이그레이션, BYO SMTP 또는 관리형 SMTP를 지원할 수 있습니다. 도메인 설정과 도메인 이메일 만들기를 참고하세요.

SPF, DKIM, DMARC의 실제 역할

SPF는 실제 MAIL FROM의 발신 IP를 승인하고, DKIM은 서명된 데이터를 검증하며, DMARC는 정렬과 수신자에게 요청하는 정책을 연결합니다.

프로토콜	역할	검사	주요 실패
SPF	승인	발신 IP가 envelope 도메인에 허용됐는지	조회 과다, 발신자 누락, 전달
DKIM	무결성	헤더와 본문이 유효한 서명과 일치하는지	selector 또는 키 오류, 고객 도메인 서명 없음
DMARC	정책과 정렬	SPF 또는 DKIM이 From과 정렬되는지	실제 경로 확인 전에 시행

SPF는 출입 명단, DKIM은 봉인, DMARC는 규칙에 비유할 수 있습니다. DNS에 한꺼번에 넣기보다 검증하며 적용하세요.

신중한 설정 순서

발신자를 조사하고 SPF를 게시한 뒤 지원되는 모든 곳에서 DKIM을 켜고, p=none으로 DMARC를 게시해 정렬을 수정한 다음 단계적으로 시행하세요.

도메인으로 보내는 시스템을 모두 조사합니다.
정상 발신자를 포함한 SPF 레코드 하나를 게시합니다.
각 지원 서비스에서 DKIM을 활성화합니다.
p=none으로 DMARC를 게시하고 보고서를 수집합니다.
정렬 실패를 수정하고 실제 메일로 시험합니다.
p=quarantine 후 p=reject로 단계적으로 이동합니다.

레코드 길이보다 오래되거나 드문 발신 경로를 파악하는 일이 더 어렵습니다.

단계 1: 발신자 조사와 SPF

SPF는 실제 envelope 도메인으로 연결되는 IP를 승인합니다. 첫 변경으로 쓰기 좋지만 모든 문제를 해결하지는 않습니다.

DNS 변경 전에 회사 메일, 청구, CRM, 지원, 마케팅, 웹 폼, 프린터 등 @yourdomain.com으로 보내는 항목을 기록하세요.

SPF TXT 레코드는 하나만 게시하세요. Google용과 마케팅용으로 나누면 오류 상태가 됩니다.

Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net include:amazonses.com ~all

~all과 -all은 검증된 정책과 전체 경로에 맞게 선택해야 하며 결과를 보장하지 않습니다.

RFC 7208에 따라 DNS를 사용하는 메커니즘과 modifier에는 10회 조회 제한이 있습니다. include:, a, mx와 중첩 조회가 포함되어 permerror가 발생할 수 있습니다.

Google, HubSpot, Zendesk, QuickBooks, Mailchimp와 잊힌 티켓 시스템까지 추가하면 완전해 보여도 수신자가 조회 한도에 도달할 수 있습니다.

도메인이 많다면 사용하지 않는다고 확인된 include만 제거하고 필요할 때 실제 활성화와 정렬을 시험한 하위 도메인으로 분리하세요. 다중 도메인 이메일 호스팅의 중앙 확인 기능도 비교할 수 있습니다.

단계 2: DKIM과 정렬

전달은 SPF를 깨뜨릴 수 있습니다. 유효하며 정렬된 DKIM 서명과 정규화된 서명 데이터가 유지되면 도움이 되지만 모든 전달 경로에서 보장되지는 않습니다.

메일박스, 트랜잭션, 마케팅, 지원 도구가 고객 도메인 DKIM을 지원한다면 실제로 활성화하세요. 지원하지 않는다면 제품 제약으로 평가하세요.

일반적인 DKIM 예:

Type: TXT
Host: trek._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqh...

일부 사업자는 TXT 대신 CNAME을 사용합니다. 실제 계정에 제공되고 활성화된 값을 따르세요.

서비스별 selector는 폐기 시 다른 경로를 건드리지 않고 제거하기 쉽습니다. 제거 전 미사용 여부를 검증하세요.

DMARC는 인증만 아니라 표시되는 From과의 정렬을 요구합니다. Google의 현재 지침은 해당 발신자에게 SPF 또는 DKIM 정렬을 요구하고 가능한 경우 둘 다를 권장합니다. 발신자 FAQ.

Mailchimp가 자체 도메인으로 서명하고 자체 return-path를 쓰면 개별 검사는 통과해도 DMARC가 실패할 수 있습니다. 사업자가 지원하는 사용자 지정 도메인 인증을 켜고 실제 selector와 반환 경로를 확인하세요.

전달을 많이 쓴다면 이메일 전달 설정과 문제 해결을 읽고 실제 경로를 시험하세요.

단계 3: p=none DMARC

DMARC는 보통 p=none으로 시작합니다. 이는 DMARC 제한을 요청하지 않으며 보고서를 받을 수 있지만 수신자는 자체 필터를 적용하고 모든 곳이 보고하지는 않습니다.

기본 레코드:

Type: TXT
Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=s

relaxed 정렬이 기본이며 strict가 항상 더 좋은 것은 아닙니다. 발신자 목록, 로그, 실제 시험, 드문 중요 경로와 롤백 없이 reject로 바로 이동하지 마세요.

보고서는 유용하지만 XML parser가 필요할 수 있습니다. 전달 뒤 SPF fail과 정렬된 DKIM pass로 DMARC가 통과할 수 있습니다. 둘 다 실패해도 스푸핑뿐 아니라 누락된 정상 소스일 수 있습니다. 스팸 문제 해결.

여기서 오래된 시스템, 스캐너, 뉴스레터와 스푸핑 가능성이 드러납니다. 보고서, 헤더, 로그와 경로 정보를 함께 확인하세요.

단계 4: 보고서 결과 수정

DMARC 보고서는 관찰된 인증과 정렬을 보여 주지만 소스를 가짜로 확정하지는 않습니다. 정상 오류와 악용 가능성을 구분해 대표적인 실제 시험에서 안정될 때까지 수정하세요.

일반적인 범주:

정상 발신자가 SPF에 없습니다.
사업자가 DKIM을 쓰지만 고객 도메인으로 서명하지 않습니다.
마케팅 도구의 기본 bounce 도메인 때문에 SPF 정렬이 실패합니다.
장치가 인증 SMTP relay 대신 직접 보냅니다.
알 수 없는 IP가 From 도메인을 사용합니다.

프린터와 스캐너는 지원되는 relay를 사용하게 하세요. TrekMail 유료 요금제에는 현재 관리형 SMTP가 포함될 수 있고 Nano는 BYO SMTP를 사용합니다. 최신 호스트와 포트는 IMAP 및 SMTP 설정을 확인하세요. 현재 TrekMail은 POP3가 아닌 IMAP을 안내합니다.

여러 대표 기간에 걸쳐 발신자 목록, 로그, 실제 시험과 드문 중요 경로가 확인되고 롤백이 준비된 뒤 진행하세요.

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com

quarantine은 단계적 중간점이 될 수 있습니다. 근거가 충분할 때 reject를 요청하되 최종 처리는 수신자가 결정합니다.

명령줄에서 레코드 확인

DNS 패널에서 업데이트가 늦게 보이거나 값을 다르게 표시할 수 있고 캐시가 TTL을 따르므로 직접 조회와 모든 실제 발신 시스템의 테스트 메시지가 중요합니다.

SPF 확인:

dig txt example.com +short

DKIM selector 확인:

dig txt trek._domainkey.example.com +short

DMARC 확인:

dig txt _dmarc.example.com +short

SPF 레코드 하나, 의도한 DKIM 공개 키와 DMARC 정책을 확인하세요. 변경이 아직 안 보이면 TTL과 캐싱을 고려하고 외부 resolver 결과도 신중히 비교하세요.

reverse DNS, TLS, 신고율과 평판도 중요합니다. 인증은 기반이지 부실한 목록이나 무리한 발송을 보완하는 마법은 아닙니다.

기존 방식과 새로운 방식

기존에는 큰 제품군에 메일박스별 비용을 내거나 도메인, SMTP와 인증을 직접 관리했습니다. 모듈형 플랫폼은 통제를 모을 수 있지만 비용이나 결과를 자동 개선하지는 않습니다.

현재 조건상 Starter는 월 $3.50부터, Nano는 $0에 BYO SMTP를 제공할 수 있으며 유료 요금제에는 관리형 SMTP가 포함될 수 있습니다. 사용자 지정 도메인, IMAP, catch-all, 전달, 서버 측 IMAP 마이그레이션과 상위 요금제 API는 현재 요금제와 설정에 따라 다릅니다.

여러 브랜드나 공유 메일박스에는 중앙 관리가 유용할 수 있지만 절감을 보장하지 않습니다. 내 도메인에 이메일 설정과 TrekMail 요금을 확인하세요.