TrekMail 이메일이 스팸으로 이동하는 이유

스팸 분류는 보통 수신자가 메일이 도메인에서 왔는지 확인할 수 없거나, 발신 도메인의 최근 기록이 나쁘거나, 메시지와 수신자 목록이 원치 않는 것으로 보이는 세 가지 요인에서 발생합니다. 어느 공급자도 받은 편지함 배치를 보장할 수 없지만 아래 검사는 제어 가능한 부분을 다룹니다.

도메인의 DNS 상태와 사용한 목록부터 확인하세요. 이 두 항목이 제목을 바꾸는 것보다 훨씬 많은 문제를 해결합니다.

먼저 패턴 확인하기

메시지를 기대하는 소수의 수신자로 테스트합니다. 어느 공급자가 스팸으로 분류하는지, 모든 메시지인지 특정 캠페인만인지 기록합니다.

• 한 공급자에만 국한되면 해당 공급자의 인증 결과와 배달 응답을 먼저 확인합니다.
• 여러 공급자가 같은 메일을 스팸으로 분류하면 DNS, 전송량 및 목록 품질을 검토합니다.
• 한 수신자만 보고하면 개인 규칙이 있거나 이전에 메일을 스팸으로 표시했는지 묻습니다.

공급자마다 신호가 다르므로 신뢰할 수 있는 공급자별 공식은 없습니다.

확인 1: 도메인 이메일 인증 완료

TrekMail에서 DNS 상태를 열고 DNS를 관리하는 공급자의 필수 레코드와 비교합니다. TrekMail을 통해 수신하는 도메인에는 보통 다음이 필요합니다.

• MX는 수신 메일을 TrekMail로 보냅니다.
• SPF는 TrekMail이 도메인을 대신해 보내도록 승인합니다.
• DKIM은 메시지가 도메인용으로 서명되었는지 확인하게 합니다.
• DMARC는 인증 실패 메일의 처리 방법을 알려 줍니다.

발신 전용 도메인은 TrekMail MX를 사용하지 않으므로 해당 구성의 표를 따릅니다. 정상 발신자를 확인 중이라면 DMARC를 모니터링 정책으로 시작하고 결과를 이해한 뒤 강화하세요. DNS 상태 확인을 참고하세요.

확인 2: 워밍업 한도 내에서 보내기

새 도메인은 첫 주에 다음 한도가 적용됩니다.

새 발신자의 갑작스러운 전송량 증가를 막지만 받은 편지함 배치를 보장하지는 않습니다.

메일을 기대하는 사람에게만 보내고 가장 적극적인 대상부터 시작해 점진적으로 늘리세요. 건강한 목록과 명확한 동의는 워밍업 후에도 중요합니다.

다른 공급자에서 도메인을 이전할 때도 같은 워밍업이 적용됩니다.

자세한 내용: 이메일 도메인 워밍업 규칙.

확인 3: 현재 안전 한도 확인

계정이 ever_paid=false(성공한 결제가 없음)이면 요금제와 관계없이 낮은 안전 한도가 적용됩니다.

• 평가판 중: 30/메일함/일, 50/계정/일, 10 수신자/메시지, 15 메시지/시간.
• 결제 없이 평가판 종료 후: 50/메일함/일, 150/계정/일, 25 수신자/메시지, 20 메시지/시간.

요금제 최대치보다 낮으며 전송량만 제어하고 평판을 측정하거나 개선하지 않습니다. 워밍업도 실제 한도를 낮출 수 있으므로 대시보드와 전송 오류를 확인하세요.

확인 4: 메시지를 기대하는 사람에게 보내기

낮은 목록 품질은 반송, 신고 및 낮은 참여를 일으켜 향후 배달을 해칩니다. 수신자가 다음에 해당하는지 검토하세요.

• 이 유형의 메시지를 요청했습니다.
• 현재도 주소를 사용합니다.
• 최근 메일과 상호 작용했습니다.

실용적인 단계:

• 평소 발송 빈도에 맞는 참여 기간을 선택하고 기간 밖 연락처에는 마케팅을 중단합니다.
• 오래되거나 가져온 목록은 전송 전 TrekMail 이메일 검증기로 확인합니다.
• 구매, 수집 또는 동의가 불명확한 목록을 사용하지 마세요.

확인 5: 반송률 낮게 유지

도메인 이메일 통계에서 배달과 반송을 봅니다. TrekMail은 2% 미만을 양호, 2% 이상 5% 미만을 경고, 5% 이상을 불량으로 봅니다. 측정할 메시지가 충분하면 24시간 동안 지속되는 10%가 보호 기능을 작동시킬 수 있습니다.

비율이 오르면 캠페인을 멈추고 유효하지 않은 수신자를 제거한 뒤 다음 묶음 전에 반송률이 너무 높은 경우를 읽으세요.

반송률과 스팸 신고율은 다릅니다. 반송은 수신 서버가 거부한 것이고 신고는 수신자가 수락된 메일을 스팸으로 표시한 것입니다. 개인 Gmail에는 Google이 0.1% 미만 유지와 0.3% 미도달을 요구합니다. Yahoo는 대량 발신자에게 0.3% 미만을 요구합니다. 0.1%를 운영 상한으로 보세요. 1,000개 중 한 번 신고로 이미 도달합니다.

확인 6: 메시지를 쉽게 알아보게 만들기

내용이 나쁜 목록이나 인증 실패를 보완하지는 못하지만 경계선의 메시지를 더 신뢰하게 만들 수 있습니다.

• 모두 대문자이거나 과도한 문장 부호 대신 명확한 제목을 사용합니다.
• 큰 이미지만이 아니라 읽을 수 있는 텍스트를 포함합니다.
• 수신자가 기대하는 브랜드와 발신 도메인을 사용합니다.
• 알아볼 수 있는 대상으로 연결하고 불필요한 단축 링크를 피합니다.
• 마케팅은 수신 이유와 눈에 보이는 구독 취소 링크를 포함합니다.

큰 캠페인 전 자신에게 정상 사본을 보내 발신자 이름, 링크, 형식 및 회신 주소를 확인합니다.

Gmail 또는 Yahoo로 대량 발송하는 경우

하루에 개인 Gmail 계정으로 5,000개가 넘는 메시지를 배달하는 발신자에게 Google은 추가 요구 사항을 적용합니다. SPF와 DKIM, 유효한 DMARC, 정렬된 인증, TLS 및 발신 인프라의 유효한 정방향과 역방향 DNS가 필요합니다. 마케팅과 구독 메일에는 원클릭 구독 취소 헤더와 눈에 보이는 링크도 필요합니다. Yahoo도 유사한 인증, 신고율 및 원클릭 취소 요구 사항을 게시합니다.

관리형 SMTP에서는 TrekMail이 발신 호스트, TLS, 정방향과 역방향 DNS를 운영합니다. 사용자는 표시된 도메인 레코드를 게시하고 동의, 목록 품질, 메시지 유형 및 취소를 관리합니다. 사용자 지정 SMTP에서는 해당 공급자에게 인증과 인프라를 확인합니다.

API 또는 MCP 전송은 전송 가능성과 반송에 따라 List-Unsubscribe 및 List-Unsubscribe-Post를 안전하게 추가합니다. 개인 대화에는 원클릭 취소를 추가하지 마세요. Google 규칙은 마케팅 및 구독 메일에 적용되며 거래 메시지에는 적용되지 않지만, 법률이나 목적이 일반 취소 방식을 요구할 수 있습니다.

이는 공급자 요구 사항이지 받은 편지함 보장이 아닙니다. 규칙은 바뀔 수 있으므로 대량 캠페인 전 최신 Google 발신자 지침과 Yahoo 모범 사례를 확인하세요.

확인 7: 더 광범위한 배달 장애 확인

많은 수신자에게 갑자기 문제가 시작되면 상태 페이지를 확인합니다. 신뢰할 수 있는 공개 평판 검사기로 자신의 도메인을 확인할 수도 있습니다.

공유 TrekMail 발신 IP를 외부 목록에서 직접 제거하려 하지 마세요. 영향을 받은 도메인, 수신 공급자, 테스트 시간 및 배달 응답을 지원 티켓에 넣어 맥락에 맞게 조사하도록 합니다.

목록 한 곳의 등재만으로 완전한 진단이 되지 않습니다. 인증, 동의 및 최근 반송 이력도 중요합니다.

확인 8: 통제된 테스트 전송

mail-tester.com에 정상 샘플 하나를 보내 명백한 문제를 찾을 수 있습니다.

1. mail-tester.com을 열고 표시된 고유 주소를 복사합니다.
2. TrekMail 메일함에서 실제 고객에게 보낼 정상 메시지를 전송합니다.
3. mail-tester.com에서 "Check your score"를 클릭합니다.

결과를 문제 해결 힌트로만 사용하고 보장으로 보지 마세요. 확인된 DNS 또는 메시지 문제를 먼저 고치고 다시 소규모 테스트합니다.

Google에 충분한 데이터가 있으면 Gmail Postmaster Tools로 도메인 수준 신호를 검토할 수 있습니다. 모든 발신자에게 데이터가 제공되는 것은 아니며 본문의 검사를 대체하지 않습니다.

확인 9: 전송 경로 확인

유료 요금제는 TrekMail 관리형 SMTP를 사용할 수 있습니다. 도메인에 저장된 외부 SMTP 프로필을 지정할 수도 있습니다. 도메인 SMTP 설정에서 선택된 경로를 확인하세요.

사용자 지정 SMTP에서는 외부 공급자가 자격 증명, 인증, IP 평판 및 전송 한도를 책임집니다. TrekMail DNS 레코드만으로 해당 공급자가 구성된다고 가정하지 마세요.

메일 구성에 맞는 경로를 사용하고 실제 전송 서비스에 맞춰 SPF, DKIM 및 DMARC를 확인합니다.

DMARC 결과 이해

TrekMail DMARC 보고서에서 모든 "실패"가 문제인 것은 아닙니다.

• SPF 실패, DKIM 통과: 전달 메일에서 발생할 수 있습니다. 남은 정렬 인증 방식이 통과하면 DMARC도 통과할 수 있습니다.
• SPF 통과, DKIM 실패: DKIM 레코드와 발신 서비스를 확인합니다.
• 둘 다 실패: 구성 또는 위조 경고로 보고 DMARC를 강화하기 전에 조사합니다.

DMARC 집계 보고서는 DMARC 레코드의 주소로 전송됩니다. 일정과 형식은 보고 메일 공급자가 관리합니다.

모든 것이 맞지만 여전히 스팸인 경우

마지막 확인 사항:

• 목록 출처: 동의나 출처가 불명확한 연락처를 제거합니다.
• 전송 패턴: 요금제 한도 안이라도 갑작스러운 증가를 피합니다.
• 수신자 규칙: 수신자에게 스팸 폴더와 메일 규칙을 확인하게 합니다.
• 받은 편지함 범주: 프로모션 등 기본이 아닌 범주는 스팸과 다르며 DNS 변경이 아니라 다른 기대가 필요합니다.