Com SPF (Sender Policy Framework), tem a flexibilidade de configurar o seu sistema para responder a falhas de autenticação de uma de duas formas: Hardfail ou SoftfailNeste blogue, vamos discutir as diferenças entre SPF hardfail e softfail, a sintaxe para configurar ambos e os seus casos de utilização. Então, vamos mergulhar de cabeça!
A diferença entre SPF Softfail e Hardfail
O quadro seguinte explica a diferença básica entre o SPF hardfail e o softfail.
Sintaxe do SPF | Tipo de falha | Estado | Ação correspondente tomada pelo destinatário |
---|---|---|---|
v=spf1 include:domain1.com -all | Falha grave | Remetente não autorizado | O correio eletrónico pode ser rejeitado |
v=spf1 include:domain1.com ~all | Softfail | O remetente pode não estar autorizado | O correio eletrónico é entregue mas marcado como suspeito ou potencialmente fraudulento |
SPF Hardfail Vs Softfail : Como definido no RFC
De acordo com o RFC 7208:
- Um resultado "Fail" para SPF indica diretamente que o remetente do e-mail não está autorizado pelo domínio de envio. "Fail" é sinónimo do resultado Hardfail (-all), que é claramente indicativo de utilização não autorizada do domínio.
- No entanto, uma abordagem muito mais relaxada é a configuração do SPF Softfail, que indica uma indicação "provável" de utilização não autorizada do domínio.
Simplifique o SPF com o PowerDMARC!
Tratamento da falha do destinatário para Hardfail Vs Softfail
Na secção 8.4o RFC define os seguintes cenários de tratamento de resultados para resultados SPF hardfail e para resultados SPF softfail:
1. SPF Hardfail / Fail
Para o resultado "Fail" ou hardfail, o servidor do destinatário pode optar por rejeitar o correio eletrónico não autorizado. Se se tratar de uma transação SMTP, deve ser devolvido um código de erro 550 5.7.1 com uma descrição de erro adequada.
Se o servidor destinatário não rejeitar o correio eletrónico durante a transação SMTP, o RFC recomenda que os destinatários registem os resultados SPF no cabeçalho Received-SPF ou Authentication-Results.
2. SPF Softfail
Como política mais flexível, o Softfail indica que o domínio de gestão administrativa suspeita que a mensagem de correio eletrónico não é autorizada, mas não pretende rejeitá-la de imediato. Neste caso, a mensagem é entregue, mas com um aviso para análise posterior.
SPF Softfail Vs Hardfail: O que recomendamos?
No caso da retransmissão de correio eletrónico SMTP, pode considerar o SPF softfail como uma aposta mais segura contra o hardfail. Vamos descobrir como:
A retransmissão de correio eletrónico SMTP é a transferência automática de mensagens de um servidor para outro. Isto significa que o e-mail é entregue a um servidor cujo endereço IP não está listado no registo SPF do seu domínio. Isto torna-o um remetente não autorizado para o seu correio eletrónico, embora, na prática, seja legítimo.
Tem algum controlo sobre esta atividade? A resposta é não, uma vez que o correio eletrónico é retransmitido automaticamente do lado do destinatário. Nestas circunstâncias, o SPF falhará para os e-mails retransmitidos.
É aqui que ter uma política de hardfail SPF pode causar-lhe problemas! Como já sabemos, os mecanismos de hardfail podem levar à rejeição de mensagens falhadas. Assim, estes e-mails retransmitidos podem não ser entregues se o seu domínio estiver configurado com uma política de hardfail.
A pior parte? A ação tomada pela política de tratamento de falhas SPF irá sobrepor-se aos resultados da autenticação DMARC e DKIM. Essencialmente, mesmo que o DKIM e, subsequentemente, o DMARC sejam aprovados, o correio eletrónico pode não ser entregue.
Conforme especificado no RFC 7489 Secção-10.1 se as verificações SPF forem efectuadas antes das operações DMARC, a presença de um prefixo "-" no mecanismo SPF de um remetente, como "-all", pode levar à rejeição imediata de mensagens de correio eletrónico. Esta rejeição ocorre no início do processo de tratamento do correio eletrónico, mesmo antes de se efetuar qualquer processamento DMARC.
Por conseguinte, se a política SPF de um remetente de correio eletrónico incluir um mecanismo "-all", indicando uma política rigorosa de rejeição de mensagens de correio eletrónico que não passem nas verificações SPF, poderá resultar na rejeição da mensagem antes de ocorrer qualquer política ou processamento DMARC. Esta rejeição antecipada pode ocorrer independentemente de o correio eletrónico poder vir a ser aprovado na autenticação DMARC.
Assim, nestas circunstâncias, o SPF Softfail triunfa sobre o mecanismo Hardfail. É uma abordagem de risco consideravelmente baixo que deixa espaço para revisão, simplesmente assinalando os e-mails autorizados em vez de os rejeitar.
Como funcionam os Registos SPF?
Para implementar o SPF nos seus e-mails, é necessário criar e publicar um registo SPF no DNS do seu domínio. Um exemplo típico de um registo SPF é o seguinte:
v=spf1 include:_spf.google.com ~all
Neste registo SPF, está a autorizar todos os e-mails provenientes de endereços IP listados no registo SPF da Google. O mecanismo de falha é definido no final do registo (~all), ou seja, Softfail.
Assim, um registo SPF define a versão do protocolo utilizado, as fontes de envio que está a autorizar e o mecanismo de falha. Quando publica este registo no seu DNS, garante que apenas os remetentes autorizados podem enviar e-mails em nome do seu domínio. Se uma fonte não autorizada tentar fazer-se passar por si, o SPF falha com o tipo de mecanismo de falha definido no seu registo.
Estratégias de implementação segura do SPF
A implementação óptima do SPF é essencial para proteger a comunicação por correio eletrónico contra ataques não autorizados de falsificação e phishing. Ao seguir as melhores práticas, as organizações podem melhorar a sua postura de segurança de correio eletrónico e proteger a reputação da sua marca. Aqui estão algumas estratégias e directrizes para implementar o SPF de forma segura:
1. Utilizar uma ferramenta de geração de registos SPF
O processo de implementação do SPF começa com a geração de registos. Pode criar o seu registo manualmente se tiver um conhecimento adequado das etiquetas SPF. No entanto, este método está sujeito a erros humanos. Idealmente, pode utilizar o nosso gerador de SPF automatizado. Esta ajuda-o a criar um registo SPF preciso e sem erros, personalizado de acordo com as necessidades da sua organização.
2. Utilizar mecanismos SPF adequados
Utilize mecanismos SPF, como "include", "a" e "IP4", para especificar as fontes de envio permitidas. Seja criterioso na seleção de mecanismos com base na sua infraestrutura de correio eletrónico e certifique-se de que estes reflectem com precisão as suas práticas de envio de correio eletrónico.
3. Manter e otimizar o seu registo SPF
O seu registo Sender Policy Framework tem de ser mantido e optimizado para evitar o seu mau funcionamento. O SPF tende a falhar quando os seus remetentes autorizados excedem o limite de 10 pesquisas de DNS no lado do recetor. Para manter um limite de pesquisa ideal, o nosso SPF hospedado hospedado é a sua melhor aposta! Ajudamos os proprietários de domínios a otimizar o SPF com um único clique, para se manterem abaixo dos limites de pesquisa e de anulação e para manterem um SPF sem erros.
4. Combinar SPF com DMARC
Implementar DMARC (Domain-based Message Authentication, Reporting, and Conformance) juntamente com o SPF fornece uma camada adicional (mas essencial) de segurança. O DMARC permite que os proprietários de domínios especifiquem políticas de tratamento de correio eletrónico, incluindo a ação a tomar em relação aos emails que falham o SPF.
O DMARC demonstrou resultados comprovados na minimização de ataques de fraude, comprometimento e falsificação de identidade no correio eletrónico.
5. Implementar políticas rigorosas de tratamento de falhas SPF
Configure o seu registo para tratar falhas de autenticação SPF com políticas rigorosas, como rejeitar ou marcar emails de domínios com falhas. Para o fazer, pode implementar SPF hardfail ou SPF softfail em vez de uma política neutra.
6. Monitorizar os resultados da autenticação SPF
Implementar relatórios DMARC para monitorizar os resultados da autenticação SPF, tais como SPF aprovado e reprovado, bem como erros de alinhamento. A analisador DMARC pode ajudá-lo a analisar os dados de autenticação SPF de forma organizada e legível.
Palavras finais
Não existe uma resposta direta à pergunta "Qual é o melhor? SPF hardfail ou softfail". Embora a etiqueta hardfail possa proporcionar uma maior segurança, a escolha da solução correcta para monitorizar as suas fontes de envio torna-se crucial.
A plataforma avançada de autenticação de domínios e relatórios do PowerDMARC fornece soluções abrangentes de SPF e DMARC para empresas de todos os tamanhos. Registe-se hoje para uma avaliação gratuita!
- Yahoo Japan impõe a adoção de DMARC aos utilizadores em 2025 - 17 de janeiro de 2025
- Botnet MikroTik explora erros de configuração de SPF para espalhar malware - 17 de janeiro de 2025
- DMARC Correio Não Autenticado é Proibido [SOLVED] - January 14, 2025