SPF 유효성 검사는 이메일 전달률 향상과 피싱 및 스팸으로부터 도메인을 보호하는 데 중요합니다. 피싱 및 스팸 공격으로부터 도메인을 보호하는 데 중요합니다. 하지만 SPF 설정은 복잡하고 구성하는 동안 오류가 발생할 수 있습니다. 이러한 일반적인 오류를 수정하고 방지하면 오탐이 발생하지 않고 DMARC 을 제대로 준수할 수 있습니다.
SPF 설정을 구성할 때 피해야 할 7가지 일반적인 실수
일부 DNS 메커니즘은 이메일 반환 경로 주소로 이메일을 보낼 수 있도록 허용된 시스템의 IP를 명시하는 데 사용됩니다. 그러나 이러한 메커니즘을 잘못 사용하면 SPF 레코드 크기 초과, 10회 이상의 DNS 조회, 2회 이상의 미해결 DNS 조회 등의 오류가 발생합니다.
SPF 설정을 구성할 때 이러한 오류를 방지할 수 있도록 일반적인 SPF 오류를 나열했습니다.
실수 1: 여러 개의 SPF 기록
도메인당 하나의 SPF 항목이 있어야 하며, 그렇지 않으면 수신 서버가 두 항목을 모두 거부합니다. 현재 사용하지 않는 SPF 항목(예: 활성 SPF 항목이 있는 더 이상 사용되지 않는 서비스)을 제거합니다.
두 개 이상의 레코드를 하나로 병합하여 이 SPF 설정 실수를 해결할 수 있습니다. 사용자 도메인에 SPF 레코드가 있고 Elastic Email SPF 항목이 포함되어 있지만 확인 검사를 통과하지 못한다고 가정해 보겠습니다. 그 이유는 도메인에 2개의 레코드가 존재하기 때문일 수 있습니다.
v=spf1 a mx include:_샘플레도메인1.com include:_spf.elasticemail.com ~all
v=spf1 a mx include:_sampledomain2.com ~all
다음과 같이 단일 레코드로 병합하여 이 문제를 해결할 수 있습니다:
v=spf1 a mx include:_샘플레도메인1.com include:_샘플레도메인2.com include:_spf.elasticemail.com ~all
실수 2: 너무 많은 DNS 조회 횟수
'포함' 조회는 10개로 제한되어 있으므로 다른 도메인에 대한 참조를 10개 이상 생성할 수 없습니다. 매개변수 "include", "a", "mx", "ptr", "exists" 및 "redirect"가 발생할 때마다 조회가 생성됩니다. 또한 도메인이 'include' 안에 참조된 도메인에 다른 매개변수가 포함되어 있으면 이 매개변수도 조회 한도 10개로 계산됩니다. 따라서 조회 제한을 초과하는 것은 SPF 설정을 구성하는 동안 발생하는 가장 일반적인 오류 중 하나입니다.
이 문제를 해결하려면 '포함' 및 비활성 도메인에 대한 참조를 제거하면 됩니다.
실수 3: 관용적 all 메커니즘
SPF 레코드는 왼쪽에서 오른쪽으로 해석되며, 'all' 메커니즘은 '모든' 메커니즘과 일치하지 않는 발신자와 일치합니다. 'all' 메커니즘을 SPF 레코드 끝에 배치하고 ~(소프트 실패) 또는 -(실패) 접두사와 함께 사용하는 것이 좋습니다. 접두사를 설정하지 않으면 기본적으로 +(통과)가 사용됩니다.
실수 4: 실수 ptr 메커니즘
SPF 'ptr' 메커니즘은 호스트 이름을 해당 IP 주소로 반환하는 역방향 DNS 조회에 사용됩니다. 이 정보는 특히 B2B 브랜드에 유용합니다. 그러나 이 메커니즘은 안정성 문제가 있으며 역방향 DNS 서버와 이에 연결된 이메일 시스템에 부담을 줍니다.
그렇기 때문에 RFC7208에서는 'ptr' 메커니즘의 사용을 권장하지 않는 이유입니다. 대부분의 경우 'a' 메커니즘으로 대체할 수 있습니다.
실수 5: 실수 mx 메커니즘
사용 'mx' 를 메일 서버 이름이 아닌 도메인 이름과 함께 사용하세요. 예 mx:mailserver.sample.com 을 명시하는 것은 'mailserver.sample.com' 도메인에 대해 메일을 수락하는 모든 호스트를 조회하기 위해 실제로 SPF 유효성 검사가 필요하지 않는 한 잘못된 것으로 간주됩니다. 대부분의 경우 'mailserver.sample.com' 자체가 도메인이 아니라 호스트이므로 이러한 호스트는 없을 것입니다.
구문 오류로 표시되지는 않지만 단순히 아무 것과도 일치하지 않습니다.
'sample.com'에 대한 MX 레코드에 대해 유효성을 검사하는 올바른 방법은 다음과 같습니다. mx:sample.com. 특정 메일 서버의 호스트 이름이나 IP 주소를 정의해야 하는 경우, a:mailserver.sample.com 또는 ip4:x.x.x.x.x를 사용해야 합니다.
실수 6: 적절한 조사 없이 SPF 기록 만들기
이는 특히 ISP에게 중요합니다. 도메인, 소유자, 도메인에 속한 브랜드에 대한 정보가 반쪽짜리인 레코드를 만들지 마세요. 어떤 이메일 서버를 사용하는지 조사하세요. 그렇지 않으면 사내 메일 서버에서 발신 이메일 전송 경로가 차단될 수 있습니다.
실수 7: 오타
SPF 레코드에 오타가 있는지 다시 한 번 확인하여 SPF 설정을 구성하는 동안 흔히 발생하는 실수를 방지하세요. '포함' 대신 '포함'을 입력할 수 있습니다. 이렇게 하면 전체 레코드가 무효화될 수 있습니다.
실수 8: 이메일 서버에서 사용하는 헬로 이름에 대한 SPF 레코드를 게시하지 않음
Verifying HELO or EHLO names is encouraged by the SPF RFC. HELO or its developed version EHLO is used when Mail from is <> despite the recipient’s failure in doing 100% HELO checking.
HELO 프로토콜을 게시하려면 메일 서버에서 사용하는 HELO FQDN에 해당하는 SPF 레코드를 생성해야 합니다. 예를 들어 mailserver.sample1.com
일반적으로 'sample1.com'에 연결된 도메인의 발신자 주소를 확인하는 규칙과는 완전히 별개의 SPF 규칙이어야 합니다.
실수 9: TXT 레코드 콘텐츠가 큰따옴표로 표시되지 않음
DNS TXT 레코드의 콘텐츠는 항상 큰따옴표("-") 안에 있지만, 실제 DNS 레코드 콘텐츠의 일부가 되어서는 안 됩니다. 이 따옴표는 TXT 레코드 콘텐츠의 시작과 끝을 구분하는 데 도움이 되므로 표시 목적으로만 사용됩니다.
SPF 레코드는 다음과 같이 시작해야 합니다. v=spf1 로 시작해야 하지만 "v=spf1으로 시작하면 전혀 인식되지 않습니다.
여전히 문제가 있으신가요?
SPF 설정을 변경할 때마다 인터넷을 통해 전파되는 데 시간이 필요합니다. 최대 72시간까지 걸릴 수도 있습니다. 그래도 문제가 계속 발생하면 무료로 제공되는 SPF 기록 검사기 도구를 사용하거나 다음 주소로 전문가 팀에 문의하세요. support@powerdmarc.com.
- 블록체인이 이메일 보안을 개선할 수 있을까요? - 2024년 5월 9일
- 데이터센터 프록시: 프록시 세계의 주력 제품 공개 - 2024년 5월 7일
- 최근 피싱 공격에서 DMARC "없음" 정책을 악용한 킴수키(Kimsuky) - 2024년 5월 6일