Adicionar um serviço de e-mail altera seu estado de envio mesmo quando o principal Registro DMARC permanece intocado. Uma plataforma de cobrança, suporte técnico ou aplicativo de marketing recém-adquirido pode exibir seu domínio em De enquanto autentica uma identidade diferente. Trate a integração como uma alteração em uma rota de correio comercial, não apenas como uma solicitação para colar registros DNS .
O objetivo é estabelecer um caminho de envio próprio, suportado e testado antes que os clientes dependam dele. A revisão pode ser pequena, mas deve abranger todos os fluxos de trabalho que o aplicativo utilizará e as evidências necessárias para mantê-lo posteriormente.
Defina o escopo de envio pretendido
Pergunte ao proprietário do aplicativo quais mensagens o serviço enviará, quais endereços De os usuários verão, quem as receberá e se o aplicativo possui caminhos transacionais e de marketing separados. Inclui operações de baixa frequência, como recuperação de conta e extratos agendados.
Registre quem controla a conta do provedor e quem pode alterar as configurações do remetente. Mantenha a segurança da conta e a aprovação comercial junto com a autenticação técnica. DMARC não estabelece que uma campanha, fatura ou solicitação específica foi autorizada pela sua organização.
Escolha o domínio pretendido deliberadamente. Um subdomínio pode fornecer um limite operacional, mas sua política e alinhamento o comportamento deve ser verificado. Não presuma que a política de aplicação do domínio principal fornece automaticamente a cada fluxo de trabalho filho o mesmo resultado. Use o guia de política de subdomínio ao planejar esse limite.
Obtenha a configuração real do provedor
Use as instruções originais atuais para o produto específico e modo de envio. Pergunte o que aparecerá em From, qual domínio de envelope o serviço usa e se ele fornece domínio de cliente DKIM assinando. A verificação da propriedade do domínio por si só não estabelece que as mensagens sejam assinadas com uma identidade alinhada.
Copie os valores DNS gerados da configuração de serviço autorizado em vez de um artigo de exemplo. Verifique os nomes exatos dos proprietários DNS , os tipos de registro, os registros existentes e a propriedade da zona antes de fazer uma alteração. UM seletor ou o token de verificação de outra conta não é um modelo reutilizável.
Se o serviço precisar de um SPF alteração, estabeleça qual SPF do domínio é avaliado e como a alteração afeta seu orçamento de pesquisa em RFC 7208 §4.6.4. Sob RFC 7208 §2.4 e RFC 7208 §4.4, adicionar o fornecedor ao SPF raiz da organização pode ser irrelevante quando o serviço usa um domínio de envelope diferente. Mantenha a mudança solicitada e sua justificativa juntas.
Torne a matriz de prontidão específica
A seguir está um exemplo de planejamento sintético, sem dados de teste observados. Suas células “pendentes” são deliberadas: as reivindicações de configuração devem ser substituídas por evidências antes da aprovação.
- Fluxo de Trabalho: Recibos; Pretendido do domínio:
billing.example.com; Evidências necessárias: Recibo recebido com DKIM alinhado, identidade do envelope e descoberta de política registrada; Decisão de liberação: teste pendente - Fluxo de trabalho: Redefinição de senha; Pretendido do domínio:
accounts.example.com; Evidências necessárias: Redefina a mensagem através do caminho real do aplicativo, incluindo qualquer gateway; Decisão de liberação: teste pendente - Fluxo de Trabalho: Campanhas; Pretendido do domínio:
news.example.com; Evidências necessárias: mensagem real da campanha, resultados de autenticação e requisitos aplicáveis do destinatário-provedor; Decisão de liberação: revisão pendente
Adicione o proprietário, a referência da conta do provedor, a documentação de origem, a data do último teste e a ação de reversão ao seu registro de trabalho. Fluxos de trabalho separados sempre que o serviço usar identidades de remetente ou infraestrutura de entrega diferentes. Um recebimento bem-sucedido não certifica um caminho de campanha.
Revise a diferença de política, incluindo nenhuma alteração
Capture a política existente e explique se a integração a altera. “Nenhuma mudança na política DMARC ” é um resultado legítimo se a nova rota for autenticada e alinhada à política existente. Ainda é uma decisão que vale a pena registrar.
A condição de passagem no nível da mensagem do DMARC requer uma identidade alinhada à passagem. Para uma implantação de aplicação, considere também a resiliência da rota: RFC 9989 diz que o proprietário de um domínio não deve confiar apenas no SPF quando a política de domínio do autor for p=reject. Verifique DKIM alinhado compatível em vez de depender apenas de um teste SPF de mala direta. Ver RFC 9989 §5.3.5 e RFC 9989 §8.
Não reduza uma política pai por padrão para acomodar um aplicativo não preparado. Primeiro resolva a configuração de identidade suportada do remetente. Se uma exceção temporária for necessária, obtenha uma aprovação do escopo com um proprietário, expiração e teste de saída. Registre o risco preciso e o domínio afetado, em vez de uma promessa geral de que a entrega irá melhorar.
Teste a rota que a empresa usará
Envie exemplos não confidenciais para destinatários autorizados em cada fluxo de trabalho. Registre o sistema de recebimento confiável, o domínio do domínio, a identidade SPF , todos os resultados relevantes DKIM , a política aplicável e o resultado DMARC . Teste após qualquer estágio de gateway ou encaminhamento que pertença à rota pretendida.
Verifique a entrega real separadamente. Um passe DMARC não garante a colocação na caixa de entrada ou o cumprimento de todas as regras do provedor destinatário. Por exemplo, os requisitos de envio em massa do Gmail incluem configuração SPF , DKIM e DMARC , bem como requisitos de entrega adicionais. Consulte o atual Diretrizes para remetentes Gmail quando esse público é relevante.
Aprove apenas os fluxos de trabalho que possuem evidências suficientes. Se um trabalho de baixa frequência ainda não puder ser exercido, mantenha-o como pendente com uma ação agendada do proprietário, em vez de marcar todo o pedido como concluído.
Monitore e aposente-se deliberadamente
Compare o próximo relatórios agregados e logs de entrega de aplicativos com o padrão de remetente esperado. Os relatórios podem revelar tráfego, mas não podem, por si só, provar que a conta do provedor foi autorizada ou que todos os fluxos de trabalho raros foram exercidos.
Defina a recuperação antes do lançamento: desative o fluxo de trabalho de envio afetado, restaure a configuração do remetente aprovado ou encaminhe através de um serviço previamente verificado, quando houver suporte. A reversão DNS tem consequências de cache, incluindo o uso qualificado de respostas obsoletas após a expiração do TTL em RFC 8767 §4, portanto não é uma reversão universal instantânea.
Finalmente, defina uma condição de aposentadoria. Quando o aplicativo for removido, revise suas permissões de envio, conta do provedor e dependências DNS antes da limpeza. Mantenha o inventário do remetente atual por meio de compra, alteração e baixa, não apenas no dia Aplicação DMARC está habilitado.
Torne a próxima decisão explícita
No dispositivo de planejamento, um caminho de recebimento verificado não limparia as linhas de redefinição ou de campanha. Registre cada resultado real e a data da evidência ou mantenha “pendente”. Para uma decisão política sem alteração, registe ainda a configuração da identidade e a rota testada. Os exemplos de planejamento não afirmam que existe qualquer conta de aplicativo, registro DNS ou teste de mensagem.