Email Spam Tester 테스트 실행 · 에이전트용 · API · 블로그

테스트 작동 방식

일회용 주소로 메시지 하나를 보내면 42개 검사가 실행됩니다. 이 페이지에서는 모든 검사를 설명합니다. 각 검사가 확인하는 항목, 실패 시 점수에서 차감되는 정도, 검사의 근거가 되는 표준 섹션을 다룹니다.

여기에는 당사의 의견을 규칙인 것처럼 제시한 내용이 없습니다. 검사가 표준에 명시된 내용을 적용하는 경우 해당 표준의 문장을 아래에 인용합니다. Google 또는 Yahoo의 요구사항을 적용하는 경우에는 해당 페이지를 링크합니다. 당사의 자체 판단인 경우에는 이를 명시합니다.

업데이트됨:

검사그룹자체 점수기존 점수
ARC 체인인증−20
DKIM 서명인증−18−1
DKIM 정렬인증−10−1
DMARC 결과인증−140
Sender ID인증−5−0.5
SPF인증−18−1
SPF 정렬인증−5−0.5
발신 호스트 이름 확인인프라 및 평판−5−3
차단 목록인프라 및 평판−25−3
HELO 이름인프라 및 평판−50
MX 레코드인프라 및 평판−5−3
역방향 DNS인프라 및 평판−12−1.5
전송 암호화인프라 및 평판−50
AI 판정스팸 엔진
종합 판정스팸 엔진−250
Postmark SpamCheck스팸 엔진
Rspamd스팸 엔진
SpamAssassin스팸 엔진0−3
이미지 대체 텍스트콘텐츠−4−0.5
링크 가용성콘텐츠−5−1
스크립트와 iframe콘텐츠−10−1
텍스트와 HTML의 균형콘텐츠−3−0.3
텍스트 및 HTML 파트콘텐츠−50
HTML 크기콘텐츠−3−0.3
이미지 용량콘텐츠−3−0.3
표시된 링크의 목적지콘텐츠−30
링크 평판콘텐츠−400
첨부 파일 검사콘텐츠−600
프리헤더콘텐츠−20
제목콘텐츠−30
단축 링크콘텐츠−5−0.5
DMARC 정책 게시대량 발신자 규칙−60
List-Unsubscribe대량 발신자 규칙−10−1
원클릭 구독 취소대량 발신자 규칙−80
대량 메일용 TLS대량 발신자 규칙−50
BIMI권장 사항00
DKIM 키 사용 기간 및 길이권장 사항00
DMARC 보고서 전달권장 사항00
DNSSEC권장 사항00
MTA-STS권장 사항00
반송 경로 길이권장 사항00
TLS 보고권장 사항00

인증

수신 서버가 메시지에 표시된 발신처에서 해당 메시지가 왔음을 입증할 수 있는지 확인합니다. 이는 전송 가능성에서 전적으로 DNS에 해당하는 절반이며, Gmail과 Yahoo가 2024년에 대량 발신자에게 의무화한 절반입니다.

ARC 체인 auth.arc

ARC는 포워더를 거치는 동안 인증 결과를 보존합니다. ARC가 없으면 푸터를 추가하는 메일링 리스트가 DKIM 서명을 깨뜨리고 전달된 사본은 최종 수신처에서 DMARC에 실패합니다.

실패하는 경우: 발신자가 할 일은 없습니다. 이는 리스트나 포워더를 운영하는 경우 중요하며, 누군가 메일을 전달한 후 일부 메일이 DMARC에 실패하는 이유를 설명합니다.

100점 만점인 자체 점수에서 최대 2점만큼 차감됩니다.

RFC 7960 §1 — Introduction

DMARC with restrictive policies causes problems for many Mailing Lists.

RFC 8617 §2.1 — Evidence

In ARC's situation, the "evidence" is a message's authentication assessment at any point along the delivery path between origination and final delivery.

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

DKIM 서명 auth.dkim

DKIM은 비공개 키로 메시지의 일부에 서명하고 공개 키를 DNS에 게시합니다. 메시지에 포함된 모든 서명을 검증하고 서명 도메인, 셀렉터 및 키 길이를 보고합니다.

실패하는 경우: 메일 발송 플랫폼에서 DKIM을 활성화하고 플랫폼에서 제공한 키를 게시하세요. 2048비트를 사용하세요. 1024비트도 여전히 검증되지만 이렇게 짧은 키는 해독될 수 있어 더 이상 안전하지 않습니다.

100점 만점인 자체 점수에서 최대 18점 및 기존 점수에서 10점 만점 중 최대 1점만큼 차감됩니다.

RFC 6376 §3.5 — The DKIM-Signature Header Field

The signature of the email is stored in the DKIM-Signature header field.

RFC 6376 §6.1 — Extract Signatures from the Message

Verifiers MUST NOT attribute ultimate meaning to the order of multiple DKIM-Signature header fields.

RFC 8301 §3.1 — Signing and Verification Algorithms

rsa-sha1 MUST NOT be used for signing or verifying.

RFC 8463 §6 — Transition Considerations

For backward compatibility, signers can add multiple signatures that use old and new signing algorithms.

Google — Set up DKIM

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

DKIM 정렬 auth.dkim_alignment

유효한 서명만으로는 DMARC에 충분하지 않습니다. 서명 도메인은 게시한 정책에 따라 From 헤더의 도메인과 정확히 일치하거나 조직 도메인 기준으로 일치해야 합니다.

실패하는 경우: 플랫폼의 도메인이 아니라 자체 도메인으로 서명하세요. 대부분의 플랫폼에서 이를 지원하며 사용자 지정 발송 도메인 또는 인증된 발송 도메인이라고 합니다.

100점 만점인 자체 점수에서 최대 10점 및 기존 점수에서 10점 만점 중 최대 1점만큼 차감됩니다.

RFC 9989 §4.4.1 — DKIM-Authenticated Identifiers

A single email can contain multiple DKIM signatures, and it is considered to produce a DMARC "pass" result if any DKIM-Authenticated Identifier aligns with the Author Domain.

Google — Set up DMARC

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

DMARC 결과 auth.dmarc

DMARC는 SPF와 DKIM을 독자에게 표시되는 도메인에 연결하고 둘 다 정렬되지 않을 때 수신자가 수행할 작업을 지정합니다. 게시된 정책과 이 메시지가 해당 정책을 충족했는지를 보고합니다.

실패하는 경우: DMARC 레코드를 게시하세요. p=none으로 시작해 몇 주 동안 보고서를 확인한 다음, 그 밖에 무엇이 도메인을 사용해 발송하는지 파악되면 quarantine으로 전환하세요.

100점 만점인 자체 점수에서 최대 14점만큼 차감됩니다.

RFC 9989 §5.3.5 — Determine DMARC "Pass" or "Fail"

If no Authenticated Identifiers exist for the domain, or none of the Authenticated Identifiers align with the Author Domain, the message is considered to fail the DMARC mechanism check.

RFC 9989 §4.7 — DMARC Policy Record Format

DMARC Policy Records follow the extensible "tag-value" syntax for DNS-based key records defined in DKIM [RFC6376].

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Yahoo — Sender requirements and recommendations

Sender ID auth.sender_id

SPF와 같은 검사이지만 봉투가 아니라 From 헤더의 도메인을 대상으로 실행합니다. 이 검사는 독자에게 표시되는 도메인이 메시지를 보낸 서버를 승인하는지라는 다른 질문에 답합니다. 메시지의 봉투는 SPF를 통과할 수 있지만 표시되는 도메인은 어떤 서버도 보증하지 않을 수 있습니다.

실패하는 경우: 플랫폼에서 제공한 반송 도메인뿐 아니라 From 헤더의 도메인에도 SPF를 게시하세요.

100점 만점인 자체 점수에서 최대 5점 및 기존 점수에서 10점 만점 중 최대 0.5점만큼 차감됩니다.

RFC 4406 §4 — Record Selection

After the above steps, there should be one record remaining and evaluation can proceed.

SPF auth.spf

SPF는 도메인을 대신해 메일을 보낼 수 있는 서버를 나열하는 DNS 레코드입니다. 수신 서버는 봉투의 주소를 가져와 해당 도메인의 레코드를 조회하고 접속한 IP가 레코드에 포함되어 있는지 확인합니다. 레코드 평가에 필요한 DNS 조회 횟수와 결과를 보고합니다. 평가는 조회 10회에서 중단되며 이를 초과하면 통과가 아니라 영구 오류가 되기 때문입니다.

실패하는 경우: 메일 발송 플랫폼만 지정하고 다른 항목은 포함하지 않는 레코드를 게시하세요. 현재 레코드가 조회 10회 제한에 가깝다면 사용하지 않는 include를 평탄화하세요 (오늘 통과하는 레코드도 제공업체가 자체 include를 추가하는 날부터 실패하기 시작합니다).

100점 만점인 자체 점수에서 최대 18점 및 기존 점수에서 10점 만점 중 최대 1점만큼 차감됩니다.

RFC 7208 §4.6.4 — DNS Lookup Limits

SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS. If this limit is exceeded, the implementation MUST return "permerror".

RFC 7208 §2.6 — Results of Evaluation

Section 4 defines check_host(), a model function definition that uses the inputs defined above and the sender's policy published in the DNS to reach a conclusion about client authorization.

Google — Set up SPF

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

SPF 정렬 auth.spf_alignment

반송 주소가 독자에게 표시되는 From 주소와 일치하는지를 나타냅니다. SPF는 봉투를 승인하며 DMARC는 두 주소가 정렬된 경우에만 해당 승인을 인정합니다.

실패하는 경우: 메일 발송 플랫폼에 자체 도메인의 반송 하위 도메인을 요청하세요. DKIM이 이미 정렬되어 있다면 긴급하지 않지만 전송 중 DKIM이 손상될 때 사용할 대체 수단이 없어집니다.

100점 만점인 자체 점수에서 최대 5점 및 기존 점수에서 10점 만점 중 최대 0.5점만큼 차감됩니다.

RFC 9989 §4.4.2 — SPF-Authenticated Identifiers

Only an SPF-Authenticated Identifier that has Identifier Alignment with the Author Domain is enough to validate the authorized use of the Author Domain.

RFC 9989 §5.3.5 — Determine DMARC "Pass" or "Fail"

If one or more of the Authenticated Identifiers align with the Author Domain, the message is considered to pass the DMARC mechanism check.

Google — Set up DMARC

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

인프라 및 평판

메시지가 전송된 시스템과 주소, 그리고 인터넷의 다른 시스템이 이미 이들을 어떻게 평가하는지 확인합니다.

발신 호스트 이름 확인 infra.a_record

HELO에서 알린 호스트 이름에 주소 레코드가 있는지를 검사합니다.

실패하는 경우: 서버가 알리는 이름의 A 레코드를 게시하십시오.

100점 만점인 자체 점수에서 최대 5점 및 기존 점수에서 10점 만점 중 최대 3점만큼 차감됩니다.

RFC 5321 §5.1 — Locating the Target Host

If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host.

Google — Set up MX records

차단 목록 infra.dnsbl

발신 IP가 수신자가 실제로 조회하는 차단 목록 중 하나에 등재되어 있는지 여부입니다. 목록은 웹 검색으로 구성하지 않고 각 존에서 자체적으로 문서화한 테스트 지점을 기준으로 확인합니다. 작동하지 않는 존은 NXDOMAIN으로 응답하며, 이는 "정상"으로 해석되기 때문입니다.

실패하는 경우: 등재 운영자 사이트의 등재 해제 절차를 따르세요. 주요 존에 등재되면 메일이 즉시 차단되므로 페이지의 다른 항목보다 먼저 처리하세요.

100점 만점인 자체 점수에서 최대 25점 및 기존 점수에서 10점 만점 중 최대 3점만큼 차감됩니다.

RFC 5782 §2.1 — IP Address DNSxL

Each IPv4 address listed in the DNSxL has a corresponding DNS entry.

RFC 5782 §5 — Test and Contact Addresses

IPv4-based DNSxLs MUST contain an entry for 127.0.0.2 for testing purposes.

Google — Postmaster Tools: reputation and delivery errors

Google — Email sender guidelines

HELO 이름 infra.helo

SMTP 대화 시작 시 발신 서버가 자신을 나타내기 위해 알리는 이름입니다. 확인 가능한 정규화된 도메인이어야 합니다.

실패하는 경우: 메일 서버의 호스트 이름을 컨테이너 ID나 내부 이름이 아닌 귀하의 도메인에 속한 실제 이름으로 설정하십시오.

100점 만점인 자체 점수에서 최대 5점만큼 차감됩니다.

RFC 5321 §4.1.1.1 — Extended HELLO (EHLO) or HELLO (HELO)

The argument clause contains the fully-qualified domain name of the SMTP client, if one is available.

Google — Email sender guidelines

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

MX 레코드 infra.mx

From 헤더의 도메인이 메일을 수신할 수 있는지를 검사합니다. MX 레코드가 없으면 회신과 반송 메일이 갈 곳이 없으며, 필터는 메일을 수신할 수 없는 발신 도메인을 좋지 않은 신호로 간주합니다.

실패하는 경우: 한 달에 한 번만 확인하는 사서함으로 라우팅되더라도 메일 발신에 사용하는 도메인의 MX 레코드를 게시하십시오.

100점 만점인 자체 점수에서 최대 5점 및 기존 점수에서 10점 만점 중 최대 3점만큼 차감됩니다.

RFC 5321 §5.1 — Locating the Target Host

The lookup first attempts to locate an MX record associated with the name.

Google — Set up MX records

역방향 DNS infra.rdns

발신 IP가 호스트 이름으로 역방향 확인되는지, 그리고 해당 호스트 이름이 동일한 IP로 정방향 확인되는지를 검사합니다. 핵심은 양방향 확인입니다. 어디든 가리키는 PTR을 설정하는 것은 쉽지만, 일치하는 쌍은 해당 주소가 귀하의 것이라는 증거입니다.

실패하는 경우: IP 소유자에게 PTR을 귀하가 제어하는 이름으로 설정해 달라고 요청하고, 해당 이름에 원래 IP를 가리키는 A 레코드가 있는지 확인하십시오.

100점 만점인 자체 점수에서 최대 12점 및 기존 점수에서 10점 만점 중 최대 1.5점만큼 차감됩니다.

RFC 1912 §2.1 — Inconsistent, Missing, or Bad Data

Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain.

Google — Email sender guidelines

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

전송 암호화 infra.tls

메시지가 TLS를 통해 도착했는지와 어떤 암호 스위트를 사용했는지를 검사합니다. 모든 최신 시스템은 TLS를 협상합니다. 암호화되지 않은 상태로 도착한 메시지는 발신 설정에 문제가 있음을 나타냅니다.

실패하는 경우: 발신 서버에서 STARTTLS를 활성화하십시오. 모든 주요 플랫폼은 이미 이를 지원하므로 여기서 실패한다면 일반적으로 경로에 자체 호스팅 릴레이가 있다는 뜻입니다.

100점 만점인 자체 점수에서 최대 5점만큼 차감됩니다.

RFC 3207 §2 — STARTTLS Extension

The STARTTLS extension to SMTP is laid out as follows:

Google — Send email over a secure TLS connection

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

스팸 엔진

독립적인 콘텐츠 필터가 메시지를 어떻게 판단하는지 확인합니다. 하나가 아닌 두 개의 엔진을 사용합니다. 단일 엔진의 점수는 해당 엔진의 판단이기 때문입니다.

AI 판정 spam.ai_judge

모델이 기술적 결과와 콘텐츠 측정값을 바탕으로 최신 머신러닝 필터가 메시지를 어떻게 처리할지 추정합니다. 모델은 본문 텍스트가 아니라 확인된 사실을 봅니다.

실패하는 경우: 이 항목 자체는 참고용일 뿐입니다. 추정 결과는 아래의 종합 판정에 반영됩니다.

세부 정보로 표시됩니다. 점수에는 반영되지 않습니다.

종합 판정 spam.panel

응답한 엔진들의 결과를 하나의 수치로 나타내며, 가장 강한 의견이 단순 평균으로 희석되지 않도록 가중치를 적용합니다. SpamAssassin과 Postmark는 동일한 규칙 기반을 공유하므로 하나의 표로 계산됩니다.

실패하는 경우: 개별 결과를 차례로 해결하세요. 이 행은 해당 결과가 변경될 때 함께 변경됩니다.

100점 만점인 자체 점수에서 최대 25점만큼 차감됩니다.

Google — Why Gmail marks messages as spam

How this score is calculated

Postmark SpamCheck spam.postmark

기본적으로 비활성화된 세 번째 평가입니다. 이 엔드포인트는 전체 메시지를 전달받으며, 측정 대상을 훼손하지 않고는 어떤 부분도 가릴 수 없습니다. 따라서 이 기능을 활성화하면 테스트한 모든 메시지가 제3자에게 복사된다는 데 동의하는 것입니다.

실패하는 경우: 수행할 작업이 없습니다. 비활성화된 경우 검사는 비활성화 상태라고 보고하며, 이는 통과와 같지 않습니다.

세부 정보로 표시됩니다. 점수에는 반영되지 않습니다.

Rspamd spam.rspamd

독립적으로 개발된 두 번째 필터입니다. SpamAssassin과 의견이 다를 때가 충분히 많아 확인할 가치가 있으며, 이것이 이 필터가 여기에 있는 이유입니다.

실패하는 경우: 참고용일 뿐입니다. 이 엔진의 평가는 별도로 점수를 매기지 않고 종합 판정에 반영됩니다.

세부 정보로 표시됩니다. 점수에는 반영되지 않습니다.

SpamAssassin spam.spamassassin

전통적인 규칙 기반 필터이며, 여전히 대부분의 이메일 테스트 도구에서 사용하는 엔진입니다. 일치한 모든 규칙이 가중치와 함께 표시됩니다.

실패하는 경우: 총점보다 일치한 규칙을 확인하세요. 어떤 규칙인지 확인하면 대부분 쉽게 해결할 수 있습니다.

기존 점수에서 10점 만점 중 최대 3점만큼 차감됩니다.

Google — Why Gmail marks messages as spam

Apache SpamAssassin — rule documentation

콘텐츠

메시지 자체를 확인합니다. 필터가 판단하기 전에 읽는 메시지 구조, 링크, 이미지 및 기타 요소를 검사합니다.

이미지 대체 텍스트 content.alt_attributes

이미지에 alt 속성이 있는지 여부입니다. 메일 클라이언트는 기본적으로 원격 이미지를 차단하므로, 처음 몇 초 동안은 대체 텍스트가 메시지 역할을 합니다.

실패하는 경우: 의미를 전달하는 대체 텍스트를 작성하고, 주요 시각 요소에는 반드시 대체 텍스트를 지정하세요.

100점 만점인 자체 점수에서 최대 4점 및 기존 점수에서 10점 만점 중 최대 0.5점만큼 차감됩니다.

Google — Email sender guidelines

스크립트와 iframe content.forbidden_tags

HTML에 어떤 메일 클라이언트도 실행하지 않는 태그가 포함되어 있는지 여부입니다. 기껏해야 제거되며, 최악의 경우 필터 회피 신호로 취급됩니다.

실패하는 경우: script, iframe, object, embed를 제거하세요. 모든 대화형 요소는 링크 뒤에 있어야 합니다.

100점 만점인 자체 점수에서 최대 10점 및 기존 점수에서 10점 만점 중 최대 1점만큼 차감됩니다.

Google — Email sender guidelines

텍스트와 HTML의 균형 content.html_text_ratio

메시지에서 읽을 수 있는 텍스트에 비해 마크업이 얼마나 많은지를 나타냅니다. 한 문장을 마크업으로 둘러싼 페이지는 필터가 인식하는 형태입니다.

실패하는 경우: 자리표시자가 아니라 HTML과 동일한 내용을 전달하는 텍스트 파트를 작성하세요.

100점 만점인 자체 점수에서 최대 3점 및 기존 점수에서 10점 만점 중 최대 0.3점만큼 차감됩니다.

RFC 2046 §5.1.4 — Alternative Subtype

Systems should recognize that the content of the various parts are interchangeable.

Google — Why Gmail marks messages as spam

텍스트 및 HTML 파트 content.html_version

메시지가 HTML과 함께 일반 텍스트 대체 버전을 포함하는지 여부입니다. 일부 필터는 일반 텍스트 대체 버전이 없는 것을 판단 요소로 삼으며, 모든 스크린 리더에는 이 버전이 필요합니다.

실패하는 경우: 빈 파트나 브라우저에서 보라는 한 줄짜리 문구가 아니라, 실제 텍스트 버전이 포함된 multipart/alternative 형식으로 전송하세요.

100점 만점인 자체 점수에서 최대 5점만큼 차감됩니다.

RFC 2046 §5.1.4 — Alternative Subtype

The "multipart/alternative" type is syntactically identical to "multipart/mixed", but the semantics are different. In particular, each of the body parts is an "alternative" version of the same information.

Google — Email sender guidelines

HTML 크기 content.html_weight

HTML 파트의 크기를 나타냅니다. Gmail은 약 102 KB를 초과하는 메시지를 잘라내고 나머지를 링크 뒤에 숨기며, 이때 수신 거부 푸터도 함께 숨겨집니다.

실패하는 경우: 인라인 CSS와 반복되는 스타일 블록을 줄이세요(사용하지 않는 규칙을 제거하면 대부분의 템플릿은 제한의 3분의 1 이내에 들어갑니다).

100점 만점인 자체 점수에서 최대 3점 및 기존 점수에서 10점 만점 중 최대 0.3점만큼 차감됩니다.

Google — Email sender guidelines

이미지 용량 content.images_weight

메시지가 불러오는 이미지의 전체 크기입니다. 용량이 큰 이미지는 휴대전화에서 메시지를 느리게 만들며, 이미지만 있는 메일은 필터가 의심스럽게 보는 형태입니다.

실패하는 경우: 이미지를 압축하고 이미지가 꺼져 있어도 메시지를 읽을 수 있는지 확인하세요.

100점 만점인 자체 점수에서 최대 3점 및 기존 점수에서 10점 만점 중 최대 0.3점만큼 차감됩니다.

Google — Email sender guidelines

첨부 파일 검사 content.malware

첨부 파일에 알려진 악성 코드가 포함되어 있는지 여부입니다. 스캐너가 꺼진 배포 환경에서는 문제가 없다고 보고하는 대신 검사가 실행되지 않았다고 보고합니다.

실패하는 경우: 이 항목이 감지되면 전송을 중단하고 메시지를 생성한 시스템에 무엇이 있는지 확인하세요.

100점 만점인 자체 점수에서 최대 60점만큼 차감됩니다.

Google — Why Gmail marks messages as spam

ClamAV — how detection works

프리헤더 content.preheader

클라이언트가 제목 옆에 표시하는 미리보기 문구입니다. 프리헤더가 없으면 본문에서 가장 먼저 나오는 내용이 표시되며, 이는 보통 브라우저에서 보기 링크입니다.

실패하는 경우: 본문의 첫 번째 요소로 숨겨진 프리헤더 블록을 추가하세요.

100점 만점인 자체 점수에서 최대 2점만큼 차감됩니다.

Google — Email sender guidelines

제목 content.subject

필터가 점수를 매기는 길이, 대문자 사용 및 패턴입니다. 디코딩된 제목을 측정하므로 키릴 문자나 CJK로 된 제목은 인코딩이 아니라 텍스트로 평가됩니다.

실패하는 경우: 약 60자 이내로 유지하고, 고함치는 듯한 표현과 느낌표를 없애세요.

100점 만점인 자체 점수에서 최대 3점만큼 차감됩니다.

RFC 5322 §2.2 — Header Fields

Header fields are lines beginning with a field name, followed by a colon (":"), followed by a field body, and terminated by CRLF.

RFC 2047 §2 — Syntax of encoded-words

An 'encoded-word' is defined by the following ABNF grammar.

Google — Why Gmail marks messages as spam

단축 링크 content.url_shortener

링크가 공개 단축 서비스를 거치는지 여부입니다. 단축 서비스는 목적지를 숨기며, 이는 정확히 필터가 신뢰하지 않도록 학습된 방식입니다.

실패하는 경우: 자체 도메인으로 연결하거나, 자체 도메인의 하위 도메인에 설정한 플랫폼의 추적 도메인을 사용하세요.

100점 만점인 자체 점수에서 최대 5점 및 기존 점수에서 10점 만점 중 최대 0.5점만큼 차감됩니다.

Google — Why Gmail marks messages as spam

대량 발신자 규칙

Gmail과 Yahoo가 대량으로 발송하는 발신자에게 요구하는 사항입니다. 이 요구사항은 대량 발송 메일에 적용되며, 대량 발송 메일로 보이지 않는 메시지에는 검사를 건너뜁니다.

DMARC 정책 게시 compliance.dmarc_present

이 메시지의 통과 여부와 별개로, From 도메인이 DMARC 레코드를 게시하는지 여부입니다. Gmail과 Yahoo는 대량 발신자에게 이를 요구합니다.

실패하는 경우: 레코드를 게시하세요. p=none이면 요구 사항을 충족하기에 충분하며, 활용할 수 있는 보고서도 제공됩니다.

100점 만점인 자체 점수에서 최대 6점만큼 차감됩니다.

RFC 9989 §4.7 — DMARC Policy Record Format

If this tag is not present in an otherwise syntactically valid DMARC Policy Record, then the record is treated as if it included "p=none".

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Yahoo — Sender requirements and recommendations

List-Unsubscribe compliance.list_unsubscribe

메일 클라이언트가 처리할 수 있는 구독 취소 헤더가 메시지에 있는지 여부입니다. Gmail과 Yahoo는 대량 발신자에게 이 헤더를 요구하며, 다른 모든 조건과 관계없이 이 헤더가 없으면 필터링됩니다. 이 규칙은 메일링에 적용됩니다. 수신자에게 구독 확인을 요청하거나 구독이 완료되었다고 알리는 메일은 수신자가 방금 수행한 작업에 관해 한 사람에게 전송됩니다. CAN-SPAM은 이를 거래 또는 관계 메시지라고 하며, Gmail과 Yahoo 모두 이러한 메시지에 구독 취소 헤더를 요구하지 않습니다. 따라서 이 검사는 먼저 메일을 읽습니다. 목록 헤더가 없는 구독 확인 메일, 환영 메일, 거래 메일 또는 알림은 감점하지 않으며, 보고서에는 해당 메일을 무엇으로 판단했는지가 표시됩니다. 여러 제안으로 채운 환영 메일은 사실상 메일링의 첫 번째 호입니다. 목록 헤더가 없으면 검사에서 둘을 구분할 수 없으며, 추측으로 감점하지 않습니다. 메일에 List-Unsubscribe 또는 List-Id가 있으면 발신자가 직접 목록 메일이라고 선언한 것이므로, 검사는 이전과 동일하게 실행됩니다.

실패하는 경우: HTTPS URI가 포함된 List-Unsubscribe 헤더를 추가하세요. 모든 발송 플랫폼에서 이를 지원합니다.

100점 만점인 자체 점수에서 최대 10점 및 기존 점수에서 10점 만점 중 최대 1점만큼 차감됩니다.

RFC 2369 §3.2 — List-Unsubscribe

The List-Unsubscribe field describes the command (preferably using mail) to directly unsubscribe the user (removing them from the list).

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Yahoo — Sender requirements and recommendations

원클릭 구독 취소 compliance.one_click_unsubscribe

더 엄격한 형식입니다. HTTPS URI, "List-Unsubscribe-Post" 헤더, 그리고 두 헤더를 모두 포함하는 하나의 유효한 DKIM 서명이 필요합니다. 세 가지가 모두 있어야 하며, 그렇지 않으면 수신 측에서 버튼을 표시하지 않습니다. List-Unsubscribe 검사와 마찬가지로 확인 메일이나 환영 메일이 아니라 메일링에 적용됩니다.

실패하는 경우: 일반적으로 누락되는 것은 서명입니다. 플랫폼에서 "List-Unsubscribe"에는 서명하지만 "List-Unsubscribe-Post"는 빠뜨립니다. 두 헤더 이름이 동일한 서명의 h= 태그에 모두 있어야 합니다.

100점 만점인 자체 점수에서 최대 8점만큼 차감됩니다.

RFC 8058 §4 — Additional Requirements

The List-Unsubscribe and List-Unsubscribe-Post headers MUST be covered by the signature and included in the "h=" tag of a valid DKIM-Signature header field.

RFC 8058 §3.1 — Mail Senders

The List-Unsubscribe header field MUST contain one HTTPS URI.

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Yahoo — Sender requirements and recommendations

권장 사항

적용할 가치가 있지만 점수에는 반영되지 않습니다. 이 섹션의 어떤 항목도 점수를 차감하지 않으며, 이는 테스트에 적용된 제품 결정입니다.

BIMI advisory.bimi

도메인이 BIMI 레코드를 게시하는지 여부입니다. 이 레코드는 일부 클라이언트에서 메시지 옆에 로고를 표시합니다. 먼저 강제 적용 DMARC 정책이 필요하며, 비용이 드는 검증된 상표 인증서도 필요합니다.

실패하는 경우: DMARC가 격리 또는 거부로 설정되고 발송량이 인증서 비용을 정당화할 때 적용할 가치가 있습니다.

권장 사항입니다. 점수는 차감되지 않습니다.

BIMI — draft specification, not yet an RFC

DKIM 키 사용 기간 및 길이 advisory.dkim_key_rotation

서명 키의 길이와 사용된 기간입니다. 짧은 키는 시간이 지날수록 매년 오프라인 공격 비용이 낮아집니다.

실패하는 경우: 2048비트로 전환하고 일정에 따라 교체하세요. 새 선택자를 게시하고 서명을 새 선택자로 전환한 다음 이전 선택자를 폐기하세요.

권장 사항입니다. 점수는 차감되지 않습니다.

RFC 8301 §3.2 — Key Sizes

Since short RSA keys more easily succumb to off-line attacks, Signers MUST use RSA keys of at least 1024 bits for all keys. Signers SHOULD use RSA keys of at least 2048 bits.

Google — Set up DKIM

DMARC 보고서 전달 advisory.dmarc_reporting

DMARC 레코드의 주소가 실제로 보고서를 수신하는지 여부입니다. 보고서 주소가 자체 도메인 외부에 있으면 RFC 9990에 따라 해당 도메인이 먼저 your-domain._report._dmarc.their-domain 위치에 TXT 레코드로 자체 권한을 게시해야 합니다. 이 레코드가 없으면 수신자는 해당 주소를 제외합니다. 반송도, 오류도, 보고서도 없습니다. 주소는 일반적으로 모니터링 공급업체에 있거나 정책은 발신 하위 도메인에 있는 반면 주소는 주 도메인에 있으므로, 이는 특이한 설정이 아니라 일반적인 설정입니다. 동일한 규칙이 실패 보고서에도 적용되며, RFC 9991은 ruf 태그에 대해 동일한 절차를 가리킵니다. 수신자가 조회하는 것과 동일한 레코드를 조회하고, 요청한 이름을 표시합니다.

실패하는 경우: 대상 도메인을 운영하는 담당자에게 검사 결과에 표시된 이름으로 v=DMARC1을 포함하는 TXT 레코드를 게시하도록 요청하세요. 모니터링 공급업체는 일반적으로 계정에 도메인을 추가하면 이를 대신 처리하므로, 레코드가 없다면 해당 공급업체 측에 도메인이 추가되지 않았을 가능성이 높습니다. 보고서가 자체 도메인으로 전송되는 경우에는 아무 작업도 필요하지 않습니다.

권장 사항입니다. 점수는 차감되지 않습니다.

RFC 9990 §4 — Verifying External Destinations

When a Mail Receiver discovers a DMARC Policy Record in the DNS, and the Organizational Domain at which that record was discovered is not identical to the Organizational Domain of the host part of the authority component of a [RFC3986] specified in the "rua" tag, the following verification steps MUST be taken:

RFC 9990 §4 — Verifying External Destinations

Where the above algorithm fails to confirm that the external reporting was authorized by the Report Consumer, the URI MUST be ignored by the Mail Receiver generating the report.

RFC 9991 §5 — Verifying External Destinations

In case of external destinations, a Mail Receiver who generates failure reports MUST use the Verifying External Destinations procedure described in Section 4 of [RFC9990], substituting the "ruf" tag where the "rua" tag appears in that procedure.

Google — Set up DMARC

DNSSEC advisory.dnssec

도메인이 서명되었는지 여부입니다. SPF, DKIM 및 DMARC는 모두 DNS에 있으므로 DNS 응답을 위조할 수 있는 공격자는 세 가지 모두를 위조할 수 있습니다.

실패하는 경우: 등록기관에서 활성화하세요. 일반적으로 스위치 하나만 켜면 되며 나머지는 등록기관에서 처리합니다.

권장 사항입니다. 점수는 차감되지 않습니다.

RFC 4033 §2 — Definitions of Important DNSSEC Terms

Authentication Chain: An alternating sequence of DNS public key (DNSKEY) RRsets and Delegation Signer (DS) RRsets

MTA-STS advisory.mta_sts

다른 서버가 암호화되지 않은 방식으로 도메인에 메일을 전달하지 못하도록 지시하는 정책을 도메인이 게시하는지 여부입니다. 발송하는 메일이 아니라 수신하는 메일을 보호합니다.

실패하는 경우: TXT 레코드와 정책 파일을 HTTPS로 게시하세요 (반나절이면 가능하며, 다운그레이드 공격을 차단합니다).

권장 사항입니다. 점수는 차감되지 않습니다.

RFC 8461 §3 — Policy Discovery

To discover if a recipient domain implements MTA-STS, a sender need only resolve a single TXT record.

반송 경로 길이 advisory.return_path_length

반송 주소의 길이입니다. RFC 5321은 수신 서버가 @ 앞의 64옥텟을 허용하도록 요구하며, 같은 절에서 어떤 구현도 피할 수 있는 제한을 두어서는 안 된다고 명시합니다. 그런데도 많은 서버가 제한을 두며, 한도를 넘는 메시지는 본문이 전송되기도 전에 MAIL FROM 단계에서 거부됩니다. 전송 플랫폼은 반송을 원래 수신자와 연결할 수 있도록 수신자 정보를 반송 경로에 인코딩하기 때문에 이 문제를 겪으며, 이로 인해 길이가 발신자가 아닌 수신자에 따라 달라집니다.

실패하는 경우: 플랫폼이 앞에 추가하는 고정 부분을 줄이거나 반송 도메인을 더 짧은 도메인으로 변경하십시오. 둘 다 변경할 수 없다면 주소가 가장 긴 구독자가 위험하므로 평균이 아니라 목록에서 가장 긴 주소를 측정하는 것이 좋습니다.

권장 사항입니다. 점수는 차감되지 않습니다.

RFC 5321 §4.5.3.1.1 — Local-part

The maximum total length of a user name or other local-part is 64 octets.

RFC 5321 §4.5.3.1 — Size Limits and Minimums

Every implementation MUST be able to receive objects of at least these sizes.

Haraka — the address parser that enforces the 64-octet local-part, and the flag that relaxes it

TLS 보고 advisory.tls_rpt

누군가 TLS를 통해 해당 도메인으로 전송하지 못했을 때 도메인이 보고서를 요청하는지 여부입니다. MTA-STS와 함께 사용합니다. 보고가 없는 정책만으로는 정책이 작동하는지 알 수 없습니다.

실패하는 경우: 일일 보고서를 수신하는 주소가 포함된 TXT 레코드를 추가하세요.

권장 사항입니다. 점수는 차감되지 않습니다.

RFC 8460 §3 — Reporting Policy

A domain publishes a record to its DNS indicating that it wishes to receive reports.