Zendesk ativa o perfil Minimal: um SPF com falha pode bloquear suas mensagens ao suporte
Por CaptainDNS
Publicado em 30 de setembro de 2026
Atualizado em 30 de setembro de 2026

Você escreveu para o suporte de uma empresa de software e ainda está esperando resposta. Desde 23 de setembro de 2026, sua mensagem pode ter ficado fora da fila de tickets. O Zendesk está migrando para o perfil "Minimal" as contas que não tinham ativado nenhum controle do remetente. Com esse perfil, um SPF com falha sem DKIM válido é suficiente para que um email nunca vire ticket.
- Desde 23 de setembro de 2026, as contas do Zendesk com a autenticação de remetentes desativada estão migrando aos poucos para o perfil "Minimal".
- Nesse perfil, um SPF com falha é pior do que um SPF ausente: sem DKIM válido, o primeiro manda o email para os tickets suspensos e o segundo deixa passar com um alerta.
- Confira o SPF e a assinatura DKIM do seu domínio. Se você administra o Zendesk, fique de olho na visualização "Suspended tickets".
O que muda com o perfil Minimal como padrão
Em 18 de junho de 2026, o Zendesk anunciou uma nova regra de segurança para a autenticação de remetentes. O anúncio oficial, atualizado em 28 de setembro de 2026, descreve uma implantação em duas fases.
A fase 1 vale para as contas novas, que já são criadas com o perfil "Minimal" como padrão. A fase 2 mira as contas existentes com a autenticação de remetentes desativada: o Zendesk aplica a elas o "Minimal" como perfil padrão.
O cronograma dessa fase 2 traz duas datas de término na mesma página. A tabela indica início em 23 de setembro de 2026 e término em 22 de outubro de 2026. Já o texto fala de uma implantação gradual de 23 de setembro a 16 de dezembro de 2026. Citamos as duas, porque a página oficial não diz qual delas vale. Uma conta que ainda está desativada hoje pode, portanto, mudar de perfil nas próximas semanas, sem data definida.
Quem administra a conta continua no controle. É possível desativar a autenticação ou escolher um perfil mais rigoroso: "Native traffic" ou "Native and forwarded traffic (ARC)". Uma regra não muda: para os emails enviados pelos agentes, a autenticação fica sempre ativa e não pode ser desligada.
Suspenso, sinalizado ou aceito: os três resultados
A documentação do Zendesk sobre a autenticação de emails recebidos apresenta o "Minimal" como o perfil menos rigoroso. Ele cruza dois resultados. O SPF verifica se o servidor que envia a mensagem está na lista publicada pelo domínio do remetente. O DKIM verifica uma assinatura criptográfica adicionada no envio.
| Resultado SPF | Resultado DKIM | Resultado no Zendesk |
|---|---|---|
| Com falha | Ausente ou com falha | Suspenso: visualização "Suspended tickets", causa "Email authentication failed" |
| Não configurado para o domínio remetente | Com falha | Aceito, marcado como "Potential spoofing" (possível falsificação) |
| Todos os outros casos | Todos os outros casos | Aceito |
Uma mensagem suspensa não vira ticket. Ela fica na visualização "Suspended tickets" (tickets suspensos), com a causa "Email authentication failed" (falha na autenticação do email). Nenhum agente vai vê-la na fila de sempre.
A segunda linha merece atenção. Um domínio que não publica nenhum SPF, com uma assinatura DKIM com falha, passa mesmo assim. O agente vê um alerta, mas recebe o ticket.
Por que um SPF com falha é pior do que um SPF ausente
Olhe a situação pelo lado do cliente, não da empresa de software. Você escreve do seu domínio para o suporte de um software que roda no Zendesk. Seu domínio publica um SPF, mas o servidor que entregou sua mensagem não está nele: um novo provedor de envio que ficou de fora, um include removido por engano. O SPF falha. Se sua mensagem não tiver uma assinatura DKIM válida, o Zendesk a suspende. Você fica esperando uma resposta; a empresa, do lado dela, não tem nenhum ticket para tratar.
A mesma mensagem, enviada de um domínio sem SPF e com o mesmo DKIM com falha, teria chegado com o alerta "Potential spoofing". Nesse perfil, um SPF com falha pesa mais do que um SPF ausente.
Não conclua que você deve remover seu SPF. Sem ele, seu domínio fica mais fácil de falsificar, e o DMARC perde um dos dois mecanismos em que se apoia. A resposta certa é corrigir o SPF e assinar suas mensagens com DKIM. No perfil "Minimal", um DKIM válido é suficiente para evitar a suspensão, mesmo quando o SPF falha.
O encaminhamento deixa esse ponto ainda mais concreto. Muitas empresas publicam um endereço de suporte no próprio domínio e depois o encaminham para o Zendesk. O servidor que entrega sua mensagem ao Zendesk deixa de ser o seu, e seu SPF muitas vezes falha sem que o seu registro tenha qualquer problema. Já a assinatura DKIM continua válida enquanto o relay não modificar a mensagem. É ela que leva a mensagem até o ticket.
O que conferir, primeiro como remetente e depois como administrador do Zendesk
Como remetente, comece pelo SPF. Liste os serviços que enviam emails com o seu domínio: serviço de email, CRM, faturamento, ferramenta de campanhas de email. Cada um precisa estar autorizado no seu registro. O verificador SPF da CaptainDNS lê o registro publicado, expande os include e testa se um determinado endereço IP está autorizado.
Depois, confira se cada fluxo de saída leva uma assinatura DKIM válida, feita com o seu domínio e não só com o do provedor. A assinatura alinhada ao seu domínio é a que o DMARC leva em conta. Se uma mensagem recente para um suporte ficou sem resposta, faça essas duas verificações antes de reenviá-la: um novo envio nas mesmas condições vai ter o mesmo destino.
Do lado da administração do Zendesk, a orientação do fornecedor cabe em uma frase: "Monitor your Suspended tickets view regularly", ou seja, monitore regularmente a visualização de tickets suspensos. O Zendesk acrescenta que problemas de spam devem ser resolvidos na origem ("Spam issues must be resolved at the source"). Um cliente legítimo que aparece nessa visualização com a causa "Email authentication failed" não está necessariamente errado: talvez o SPF ou o DKIM dele precise de correção, mas um encaminhamento também pode fazer o SPF dele falhar. Verifique primeiro os seus próprios encaminhamentos e, se for ele quem precisa corrigir o domínio, avise-o por outro canal.
Se o seu endereço de suporte é um alias encaminhado para o Zendesk, veja também o perfil "Native and forwarded traffic (ARC)". Ele é mais rigoroso do que o "Minimal", mas se apoia no ARC, um mecanismo que preserva os resultados de autenticação de um relay para o outro.
Confira a assinatura DKIM do seu domínio
Um DKIM válido evita a suspensão mesmo quando o SPF falha. Teste cada seletor usado pelos seus serviços de envio.
O que este artigo não é
Este post não detalha as regras que o Gmail impõe aos remetentes: nosso artigo sobre o endurecimento das regras de envio do Gmail a partir de novembro de 2025 trata delas separadamente.
Também não é um guia de solução de problemas de SPF. Para um erro de sintaxe, um mecanismo mal escrito ou a ultrapassagem das 10 consultas DNS, leia o guia de SPF PermError. As assinaturas com falha têm seu próprio artigo: DKIM fail: todas as causas e como corrigir.
Por fim, este post não compara as ferramentas de atendimento do mercado. Ele se limita ao Zendesk e ao seu perfil "Minimal", com base nas duas páginas oficiais citadas mais abaixo.
FAQ
Meu email para um suporte no Zendesk ficou sem resposta. Ele foi suspenso?
É possível, se o SPF do seu domínio falhou e sua mensagem não tinha DKIM válido. Nesse caso, ela está na visualização "Suspended tickets" da empresa, com a causa "Email authentication failed". Confira seu SPF e seu DKIM e depois entre em contato com a empresa por outro canal.
Por que um SPF com falha bloqueia e um SPF ausente passa?
No perfil "Minimal", o Zendesk suspende um email quando o SPF falha e o DKIM está ausente ou com falha. Se o domínio não tem SPF configurado e o DKIM falha, o email é aceito com o alerta "Potential spoofing". Corrija seu SPF em vez de excluí-lo.
Quando minha conta do Zendesk vai migrar para o Minimal?
As contas novas já estão nele. Para as contas existentes com a autenticação desativada, a página oficial indica início em 23 de setembro de 2026, com término em 22 de outubro de 2026 na tabela e em 16 de dezembro de 2026 no texto. O Zendesk não diz qual das datas vale.
Como evitar a suspensão quando um email é encaminhado?
Assine suas mensagens com um DKIM válido e alinhado ao seu domínio: ele continua válido se o relay não modificar a mensagem, enquanto o SPF costuma falhar depois de um encaminhamento. Do lado da administração, o perfil "Native and forwarded traffic (ARC)" leva em conta as mensagens encaminhadas.
Fontes: anúncio do Zendesk sobre o novo padrão de autenticação de remetentes e documentação do Zendesk sobre a autenticação de emails recebidos (SPF, DKIM, DMARC e ARC).


