Alguém preenche o seu formulário de contato. A página confirma: “Obrigado, entraremos em contato.” A pessoa fecha a aba e espera o seu retorno.
Você nunca liga, porque nunca recebeu a mensagem. Nenhum e-mail chegou, nem naquele dia, nem depois. O potencial cliente fica esperando em silêncio e depois vai procurar a próxima empresa cujo formulário funciona de verdade. Nada na tela avisou nenhum dos dois de que algo tinha falhado.
Como o WordPress envia esse e-mail de verdade
Veja o encanamento, em termos simples. Quando alguém envia um formulário do WordPress, o site chama uma função chamada wp_mail, que por padrão entrega a mensagem para a função nativa mail() do PHP, em vez de um serviço de e-mail dedicado. O PHP mail não faz login em lugar nenhum, não comprova que é você mesmo quem está enviando e não passa pelo tipo de infraestrutura verificada que o Gmail ou o Outlook esperam de um remetente legítimo. Ele só pede para o seu servidor web empurrar um e-mail porta afora e torce para dar certo. Isso costumava bastar. Hoje quase nunca basta, porque os provedores de e-mail reforçaram as defesas justamente contra esse tipo de envio sem autenticação e de baixo esforço, e uma simples chamada a mail() raramente passa no filtro.
O e-mail finge vir de você, e ninguém acredita
Seu formulário de contato costuma estar configurado para enviar “de” um endereço como you@yoursite.com, ou de algo que nem existe, como wordpress@yoursite.com. O campo De diz que é você, mas o servidor que realmente faz o envio nunca foi autorizado a enviar e-mails em nome do seu domínio. Todos os grandes provedores de e-mail verificam essa autorização hoje em dia. Quando ela não existe, eles não devolvem a mensagem com um erro claro que você perceberia. Eles descartam a mensagem em silêncio, ou a guardam em algum lugar que você nunca vai abrir. Seu site não está quebrado de nenhum jeito que você perceberia olhando para ele. Ele está fazendo uma afirmação que não consegue comprovar, e os provedores pararam de acreditar nela sem provas.
Sua hospedagem não envia o e-mail, ou envia pouco
Nem todo plano de hospedagem deixa um site enviar e-mails livremente. A hospedagem compartilhada, em especial, costuma limitar quantas mensagens um domínio pode enviar por hora, ou bloqueia de vez a função de e-mail do PHP, porque algum outro cliente do mesmo servidor já a usou para mandar spam e a empresa travou o recurso inteiro. Se a sua hospedagem é uma das mais rígidas, seu formulário pode parecer perfeito (a página confirma, o código roda sem erro) enquanto o envio real é engolido antes mesmo de sair do prédio. Você não vai ver nenhuma mensagem de falha, porque a falha acontece numa infraestrutura que você não consegue enxergar por dentro.
Seu domínio não consegue provar que o e-mail é legítimo
Mesmo quando o e-mail é enviado, os provedores que o recebem verificam registros DNS chamados SPF e DMARC para decidir se devem confiar nele. Juntos, eles são a forma de o seu domínio declarar quais servidores têm permissão para enviar e-mails em nome dele, e o que um servidor que recebe deve fazer com uma mensagem que não passa nessa verificação. Num site WordPress em que ninguém configurou isso de propósito, esses registros muitas vezes não existem ou estão configurados errado, e os e-mails do seu domínio acabam parecendo exatamente o tipo de mensagem que esses sistemas existem para filtrar.
Funcionava, até uma atualização mudar alguma coisa
O núcleo do WordPress, o seu tema e cada plugin do site se atualizam no próprio ritmo, e qualquer um deles pode mudar em silêncio a forma como os e-mails são enviados. Uma atualização do plugin de formulários troca a biblioteca de e-mail. Um plugin de segurança começa a bloquear uma conexão de saída que antes permitia. Um plugin de cache continua mostrando a página de confirmação antiga mesmo depois de o envio no servidor ter começado a falhar. Nada disso aparece como erro no seu Painel, porque, do ponto de vista do WordPress, o formulário foi enviado com sucesso. O que parou de funcionar em silêncio foi a camada de baixo, e uma atualização é o motivo mais comum para essa camada mudar sem que ninguém mexa nela de propósito.
O teste de 10 minutos
Antes de consertar qualquer coisa, confirme o que está acontecendo de verdade. Isso leva uns dez minutos e mostra com qual das falhas acima você está lidando.
- Faça um envio de teste real, usando um endereço de e-mail que não seja do Gmail: um e-mail do trabalho, uma conta do Outlook, o que você tiver. O filtro de spam do Gmail é agressivo o suficiente, por si só, para que um teste só com Gmail esconda um problema que outro provedor teria pegado.
- Confira a pasta de spam ou lixo eletrônico, e não só a caixa de entrada, no endereço que você usou no teste. Uma mensagem parada no spam é um problema diferente de uma mensagem que nunca chegou, e aponta para a parte de SPF e DMARC acima, e não para um bloqueio da hospedagem.
- Olhe o log de e-mails de verdade, e não a mensagem de confirmação. A maioria das hospedagens tem um log de e-mails no cPanel ou no painel de controle, ou você pode instalar um plugin gratuito como o WP Mail Logging, que registra cada e-mail que o WordPress tenta enviar e se deu certo. Só essa etapa já mostra se o WordPress chegou a tentar.
- Envie um segundo teste para outro provedor. Se chegar no Outlook mas não no Gmail, é um sinal forte de que o problema é de autenticação, específico da forma como um provedor avalia o seu domínio, e não um bloqueio geral da hospedagem.
- Passe o seu domínio pelo Check-up de saúde do site. Ele verifica seus registros SPF e DMARC (não o DKIM, que exige outro tipo de consulta) e mostra em menos de um minuto se o seu domínio está configurado para provar que os e-mails dele são legítimos. Um alerta ali costuma explicar tudo o que vem antes.
As opções honestas de correção
Depois que você sabe com qual falha está lidando, a solução costuma ser uma entre poucas opções. Nenhuma é truque; cada uma é um jeito real de resolver.
Instale um plugin de SMTP. É a resposta padrão dos desenvolvedores, e é uma resposta justa. Um plugin de SMTP redireciona os seus e-mails de saída por um serviço de e-mail de verdade, em vez da função mail() do PHP, o que resolve o problema de autenticação na raiz, porque agora o e-mail sai de uma infraestrutura em que os provedores já confiam. Leva uns vinte minutos se você se sente à vontade para criar uma chave de API e colar numa tela de configurações. Se não, é uma hora de trabalho razoável para passar a um desenvolvedor.
Mude para um serviço de formulários. Ferramentas feitas especificamente para lidar com envios de formulários, em vez de um plugin acoplado ao wp_mail, costumam mandar as notificações pela própria infraestrutura de envio verificada, driblando o problema inteiro. Você abre mão de um pouco de controle sobre a aparência e o comportamento exatos do formulário. Em troca, ganha um serviço cujo único trabalho é garantir que a mensagem chegue.
Deixe alguém cuidar do site por você. Se você prefere não aprender o que significa SPF, essa é uma posição válida, não uma falha sua. Esse é exatamente o tipo de manutenção que escapa num site WordPress cuidado por conta própria: ninguém percebe até que um potencial cliente liga para a concorrência. Se você prefere deixar de ser quem confere o log de e-mails toda vez que uma atualização quebra alguma coisa, pule para a opção de nunca mais se preocupar com isso.
Por que isso continua quebrando
Um site WordPress não é algo que se termina. É uma pilha de peças que se atualizam de forma independente (o núcleo, o tema, uma dúzia de plugins, a hospedagem por baixo de tudo), e qualquer uma delas pode mexer no chão em que as outras estão. Uma atualização de plugin daqui a seis meses pode quebrar este mesmo formulário de um jeito completamente diferente, e não vai ser culpa sua, assim como não é agora. Esse é o preço de manter um software que ninguém está acompanhando ativamente. A versão mais extrema que já vimos nem tinha a ver com formulário: 32 links de spam escondidos estavam injetados no código WordPress de uma empresa de mudanças fundada por veteranos, invisíveis na página, derrubando em silêncio as posições dela nos buscadores até que uma auditoria os encontrou. Um formulário de contato quebrado é a falha que você percebe, porque os potenciais clientes param de ligar. Muitas falhas do WordPress nunca chegam a ser percebidas.
Se você nunca mais quiser depurar isso
Se você prefere não ser quem confere logs de e-mail e lê registros DNS toda vez que isso quebra, é isso que o Surmado Sites resolve como parte de cuidar do site: a hospedagem e a entrega de e-mails, além da manutenção que impede uma correção de se desfazer na próxima atualização. Você pede uma vez, em linguagem simples, e fica resolvido.
Perguntas frequentes
Por que o formulário diz “enviado” se nada chega?
A confirmação de “mensagem enviada” é gerada pelo WordPress no momento em que o formulário é enviado e o wp_mail é chamado. Ela não espera um servidor de e-mail responder se a mensagem foi realmente entregue, porque a maioria das configurações de formulário de contato não foi feita para verificar isso. A confirmação significa que o WordPress tentou o envio. Não significa que alguém recebeu.
Os envios estão caindo no spam?
Às vezes, mas nem sempre. Se os seus registros SPF ou DMARC estão configurados errado, o e-mail que é enviado costuma cair no spam, porque os provedores que o recebem não conseguem verificar que ele vem mesmo do seu domínio. Se a sua hospedagem bloqueia o envio por completo, ou um conflito entre plugins o interrompe antes de ele sair do seu servidor, o e-mail nunca chega a ser enviado, então também não está no spam. Conferir um log de e-mails, ou o resultado do seu Check-up de saúde do site, mostra em qual das duas situações você está.
Por que parou de funcionar depois de uma atualização?
Porque algo nessa cadeia de atualizações mudou como os e-mails são enviados, ou se eles são enviados, e nenhuma dessas mudanças aparece como um erro visível em nenhum lugar do WordPress. Raramente é o plugin de que você suspeitaria primeiro. Por isso vale a pena conferir o log de e-mails logo depois de qualquer atualização, algo que leva dois minutos, antes de sair procurando a falha às cegas.
Preciso de um plugin de SMTP?
Nem sempre, mas muitas vezes, sim. Se os registros SPF e DMARC do seu domínio estão certos e o problema real é a hospedagem bloqueando ou limitando o e-mail do PHP, um plugin de SMTP que envie os e-mails por um serviço de e-mail de verdade é a correção mais direta. Se o problema está nos registros DNS, corrija isso primeiro; um novo método de envio não vai ajudar se o próprio domínio continuar sem conseguir provar que é legítimo. De qualquer forma, um plugin de SMTP é uma solução real e comum, não um quebra-galho, e também é mais uma coisa para configurar e manter funcionando, que é justamente a parte que um serviço de formulários ou um site gerenciado tira das suas mãos.