O WordPress costuma ser o aplicativo que cria uma mensagem, não o serviço que a envia ao destinatário. Um nome de plugin ou uma notificação “enviada” não identifica o IP avaliado por SPF ou o domínio em um Assinatura DKIM. Acompanhe um evento real de aplicativo além da fronteira entre o WordPress, seu transporte e a caixa postal de recebimento.
Identifique quem é o dono de cada estágio
Comece com o evento: uma solicitação de redefinição de senha, notificação de pedido ou envio de formulário de contato. Registre o plug-in ou o caminho do código que cria a mensagem, o endereço De configurado, o plug-in de transporte, se presente, e se ele usa correio PHP local, SMTP remoto ou uma API de provedor. O manual de e-mail do WordPress explica que os plug-ins podem substituir a rota de envio padrão por serviços de terceiros.
Inspecione a configuração por meio de administração autorizada sem copiar credenciais em um ticket. Registre o nome do serviço, o rótulo da conta ou do projeto e o domínio de envio, mas mantenha os segredos da API e as senhas SMTP fora do arquivo de evidências. Verifique também o comportamento de fallback. Um plugin pode ser configurado corretamente para sua rota principal enquanto um trabalho separado ou substituto usa o servidor de hospedagem.
Não confunda sucesso de aplicação com entrega
O WordPress documenta que um valor de retorno wp_mail() verdadeiro significa que o método de envio processou a solicitação sem erro, e não que o destinatário recebeu a mensagem. Da mesma forma, um provedor que aceita uma chamada de API estabelece um estágio diferente da entrega final.
Correlacione o evento do aplicativo com um identificador de transporte ou provedor e, quando disponível, um evento de entrega ou devolução. Mantenha os carimbos de data/hora em um fuso horário consistente. Caso o provedor não tenha registro do evento, investigue o caminho da aplicação e do plugin antes de alterar o DNS do provedor. Se ele aceitou o evento, mas o receptor o rejeitou, colete todas as evidências de diagnóstico e autenticação SMTP .
Configure a autenticação no remetente real
Para um serviço SMTP ou API remoto, use o fluxo de autenticação de domínio atual desse serviço. Publique seu gerado DKIM TXT ou CNAME registra exatamente e ativar o domínio quando necessário. Determine o domínio do envelope e se o produto suporta uma rejeição personalizada ou caminho de retorno domínio. Não invente um SPF para todo o WordPress; WordPress não é uma rede universal de e-mail de saída.
Para uma rota de servidor de hospedagem, trabalhe com o host ou administrador de e-mail para identificar a infraestrutura real de envio público e o assinante DKIM compatível. Adicionar o IP do site ao SPF sem comprovar que ele envia o e-mail pode autorizar o sistema errado. Mantenha uma política SPF apropriada no domínio do envelope avaliado e leve em consideração o limite de pesquisa.
Para DMARC, escolha um endereço De em um domínio para o qual a organização está autorizada a enviar. O endereço de um visitante de formulário de contato normalmente pertence a Responder para, não como uma identidade From forjada. Configure um caminho autenticado alinhado para o domínio De da organização e coordene a política com outros remetentes legítimos. Reply-To não estabelece DMARC alinhamento.
Trabalhe por meio de um rastreamento de evento sintético
Apenas ilustração, não um WordPress executado ou teste de provedor:
- Etapa: Evento de pedido; Exemplo de rótulo de evidência: order-test-42; O que estabelece: Aplicativo solicitou notificação.
- Etapa: Envio do plugin; Exemplo de rótulo de evidência: transport-event-42; O que estabelece: O transporte selecionado atendeu a solicitação.
- Etapa: Aceitação do fornecedor; Exemplo de rótulo de evidência: provedor-message-42; O que estabelece: O provedor remetente aceitou o evento.
- Etapa: Recebimento externo; Exemplo de rótulo de evidência: cabeçalhos brutos redigidos; O que estabelece: Final From, envelope, resultados DKIM e DMARC .
Suponha que a mensagem entregue use orders@example.com , um domínio de envelope de propriedade do provedor e uma assinatura d=example.com de passagem. DKIM pode fornecer autenticação DMARC alinhada mesmo se SPF não estiver alinhado. Se o substituto enviar mensagens não assinadas de um IP de hospedagem não autorizado para o domínio do envelope, o mesmo evento de aplicativo poderá produzir um resultado diferente. Teste o substituto deliberadamente apenas dentro de um escopo aprovado.
Deixe uma transferência sustentável
Atribua proprietários separados de aplicativos, transporte e DNS . Armazene a versão de configuração, os registros públicos gerados e as evidências de teste redigidas com ou sem sucesso. Exercite redefinições de senha e outros eventos críticos após atualizações de plug-ins, migração de hospedagem, alterações de provedor, alterações de endereço de origem ou rotação de chave. Monitore rejeições e falhas reais em vez de confiar no status verde do WordPress.
Após a aposentadoria, desative o acesso de transporte não utilizado e remova a autorização DNS obsoleta somente após verificar as dependências compartilhadas. Não remova os registros de um provedor apenas porque um plug-in foi substituído se outros aplicativos ainda usarem esse remetente.
Separe quatro locais de falha
Use o rastreamento de eventos para distinguir nenhum evento de aplicativo, nenhum envio de transporte, rejeição do provedor e falha do destinatário final. Registro desconhecido quando um estágio não possui log confiável. Não infira a rejeição do provedor a partir de uma mensagem ausente na caixa de entrada ou o recebimento final de um retorno de método bem-sucedido. Preserve os identificadores originais durante a transferência para que os proprietários do aplicativo e do correio investiguem o mesmo evento.