DMARC: Como Proteger Sua Reputação de Email
Pássaro
13 de abr. de 2016
1 min read
Principais Conclusões
O DMARC ajuda a proteger seu domínio contra phishing, spoofing e uso não autorizado de e-mail, publicando suas práticas de autenticação e solicitando um tratamento específico para mensagens que falham.
Ele funciona juntamente com SPF e DKIM para garantir o alinhamento do domínio e evitar que e-mails fraudulentos danifiquem sua reputação como remetente.
Políticas DMARC fortes suportam maior confiança, maior engajamento e tornam seu domínio à prova de futuro à medida que o ecossistema se afunila em direção a modelos de reputação baseados em domínio.
As verificações de validação DMARC dependem do alinhamento de domínio entre o domínio From, o domínio Return-Path (SPF) e o domínio de assinatura DKIM.
Configurar o DMARC requer receber relatórios, entender dados agregados vs. forenses e configurar ferramentas para analisá-los.
Você começa com uma política p=none segura para monitorar o tráfego antes de passar para quarantine ou reject.
Publicar um registro DMARC envolve criar uma entrada TXT DNS em _dmarc.seudominio.com com política, endereços de relatório e parâmetros opcionais como percentual de implementação.
Caixas de correio de relatório adequadas (agregadas + forenses) e ferramentas de análise são essenciais para monitorar conformidade, detectar spoofing e garantir que o alinhamento esteja correto.
O DMARC exige apenas um dos seguintes para passar: SPF alinhado ou DKIM alinhado.
Implementar DMARC fortalece a segurança do e-mail e desempenha um papel fundamental na integridade da marca, confiança e entregabilidade a longo prazo.
Destaques de Perguntas e Respostas
O que é DMARC e por que isso é importante?
DMARC (Autenticação, Relatório e Conformidade de Mensagens Baseadas em Domínio) é uma política publicada no DNS que protege seu domínio contra spoofing e phishing, aplicando a alinhamento de domínio e permitindo visibilidade por meio de relatórios.
O DMARC é um protocolo de autenticação?
Não. DMARC não é autenticação em si—ele depende de SPF e DKIM para autenticar e usa políticas + relatórios para controlar como os servidores de recebimento lidam com falhas.
O que o DMARC verifica?
Ele verifica:
Autenticação SPF + alinhamento
Autenticação DKIM + alinhamento
Um remetente precisa apenas de um desses para que o DMARC seja bem-sucedido.
O que é "alinhamento de domínio"?
É o requisito de que o domínio visível do Remetente corresponda (estrito) ou compartilhe o mesmo domínio organizacional (relaxado) com o domínio do SPF Return-Path ou com o domínio da assinatura DKIM.
Por que o DMARC melhora a entregabilidade?
Porque os provedores de caixas de entrada confiam mais em domínios autenticados e alinhados. O DMARC previne que mensagens falsificadas erodam sua reputação e melhora a colocação na caixa de entrada para e-mails legítimos.
Qual é a diferença entre relatórios DMARC agregados e forenses?
Relatórios agregados (RUA): Resumos XML dos resultados de autenticação em todo o tráfego.
Relatórios forenses (RUF): Amostras individuais de mensagens falhadas para uma análise mais profunda.
Quais caixas de correio eu preciso antes de publicar o DMARC?
Você deve criar dois endereços, como:
agg_reports@yourdomain.com (RUA)
afrf_reports@yourdomain.com (RUF)
Isso mantém os fluxos de relatórios separados e mais fáceis de analisar.
Qual política DMARC eu devo começar?
Comece sempre com p=none. Ele monitora a atividade de autenticação sem afetar a entrega, permitindo que você identifique problemas de alinhamento e tentativas de spoofing com segurança.
Quais são as políticas DMARC disponíveis?
nenhum: monitorar apenas
quarentena: enviar mensagens com falha para o spam
rejeitar: bloquear mensagens com falha completamente
Onde eu publico um registro DMARC?
No seu DNS em:
_dmarc.yourdomain.com
Deve ser um registro TXT especificando sua política, versão e pontos finais de relatório.
Como é que um registro DMARC básico se parece?
Exemplo:
v=DMARC1; p=none; rua=mailto:agg_reports@yourdomain.com; ruf=mailto:afrf_reports@yourdomain.com; pct=100
O que acontece se o DMARC falhar?
O servidor de recebimento aplica a política solicitada (nenhuma, quarentena, rejeitar), embora o tratamento final seja, em última análise, responsabilidade do provedor. Uma política rigorosa pode reduzir significativamente as tentativas de phishing usando seu domínio.
Neste post, vamos te contar tudo o que você precisa saber sobre como utilizar o DMARC para proteger sua reputação de e-mail e fornecer dicas sobre como configurá-lo para seus domínios.
Neste post, vamos te contar tudo o que você precisa saber sobre como utilizar o DMARC para proteger sua reputação de e-mail e fornecer dicas sobre como configurá-lo para seus domínios.
Neste post, vamos te contar tudo o que você precisa saber sobre como utilizar o DMARC para proteger sua reputação de e-mail e fornecer dicas sobre como configurá-lo para seus domínios.
Uma Ferramenta Eficaz para Combater Correspondências Fraudulentas
Freqüentemente mencionado na mesma frase que os protocolos de autenticação de email SPF e DKIM, o DMARC, ou Autenticação, Relatório e Conformidade de Mensagens Baseadas em Domínio, não é em si um protocolo de autenticação. Em vez disso, o propósito do DMARC é nos permitir, os proprietários de domínios, proteger nossa reputação de email ao:
Anunciar práticas de autenticação de email,
Solicitar tratamento para emails que falham nas verificações de autenticação, e
Solicitar relatórios sobre emails que afirmam ser do seu domínio.
O DMARC pode ser uma ferramenta eficaz para usarmos na nossa luta contra emails fraudulentos que visam o nosso nome de domínio (por exemplo, phishing e spoofing), e que pode promover maior confiança entre nossos recipientes em relação aos nossos emails. Para organizações que exigem criptografia de ponta a ponta além da autenticação, implementar S/MIME com métodos eficientes de coleta de chaves públicas de destinatários oferece camadas adicionais de segurança. Essa maior confiança deve, por sua vez, levar a um maior engajamento com nossos emails, e emails que são abertos e geram cliques impulsionam vendas e maior ROI para nossas campanhas de email.
Além de proteger nosso domínio, prevemos que implementar o DMARC agora será uma excelente maneira de “preparar nosso domínio para o futuro”. Aqui na Bird, acreditamos que à medida que a indústria avança para o IPv6, é quase certo que migrará de um modelo de reputação baseado em IP para um modelo de reputação baseado em domínio. A reputação baseada em domínio exigirá autenticação baseada em domínio, e o DMARC, em conjunto com DKIM e SPF, ajudará os domínios a estabelecer uma reputação baseada em domínio muito antes de ser absolutamente necessário.
Neste post, vamos te contar tudo que você precisa saber sobre como usar o DMARC para proteger sua reputação de email e te dar dicas de como configurá-lo para seus domínios.
Freqüentemente mencionado na mesma frase que os protocolos de autenticação de email SPF e DKIM, o DMARC, ou Autenticação, Relatório e Conformidade de Mensagens Baseadas em Domínio, não é em si um protocolo de autenticação. Em vez disso, o propósito do DMARC é nos permitir, os proprietários de domínios, proteger nossa reputação de email ao:
Anunciar práticas de autenticação de email,
Solicitar tratamento para emails que falham nas verificações de autenticação, e
Solicitar relatórios sobre emails que afirmam ser do seu domínio.
O DMARC pode ser uma ferramenta eficaz para usarmos na nossa luta contra emails fraudulentos que visam o nosso nome de domínio (por exemplo, phishing e spoofing), e que pode promover maior confiança entre nossos recipientes em relação aos nossos emails. Para organizações que exigem criptografia de ponta a ponta além da autenticação, implementar S/MIME com métodos eficientes de coleta de chaves públicas de destinatários oferece camadas adicionais de segurança. Essa maior confiança deve, por sua vez, levar a um maior engajamento com nossos emails, e emails que são abertos e geram cliques impulsionam vendas e maior ROI para nossas campanhas de email.
Além de proteger nosso domínio, prevemos que implementar o DMARC agora será uma excelente maneira de “preparar nosso domínio para o futuro”. Aqui na Bird, acreditamos que à medida que a indústria avança para o IPv6, é quase certo que migrará de um modelo de reputação baseado em IP para um modelo de reputação baseado em domínio. A reputação baseada em domínio exigirá autenticação baseada em domínio, e o DMARC, em conjunto com DKIM e SPF, ajudará os domínios a estabelecer uma reputação baseada em domínio muito antes de ser absolutamente necessário.
Neste post, vamos te contar tudo que você precisa saber sobre como usar o DMARC para proteger sua reputação de email e te dar dicas de como configurá-lo para seus domínios.
Freqüentemente mencionado na mesma frase que os protocolos de autenticação de email SPF e DKIM, o DMARC, ou Autenticação, Relatório e Conformidade de Mensagens Baseadas em Domínio, não é em si um protocolo de autenticação. Em vez disso, o propósito do DMARC é nos permitir, os proprietários de domínios, proteger nossa reputação de email ao:
Anunciar práticas de autenticação de email,
Solicitar tratamento para emails que falham nas verificações de autenticação, e
Solicitar relatórios sobre emails que afirmam ser do seu domínio.
O DMARC pode ser uma ferramenta eficaz para usarmos na nossa luta contra emails fraudulentos que visam o nosso nome de domínio (por exemplo, phishing e spoofing), e que pode promover maior confiança entre nossos recipientes em relação aos nossos emails. Para organizações que exigem criptografia de ponta a ponta além da autenticação, implementar S/MIME com métodos eficientes de coleta de chaves públicas de destinatários oferece camadas adicionais de segurança. Essa maior confiança deve, por sua vez, levar a um maior engajamento com nossos emails, e emails que são abertos e geram cliques impulsionam vendas e maior ROI para nossas campanhas de email.
Além de proteger nosso domínio, prevemos que implementar o DMARC agora será uma excelente maneira de “preparar nosso domínio para o futuro”. Aqui na Bird, acreditamos que à medida que a indústria avança para o IPv6, é quase certo que migrará de um modelo de reputação baseado em IP para um modelo de reputação baseado em domínio. A reputação baseada em domínio exigirá autenticação baseada em domínio, e o DMARC, em conjunto com DKIM e SPF, ajudará os domínios a estabelecer uma reputação baseada em domínio muito antes de ser absolutamente necessário.
Neste post, vamos te contar tudo que você precisa saber sobre como usar o DMARC para proteger sua reputação de email e te dar dicas de como configurá-lo para seus domínios.
Termos a Conhecer
Antes de começarmos a configurar o DMARC para o seu domínio, queremos ter certeza de que estamos falando a mesma língua. Vamos começar definindo alguns termos que usaremos ao longo deste documento.
Domínio RFC5322.From
O domínio RFC5322.From é a parte do domínio do endereço de e-mail que geralmente é vista por um destinatário de nosso e-mail quando está sendo lido. No seguinte exemplo, o domínio RFC5322.From é “joesbaitshop.com”
From: Joe’s Bait and Tackle <sales@joesbaitshop.com>
Domínio DKIM d=
DKIM é um protocolo de autenticação que permite que um domínio assuma a responsabilidade por uma mensagem de uma maneira que pode ser validada pelo receptor da mensagem; isso é feito através do uso de assinaturas criptográficas inseridas nos cabeçalhos da mensagem enquanto ela deixa seu ponto de origem. Essas assinaturas são efetivamente instantâneas do que a mensagem parecia naquele momento, e o receptor pode usar essas instantâneas para ver se a mensagem chegou inalterada ao seu destino. O processo de produzir e inserir essas instantâneas é chamado de assinatura DKIM, e o domínio que assume a responsabilidade pela mensagem ao assiná-la insere seu nome no cabeçalho em uma tag de chave-valor como “d=signingDomain”, e assim é referida como o domínio DKIM d=.
Domínio Return-Path
O domínio Return-Path, às vezes chamado de domínio RFC5321.From ou domínio Mail From, é o domínio para o qual as devoluções são direcionadas; é também o domínio no qual as verificações de SPF são feitas durante a transação de e-mail. Esse domínio geralmente não é visto pelo destinatário, a menos que o destinatário seja esperto o suficiente para olhar todos os cabeçalhos de uma determinada mensagem.
Por padrão, todo e-mail enviado através do bird.com terá birdmail.com como seu domínio Return-Path, como no seguinte exemplo:
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
No entanto, para fazer o DMARC funcionar para o seu domínio, você vai querer aproveitar um domínio de devolução personalizado, um que terminará no mesmo domínio que o seu domínio de envio, por exemplo, bounces.seudominio.com ao usar seudominio.com como seu domínio de envio.
Domínio Organizacional
O termo “Domínio Organizacional” se refere ao domínio que foi submetido a um registrador para criar a presença do domínio na internet. Para o Bird, nossos domínios organizacionais são bird.com e birdmail.com.
Alinhamento de Domínio
O último termo a entender sobre o DMARC é “Alinhamento de Domínio”, e ele vem em duas variantes: “relaxado” e “estrito.”
Alinhamento de Domínio Relaxado
Qualquer dois domínios são considerados ter alinhamento de domínio relaxado quando seus Domínios Organizacionais são iguais. Por exemplo, a.mail.bird.com e b.foo.bird.com têm alinhamento de domínio relaxado devido ao seu domínio organizacional comum, bird.com.
Alinhamento de Domínio Estrito
Dois domínios são considerados estar em alinhamento de domínio estrito se e somente se forem idênticos. Assim, foo.bird.com e foo.bird.com estão em alinhamento estrito, já que os dois domínios são idênticos. Por outro lado, foo.bird.com e bar.foo.bird.com estão apenas em alinhamento relaxado.
Requisitos de Alinhamento de Domínio DMARC
Para que as verificações de validação DMARC passem, o DMARC exige que haja alinhamento de domínio da seguinte forma:
Para SPF, o domínio RFC5322.From e o domínio Return-Path devem estar em alinhamento
Para DKIM, o domínio RFC5322.From e o domínio DKIM d= devem estar em alinhamento
O alinhamento pode ser relaxado ou estrito, com base na política publicada do domínio de envio.
Antes de começarmos a configurar o DMARC para o seu domínio, queremos ter certeza de que estamos falando a mesma língua. Vamos começar definindo alguns termos que usaremos ao longo deste documento.
Domínio RFC5322.From
O domínio RFC5322.From é a parte do domínio do endereço de e-mail que geralmente é vista por um destinatário de nosso e-mail quando está sendo lido. No seguinte exemplo, o domínio RFC5322.From é “joesbaitshop.com”
From: Joe’s Bait and Tackle <sales@joesbaitshop.com>
Domínio DKIM d=
DKIM é um protocolo de autenticação que permite que um domínio assuma a responsabilidade por uma mensagem de uma maneira que pode ser validada pelo receptor da mensagem; isso é feito através do uso de assinaturas criptográficas inseridas nos cabeçalhos da mensagem enquanto ela deixa seu ponto de origem. Essas assinaturas são efetivamente instantâneas do que a mensagem parecia naquele momento, e o receptor pode usar essas instantâneas para ver se a mensagem chegou inalterada ao seu destino. O processo de produzir e inserir essas instantâneas é chamado de assinatura DKIM, e o domínio que assume a responsabilidade pela mensagem ao assiná-la insere seu nome no cabeçalho em uma tag de chave-valor como “d=signingDomain”, e assim é referida como o domínio DKIM d=.
Domínio Return-Path
O domínio Return-Path, às vezes chamado de domínio RFC5321.From ou domínio Mail From, é o domínio para o qual as devoluções são direcionadas; é também o domínio no qual as verificações de SPF são feitas durante a transação de e-mail. Esse domínio geralmente não é visto pelo destinatário, a menos que o destinatário seja esperto o suficiente para olhar todos os cabeçalhos de uma determinada mensagem.
Por padrão, todo e-mail enviado através do bird.com terá birdmail.com como seu domínio Return-Path, como no seguinte exemplo:
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
No entanto, para fazer o DMARC funcionar para o seu domínio, você vai querer aproveitar um domínio de devolução personalizado, um que terminará no mesmo domínio que o seu domínio de envio, por exemplo, bounces.seudominio.com ao usar seudominio.com como seu domínio de envio.
Domínio Organizacional
O termo “Domínio Organizacional” se refere ao domínio que foi submetido a um registrador para criar a presença do domínio na internet. Para o Bird, nossos domínios organizacionais são bird.com e birdmail.com.
Alinhamento de Domínio
O último termo a entender sobre o DMARC é “Alinhamento de Domínio”, e ele vem em duas variantes: “relaxado” e “estrito.”
Alinhamento de Domínio Relaxado
Qualquer dois domínios são considerados ter alinhamento de domínio relaxado quando seus Domínios Organizacionais são iguais. Por exemplo, a.mail.bird.com e b.foo.bird.com têm alinhamento de domínio relaxado devido ao seu domínio organizacional comum, bird.com.
Alinhamento de Domínio Estrito
Dois domínios são considerados estar em alinhamento de domínio estrito se e somente se forem idênticos. Assim, foo.bird.com e foo.bird.com estão em alinhamento estrito, já que os dois domínios são idênticos. Por outro lado, foo.bird.com e bar.foo.bird.com estão apenas em alinhamento relaxado.
Requisitos de Alinhamento de Domínio DMARC
Para que as verificações de validação DMARC passem, o DMARC exige que haja alinhamento de domínio da seguinte forma:
Para SPF, o domínio RFC5322.From e o domínio Return-Path devem estar em alinhamento
Para DKIM, o domínio RFC5322.From e o domínio DKIM d= devem estar em alinhamento
O alinhamento pode ser relaxado ou estrito, com base na política publicada do domínio de envio.
Antes de começarmos a configurar o DMARC para o seu domínio, queremos ter certeza de que estamos falando a mesma língua. Vamos começar definindo alguns termos que usaremos ao longo deste documento.
Domínio RFC5322.From
O domínio RFC5322.From é a parte do domínio do endereço de e-mail que geralmente é vista por um destinatário de nosso e-mail quando está sendo lido. No seguinte exemplo, o domínio RFC5322.From é “joesbaitshop.com”
From: Joe’s Bait and Tackle <sales@joesbaitshop.com>
Domínio DKIM d=
DKIM é um protocolo de autenticação que permite que um domínio assuma a responsabilidade por uma mensagem de uma maneira que pode ser validada pelo receptor da mensagem; isso é feito através do uso de assinaturas criptográficas inseridas nos cabeçalhos da mensagem enquanto ela deixa seu ponto de origem. Essas assinaturas são efetivamente instantâneas do que a mensagem parecia naquele momento, e o receptor pode usar essas instantâneas para ver se a mensagem chegou inalterada ao seu destino. O processo de produzir e inserir essas instantâneas é chamado de assinatura DKIM, e o domínio que assume a responsabilidade pela mensagem ao assiná-la insere seu nome no cabeçalho em uma tag de chave-valor como “d=signingDomain”, e assim é referida como o domínio DKIM d=.
Domínio Return-Path
O domínio Return-Path, às vezes chamado de domínio RFC5321.From ou domínio Mail From, é o domínio para o qual as devoluções são direcionadas; é também o domínio no qual as verificações de SPF são feitas durante a transação de e-mail. Esse domínio geralmente não é visto pelo destinatário, a menos que o destinatário seja esperto o suficiente para olhar todos os cabeçalhos de uma determinada mensagem.
Por padrão, todo e-mail enviado através do bird.com terá birdmail.com como seu domínio Return-Path, como no seguinte exemplo:
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
No entanto, para fazer o DMARC funcionar para o seu domínio, você vai querer aproveitar um domínio de devolução personalizado, um que terminará no mesmo domínio que o seu domínio de envio, por exemplo, bounces.seudominio.com ao usar seudominio.com como seu domínio de envio.
Domínio Organizacional
O termo “Domínio Organizacional” se refere ao domínio que foi submetido a um registrador para criar a presença do domínio na internet. Para o Bird, nossos domínios organizacionais são bird.com e birdmail.com.
Alinhamento de Domínio
O último termo a entender sobre o DMARC é “Alinhamento de Domínio”, e ele vem em duas variantes: “relaxado” e “estrito.”
Alinhamento de Domínio Relaxado
Qualquer dois domínios são considerados ter alinhamento de domínio relaxado quando seus Domínios Organizacionais são iguais. Por exemplo, a.mail.bird.com e b.foo.bird.com têm alinhamento de domínio relaxado devido ao seu domínio organizacional comum, bird.com.
Alinhamento de Domínio Estrito
Dois domínios são considerados estar em alinhamento de domínio estrito se e somente se forem idênticos. Assim, foo.bird.com e foo.bird.com estão em alinhamento estrito, já que os dois domínios são idênticos. Por outro lado, foo.bird.com e bar.foo.bird.com estão apenas em alinhamento relaxado.
Requisitos de Alinhamento de Domínio DMARC
Para que as verificações de validação DMARC passem, o DMARC exige que haja alinhamento de domínio da seguinte forma:
Para SPF, o domínio RFC5322.From e o domínio Return-Path devem estar em alinhamento
Para DKIM, o domínio RFC5322.From e o domínio DKIM d= devem estar em alinhamento
O alinhamento pode ser relaxado ou estrito, com base na política publicada do domínio de envio.
Como o DMARC Funciona para Proteger Sua Reputação de Email
Quando falamos de um provedor de caixa de entrada ou outro domínio "verificando DMARC", ou "validando DMARC", ou "aplicando a política DMARC", o que queremos dizer é que o domínio que recebe uma mensagem está executando os seguintes passos:
Identificar o domínio RFC5322.From da mensagem
Procurar a política DMARC desse domínio no DNS
Realizar a validação da assinatura DKIM
Realizar a validação SPF
Verificar o alinhamento do domínio
Aplicar a política DMARC
Para que uma mensagem passe na validação DMARC, a mensagem deve passar por apenas uma das duas verificações de autenticação e alinhamento. Portanto, uma mensagem passará na validação DMARC se qualquer uma das seguintes condições for verdadeira:
A mensagem passa nas verificações SPF e o domínio RFC5322.From e o domínio de Return-Path estão em alinhamento, ou
A mensagem passa na validação DKIM e o domínio RFC5322.From e o domínio DKIM d= estão em alinhamento, ou
Ambas as acima são verdadeiras
Visão Geral dos Caminhos de Validação DMARC
Caminho de autenticação | Domínios comparados | Alinhamento necessário | Condição de aprovação DMARC |
|---|---|---|---|
SPF | RFC5322.From ↔ Return-Path | Relaxado ou estrito | SPF passa e os domínios estão alinhados |
DKIM | RFC5322.From ↔ DKIM d= | Relaxado ou estrito | DKIM passa e os domínios estão alinhados |
SPF + DKIM | Ambos acima | Qualquer um alinhado | Uma ou ambas as verificações de alinhamento passam |
Quando falamos de um provedor de caixa de entrada ou outro domínio "verificando DMARC", ou "validando DMARC", ou "aplicando a política DMARC", o que queremos dizer é que o domínio que recebe uma mensagem está executando os seguintes passos:
Identificar o domínio RFC5322.From da mensagem
Procurar a política DMARC desse domínio no DNS
Realizar a validação da assinatura DKIM
Realizar a validação SPF
Verificar o alinhamento do domínio
Aplicar a política DMARC
Para que uma mensagem passe na validação DMARC, a mensagem deve passar por apenas uma das duas verificações de autenticação e alinhamento. Portanto, uma mensagem passará na validação DMARC se qualquer uma das seguintes condições for verdadeira:
A mensagem passa nas verificações SPF e o domínio RFC5322.From e o domínio de Return-Path estão em alinhamento, ou
A mensagem passa na validação DKIM e o domínio RFC5322.From e o domínio DKIM d= estão em alinhamento, ou
Ambas as acima são verdadeiras
Visão Geral dos Caminhos de Validação DMARC
Caminho de autenticação | Domínios comparados | Alinhamento necessário | Condição de aprovação DMARC |
|---|---|---|---|
SPF | RFC5322.From ↔ Return-Path | Relaxado ou estrito | SPF passa e os domínios estão alinhados |
DKIM | RFC5322.From ↔ DKIM d= | Relaxado ou estrito | DKIM passa e os domínios estão alinhados |
SPF + DKIM | Ambos acima | Qualquer um alinhado | Uma ou ambas as verificações de alinhamento passam |
Quando falamos de um provedor de caixa de entrada ou outro domínio "verificando DMARC", ou "validando DMARC", ou "aplicando a política DMARC", o que queremos dizer é que o domínio que recebe uma mensagem está executando os seguintes passos:
Identificar o domínio RFC5322.From da mensagem
Procurar a política DMARC desse domínio no DNS
Realizar a validação da assinatura DKIM
Realizar a validação SPF
Verificar o alinhamento do domínio
Aplicar a política DMARC
Para que uma mensagem passe na validação DMARC, a mensagem deve passar por apenas uma das duas verificações de autenticação e alinhamento. Portanto, uma mensagem passará na validação DMARC se qualquer uma das seguintes condições for verdadeira:
A mensagem passa nas verificações SPF e o domínio RFC5322.From e o domínio de Return-Path estão em alinhamento, ou
A mensagem passa na validação DKIM e o domínio RFC5322.From e o domínio DKIM d= estão em alinhamento, ou
Ambas as acima são verdadeiras
Visão Geral dos Caminhos de Validação DMARC
Caminho de autenticação | Domínios comparados | Alinhamento necessário | Condição de aprovação DMARC |
|---|---|---|---|
SPF | RFC5322.From ↔ Return-Path | Relaxado ou estrito | SPF passa e os domínios estão alinhados |
DKIM | RFC5322.From ↔ DKIM d= | Relaxado ou estrito | DKIM passa e os domínios estão alinhados |
SPF + DKIM | Ambos acima | Qualquer um alinhado | Uma ou ambas as verificações de alinhamento passam |
Fazendo o DMARC Funcionar para Seu Domínio
Agora que explicamos a mecânica do DMARC, vamos falar sobre como fazer o DMARC funcionar para nós, o que envolve os seguintes três passos:
Fazendo preparativos para receber relatórios de DMARC
Decidindo sobre qual política de DMARC usar para seu domínio
Publicando seu registro DMARC
Cobriremos cada um desses em detalhes abaixo, mas vamos te dizer claramente que o passo 1 acima consumirá cerca de 95% do seu tempo de preparação.
Agora que explicamos a mecânica do DMARC, vamos falar sobre como fazer o DMARC funcionar para nós, o que envolve os seguintes três passos:
Fazendo preparativos para receber relatórios de DMARC
Decidindo sobre qual política de DMARC usar para seu domínio
Publicando seu registro DMARC
Cobriremos cada um desses em detalhes abaixo, mas vamos te dizer claramente que o passo 1 acima consumirá cerca de 95% do seu tempo de preparação.
Agora que explicamos a mecânica do DMARC, vamos falar sobre como fazer o DMARC funcionar para nós, o que envolve os seguintes três passos:
Fazendo preparativos para receber relatórios de DMARC
Decidindo sobre qual política de DMARC usar para seu domínio
Publicando seu registro DMARC
Cobriremos cada um desses em detalhes abaixo, mas vamos te dizer claramente que o passo 1 acima consumirá cerca de 95% do seu tempo de preparação.
Preparando para Receber Relatórios DMARC
Qualquer domínio que publique uma política DMARC deve primeiro se preparar para receber relatórios sobre seu domínio. Esses relatórios serão gerados por qualquer domínio que realiza a validação DMARC e vê e-mails que afirmam ser de nosso domínio, e serão enviados para nós pelo menos uma vez ao dia. Os relatórios virão em dois formatos:
Relatórios agregados, que são documentos XML mostrando dados estatísticos de quanto e-mail foi visto pelo reporter de cada fonte, quais foram os resultados de autenticação e como as mensagens foram tratadas pelo reporter. Relatórios agregados são projetados para serem analisados por máquinas, com seus dados armazenados em algum lugar para permitir análise geral de tráfego, auditoria dos fluxos de mensagens de nosso domínio e talvez identificação de tendências em fontes de email não autenticadas, potencialmente fraudulentas.
Relatórios forenses, que são cópias individuais de mensagens que falharam na autenticação, cada uma enclausurada em uma mensagem de email completa usando um formato chamado AFRF. Os relatórios forenses devem conter cabeçalhos e corpos de mensagem completos, mas muitos reporters removem ou ocultam algumas informações devido a preocupações de privacidade. No entanto, o relatório forense ainda pode ser útil tanto para solucionar problemas de autenticação de nosso domínio quanto para identificar, a partir de URIs nos corpos das mensagens, domínios e sites maliciosos usados para fraudar os clientes do proprietário de nosso domínio.
A preparação para receber esses relatórios envolve primeiro a criação de duas caixas de correio em nosso domínio para lidar com esses relatórios, como agg_reports@ourdomain.com e afrf_reports@ourdomain.com. Observe que esses nomes de caixa de correio são completamente arbitrários, e não há requisitos para a nomeação da parte local da caixa de correio; estamos livres para escolher quaisquer nomes que desejamos, mas mantenha as duas separadas para um processamento mais fácil.
Uma vez que os nomes das caixas de correio sejam selecionados e criados em nosso domínio, a próxima coisa a fazer aqui é colocar ferramentas em funcionamento para ler essas caixas de correio e fazer uso dos dados, especialmente dos relatórios de dados agregados, que novamente são projetados para serem analisados por máquinas, em vez de lidos por um humano. Os relatórios forenses, por outro lado, podem ser gerenciáveis simplesmente lendo-os nós mesmos, mas nossa capacidade de fazer isso dependerá tanto da compreensão do nosso cliente de e-mail sobre como exibir mensagens no formato AFRF quanto do volume de relatórios que recebemos.
Embora seja possível para nós escrevermos nossas próprias ferramentas para processar relatórios DMARC, até que Bird forneça tais serviços para os clientes da bird.com (algo que estamos considerando, mas ainda não prometendo), recomendamos que façamos uso de ferramentas que já estão disponíveis para a tarefa.
Qualquer domínio que publique uma política DMARC deve primeiro se preparar para receber relatórios sobre seu domínio. Esses relatórios serão gerados por qualquer domínio que realiza a validação DMARC e vê e-mails que afirmam ser de nosso domínio, e serão enviados para nós pelo menos uma vez ao dia. Os relatórios virão em dois formatos:
Relatórios agregados, que são documentos XML mostrando dados estatísticos de quanto e-mail foi visto pelo reporter de cada fonte, quais foram os resultados de autenticação e como as mensagens foram tratadas pelo reporter. Relatórios agregados são projetados para serem analisados por máquinas, com seus dados armazenados em algum lugar para permitir análise geral de tráfego, auditoria dos fluxos de mensagens de nosso domínio e talvez identificação de tendências em fontes de email não autenticadas, potencialmente fraudulentas.
Relatórios forenses, que são cópias individuais de mensagens que falharam na autenticação, cada uma enclausurada em uma mensagem de email completa usando um formato chamado AFRF. Os relatórios forenses devem conter cabeçalhos e corpos de mensagem completos, mas muitos reporters removem ou ocultam algumas informações devido a preocupações de privacidade. No entanto, o relatório forense ainda pode ser útil tanto para solucionar problemas de autenticação de nosso domínio quanto para identificar, a partir de URIs nos corpos das mensagens, domínios e sites maliciosos usados para fraudar os clientes do proprietário de nosso domínio.
A preparação para receber esses relatórios envolve primeiro a criação de duas caixas de correio em nosso domínio para lidar com esses relatórios, como agg_reports@ourdomain.com e afrf_reports@ourdomain.com. Observe que esses nomes de caixa de correio são completamente arbitrários, e não há requisitos para a nomeação da parte local da caixa de correio; estamos livres para escolher quaisquer nomes que desejamos, mas mantenha as duas separadas para um processamento mais fácil.
Uma vez que os nomes das caixas de correio sejam selecionados e criados em nosso domínio, a próxima coisa a fazer aqui é colocar ferramentas em funcionamento para ler essas caixas de correio e fazer uso dos dados, especialmente dos relatórios de dados agregados, que novamente são projetados para serem analisados por máquinas, em vez de lidos por um humano. Os relatórios forenses, por outro lado, podem ser gerenciáveis simplesmente lendo-os nós mesmos, mas nossa capacidade de fazer isso dependerá tanto da compreensão do nosso cliente de e-mail sobre como exibir mensagens no formato AFRF quanto do volume de relatórios que recebemos.
Embora seja possível para nós escrevermos nossas próprias ferramentas para processar relatórios DMARC, até que Bird forneça tais serviços para os clientes da bird.com (algo que estamos considerando, mas ainda não prometendo), recomendamos que façamos uso de ferramentas que já estão disponíveis para a tarefa.
Qualquer domínio que publique uma política DMARC deve primeiro se preparar para receber relatórios sobre seu domínio. Esses relatórios serão gerados por qualquer domínio que realiza a validação DMARC e vê e-mails que afirmam ser de nosso domínio, e serão enviados para nós pelo menos uma vez ao dia. Os relatórios virão em dois formatos:
Relatórios agregados, que são documentos XML mostrando dados estatísticos de quanto e-mail foi visto pelo reporter de cada fonte, quais foram os resultados de autenticação e como as mensagens foram tratadas pelo reporter. Relatórios agregados são projetados para serem analisados por máquinas, com seus dados armazenados em algum lugar para permitir análise geral de tráfego, auditoria dos fluxos de mensagens de nosso domínio e talvez identificação de tendências em fontes de email não autenticadas, potencialmente fraudulentas.
Relatórios forenses, que são cópias individuais de mensagens que falharam na autenticação, cada uma enclausurada em uma mensagem de email completa usando um formato chamado AFRF. Os relatórios forenses devem conter cabeçalhos e corpos de mensagem completos, mas muitos reporters removem ou ocultam algumas informações devido a preocupações de privacidade. No entanto, o relatório forense ainda pode ser útil tanto para solucionar problemas de autenticação de nosso domínio quanto para identificar, a partir de URIs nos corpos das mensagens, domínios e sites maliciosos usados para fraudar os clientes do proprietário de nosso domínio.
A preparação para receber esses relatórios envolve primeiro a criação de duas caixas de correio em nosso domínio para lidar com esses relatórios, como agg_reports@ourdomain.com e afrf_reports@ourdomain.com. Observe que esses nomes de caixa de correio são completamente arbitrários, e não há requisitos para a nomeação da parte local da caixa de correio; estamos livres para escolher quaisquer nomes que desejamos, mas mantenha as duas separadas para um processamento mais fácil.
Uma vez que os nomes das caixas de correio sejam selecionados e criados em nosso domínio, a próxima coisa a fazer aqui é colocar ferramentas em funcionamento para ler essas caixas de correio e fazer uso dos dados, especialmente dos relatórios de dados agregados, que novamente são projetados para serem analisados por máquinas, em vez de lidos por um humano. Os relatórios forenses, por outro lado, podem ser gerenciáveis simplesmente lendo-os nós mesmos, mas nossa capacidade de fazer isso dependerá tanto da compreensão do nosso cliente de e-mail sobre como exibir mensagens no formato AFRF quanto do volume de relatórios que recebemos.
Embora seja possível para nós escrevermos nossas próprias ferramentas para processar relatórios DMARC, até que Bird forneça tais serviços para os clientes da bird.com (algo que estamos considerando, mas ainda não prometendo), recomendamos que façamos uso de ferramentas que já estão disponíveis para a tarefa.
Qual Política DMARC Usar
A especificação DMARC fornece três opções para os proprietários de domínio especificarem seu tratamento preferido de e-mails que falham nas verificações de validação DMARC. Elas são:
nenhum, significando tratar o e-mail da mesma forma que seria tratado independentemente das verificações de validação DMARC
quarentena, significando aceitar o e-mail, mas colocá-lo em algum lugar diferente da Caixa de Entrada do destinatário (tipicamente na pasta de spam)
rejeitar, significando rejeitar a mensagem de imediato
É importante ter em mente que o proprietário do domínio pode apenas solicitar tal tratamento em seu registro DMARC; cabe ao destinatário da mensagem decidir se irá ou não honrar a política solicitada. Alguns farão isso, enquanto outros podem ser um pouco mais flexíveis na aplicação da política, como apenas colocar e-mails na pasta de spam quando a política do domínio é rejeitar.
Recomendamos a todos os nossos clientes que comecem com uma política de nenhum, simplesmente para ficar seguro. Embora tenhamos confiança em nossa capacidade de autenticar corretamente seu e-mail através da assinatura DKIM, ainda é melhor dedicar algum tempo para examinar os relatórios sobre seu domínio antes de ser mais agressivo com sua política DMARC.
A especificação DMARC fornece três opções para os proprietários de domínio especificarem seu tratamento preferido de e-mails que falham nas verificações de validação DMARC. Elas são:
nenhum, significando tratar o e-mail da mesma forma que seria tratado independentemente das verificações de validação DMARC
quarentena, significando aceitar o e-mail, mas colocá-lo em algum lugar diferente da Caixa de Entrada do destinatário (tipicamente na pasta de spam)
rejeitar, significando rejeitar a mensagem de imediato
É importante ter em mente que o proprietário do domínio pode apenas solicitar tal tratamento em seu registro DMARC; cabe ao destinatário da mensagem decidir se irá ou não honrar a política solicitada. Alguns farão isso, enquanto outros podem ser um pouco mais flexíveis na aplicação da política, como apenas colocar e-mails na pasta de spam quando a política do domínio é rejeitar.
Recomendamos a todos os nossos clientes que comecem com uma política de nenhum, simplesmente para ficar seguro. Embora tenhamos confiança em nossa capacidade de autenticar corretamente seu e-mail através da assinatura DKIM, ainda é melhor dedicar algum tempo para examinar os relatórios sobre seu domínio antes de ser mais agressivo com sua política DMARC.
A especificação DMARC fornece três opções para os proprietários de domínio especificarem seu tratamento preferido de e-mails que falham nas verificações de validação DMARC. Elas são:
nenhum, significando tratar o e-mail da mesma forma que seria tratado independentemente das verificações de validação DMARC
quarentena, significando aceitar o e-mail, mas colocá-lo em algum lugar diferente da Caixa de Entrada do destinatário (tipicamente na pasta de spam)
rejeitar, significando rejeitar a mensagem de imediato
É importante ter em mente que o proprietário do domínio pode apenas solicitar tal tratamento em seu registro DMARC; cabe ao destinatário da mensagem decidir se irá ou não honrar a política solicitada. Alguns farão isso, enquanto outros podem ser um pouco mais flexíveis na aplicação da política, como apenas colocar e-mails na pasta de spam quando a política do domínio é rejeitar.
Recomendamos a todos os nossos clientes que comecem com uma política de nenhum, simplesmente para ficar seguro. Embora tenhamos confiança em nossa capacidade de autenticar corretamente seu e-mail através da assinatura DKIM, ainda é melhor dedicar algum tempo para examinar os relatórios sobre seu domínio antes de ser mais agressivo com sua política DMARC.
Publicando Sua Política DMARC
A política DMARC de um domínio é anunciada publicando um registro TXT DNS em um local específico no namespace DNS, a saber, “_dmarc.domainname.tld” (note o sublinhado no início). Um registro básico de política DMARC para o nosso domínio de exemplo anterior, joesbaitshop.com, pode parecer algo assim:
_dmarc.joesbaitship.com. IN TXT "v=DMARC1; p=none; rua=mailto:agg_reports@joesbait.com; ruf=mailto:afrf_reports@joesbait.com; pct=100"
Desmembrando este registro, temos:
v=DMARC1 especifica a versão DMARC (1 é a única escolha no momento)
p=none especifica o tratamento preferido, ou política DMARC
rua=mailto:agg_reports@joesbait.com é a caixa de correio para a qual os relatórios agregados devem ser enviados
ruf=mailto:afrf_reports@joesbait.com é a caixa de correio para a qual os relatórios forenses devem ser enviados
pct=100 é a porcentagem de e-mails à qual o proprietário do domínio gostaria de aplicar sua política. Domínios que estão começando com DMARC, especialmente aqueles que provavelmente gerarão um alto volume de relatórios, podem querer começar com um número muito mais baixo aqui para ver como seus processos de manuseio de relatórios se sustentam à carga.
Existem outras opções de configuração disponíveis para um proprietário de domínio usar em seu registro de política DMARC também, mas as dicas que fornecemos devem ser um bom começo.
A política DMARC de um domínio é anunciada publicando um registro TXT DNS em um local específico no namespace DNS, a saber, “_dmarc.domainname.tld” (note o sublinhado no início). Um registro básico de política DMARC para o nosso domínio de exemplo anterior, joesbaitshop.com, pode parecer algo assim:
_dmarc.joesbaitship.com. IN TXT "v=DMARC1; p=none; rua=mailto:agg_reports@joesbait.com; ruf=mailto:afrf_reports@joesbait.com; pct=100"
Desmembrando este registro, temos:
v=DMARC1 especifica a versão DMARC (1 é a única escolha no momento)
p=none especifica o tratamento preferido, ou política DMARC
rua=mailto:agg_reports@joesbait.com é a caixa de correio para a qual os relatórios agregados devem ser enviados
ruf=mailto:afrf_reports@joesbait.com é a caixa de correio para a qual os relatórios forenses devem ser enviados
pct=100 é a porcentagem de e-mails à qual o proprietário do domínio gostaria de aplicar sua política. Domínios que estão começando com DMARC, especialmente aqueles que provavelmente gerarão um alto volume de relatórios, podem querer começar com um número muito mais baixo aqui para ver como seus processos de manuseio de relatórios se sustentam à carga.
Existem outras opções de configuração disponíveis para um proprietário de domínio usar em seu registro de política DMARC também, mas as dicas que fornecemos devem ser um bom começo.
A política DMARC de um domínio é anunciada publicando um registro TXT DNS em um local específico no namespace DNS, a saber, “_dmarc.domainname.tld” (note o sublinhado no início). Um registro básico de política DMARC para o nosso domínio de exemplo anterior, joesbaitshop.com, pode parecer algo assim:
_dmarc.joesbaitship.com. IN TXT "v=DMARC1; p=none; rua=mailto:agg_reports@joesbait.com; ruf=mailto:afrf_reports@joesbait.com; pct=100"
Desmembrando este registro, temos:
v=DMARC1 especifica a versão DMARC (1 é a única escolha no momento)
p=none especifica o tratamento preferido, ou política DMARC
rua=mailto:agg_reports@joesbait.com é a caixa de correio para a qual os relatórios agregados devem ser enviados
ruf=mailto:afrf_reports@joesbait.com é a caixa de correio para a qual os relatórios forenses devem ser enviados
pct=100 é a porcentagem de e-mails à qual o proprietário do domínio gostaria de aplicar sua política. Domínios que estão começando com DMARC, especialmente aqueles que provavelmente gerarão um alto volume de relatórios, podem querer começar com um número muito mais baixo aqui para ver como seus processos de manuseio de relatórios se sustentam à carga.
Existem outras opções de configuração disponíveis para um proprietário de domínio usar em seu registro de política DMARC também, mas as dicas que fornecemos devem ser um bom começo.
Resumo
Há muito a se analisar nas informações acima! Esperamos que você ache o guia para criar um registro de política DMARC útil. Também esperamos que nossa explicação sobre por que o DMARC é importante ajude a deixar claro por que você deve começar a usar essa ferramenta fundamental para proteger sua reputação de e-mail.
Claro, este não é um documento completo ou autoritário sobre o assunto. Se você quiser se aprofundar mais ou precisar de mais ajuda, um ótimo lugar para começar é a FAQ oficial do DMARC. E, não é necessário dizer que a equipe de suporte do MessageBird está pronta para ajudá-lo a configurar sua conta do MessageBird para DMARC também.
Obrigado por ler—e comece a proteger seus domínios com DMARC hoje!
Há muito a se analisar nas informações acima! Esperamos que você ache o guia para criar um registro de política DMARC útil. Também esperamos que nossa explicação sobre por que o DMARC é importante ajude a deixar claro por que você deve começar a usar essa ferramenta fundamental para proteger sua reputação de e-mail.
Claro, este não é um documento completo ou autoritário sobre o assunto. Se você quiser se aprofundar mais ou precisar de mais ajuda, um ótimo lugar para começar é a FAQ oficial do DMARC. E, não é necessário dizer que a equipe de suporte do MessageBird está pronta para ajudá-lo a configurar sua conta do MessageBird para DMARC também.
Obrigado por ler—e comece a proteger seus domínios com DMARC hoje!
Há muito a se analisar nas informações acima! Esperamos que você ache o guia para criar um registro de política DMARC útil. Também esperamos que nossa explicação sobre por que o DMARC é importante ajude a deixar claro por que você deve começar a usar essa ferramenta fundamental para proteger sua reputação de e-mail.
Claro, este não é um documento completo ou autoritário sobre o assunto. Se você quiser se aprofundar mais ou precisar de mais ajuda, um ótimo lugar para começar é a FAQ oficial do DMARC. E, não é necessário dizer que a equipe de suporte do MessageBird está pronta para ajudá-lo a configurar sua conta do MessageBird para DMARC também.
Obrigado por ler—e comece a proteger seus domínios com DMARC hoje!
