DMARC Reports no Postfix são relatórios XML enviados por provedores receptores (Gmail, Outlook e outros) sobre autenticação SPF/DKIM e a política DMARC aplicada às mensagens do seu domínio. Eles falham com frequência por rua inválido, caixa que rejeita anexos ou desalinhamento SPF/DKIM; para ver e interpretar os reports no servidor Linux, publique o TXT _dmarc, receba os e-mails na caixa configurada e analise os XML descompactados.
- Publique o registro TXT _dmarc com rua (e opcionalmente ruf) apontando para uma caixa válida
- Garanta que o Postfix aceite e entregue mensagens nessa caixa (MX e mailbox locais ou relay)
- Confirme SPF e DKIM alinhados ao domínio de envio antes de confiar nos números
- Descompacte anexos .xml.gz e leia org_name, source_ip, contagens e disposition
- Mantenha p=none até validar o fluxo de monitoramento e só então endureça a política
Pré-requisitos
- Servidor Linux com Postfix instalado e funcionando como MTA de saída (Debian 13, Rocky Linux 10 ou AlmaLinux 10)
- Acesso root ou sudo e permissão para editar zona DNS do domínio
- Caixa de e-mail dedicada para reports (ex.: [email protected]) com espaço e sem filtro agressivo de anexos
- SPF e DKIM já publicados e testados; veja o Guia DKIM, SPF e DMARC: configure e saia do spam
- Ferramentas: dig, gunzip, um editor de texto e, opcionalmente, um parser DMARC open source
- Registro MX correto apontando para o host que receberá os reports
Entenda DMARC Reports no Postfix e o papel do registro DNS
O monitoramento de autenticação de e-mail depende do registro DNS _dmarc, não de um parâmetro exclusivo do main.cf. Quando um receptor processa uma mensagem do seu domínio, ele avalia SPF e DKIM, aplica a política DMARC (none, quarantine ou reject) e, se o registro pedir, envia um relatório agregado (rua) ou forense (ruf) para o endereço indicado. O Postfix apenas entrega o e-mail de saída e, no lado de entrada, precisa aceitar a mensagem de report como qualquer outro correio legítimo.
Um registro típico em modo observação fica assim (substitua seudominio.com.br):
dig +short TXT _dmarc.seudominio.com.br"v=DMARC1; p=none; rua=mailto:[email protected]; fo=1; adkim=r; aspf=r"Com p=none você observa falhas sem bloquear. fo=1 pede report em falha de SPF ou DKIM. adkim e aspf em modo relaxed (r) toleram subdomínios alinhados. Só avance para p=quarantine ou p=reject depois de semanas de reports limpos e de confirmar que todos os envios legítimos (incluindo newsletters e sistemas internos) passam SPF/DKIM. Para a base de zona e tipos de registro, consulte o Guia de zona DNS: registros A, MX, CNAME e TXT do zero.
O Postfix não “gera” DMARC Reports: ele envia as mensagens autenticadas. Se SPF ou DKIM estiverem quebrados, os relatórios mostrarão falha mesmo com o TXT correto. Por isso o alinhamento do envelope From, do header From e da assinatura DKIM é pré-requisito para os números fazerem sentido operacional.
Como configurar a caixa rua e receber os XML no Linux
A entrega de relatórios agregados exige uma mailbox que aceite anexos .xml.gz e não descarte por política de antispam. Crie o usuário local ou virtual, aponte o MX e teste o fluxo antes de confiar no monitoramento. Em Debian 13 com caixa local simples:
sudo adduser --disabled-password --gecos "DMARC Reports" dmarc
sudo mkdir -p /home/dmarc/Maildir/{cur,new,tmp}
sudo chown -R dmarc:dmarc /home/dmarc/MaildirNo main.cf, confirme que o destino local ou virtual cobre o endereço usado em rua. Exemplo mínimo para entrega local (ajuste home_mailbox se usar Maildir):
postconf -e "home_mailbox = Maildir/"
postconf -e "mydestination = \$myhostname, localhost.\$mydomain, localhost, \$mydomain"
postfix check && sudo systemctl reload postfixOutput esperado do check: silêncio (sem erros). Em seguida envie um teste manual para [email protected] a partir de outra conta e confira se a mensagem chega em Maildir/new. Se usar virtual_mailbox_maps ou Dovecot LMTP, o princípio é o mesmo: a caixa precisa existir e o Postfix deve aceitar o RCPT TO sem rejeitar por política.
Muitos operadores preferem um endereço em provedor externo confiável só para rua, reduzindo risco de loop ou de filtro local. O importante é que o endereço em mailto: seja entregável e monitore a pasta de spam nas primeiras semanas. Relatórios costumam chegar diariamente ou em lotes; volume baixo de envio implica poucos reports — isso não indica falha do DNS.
Por que DMARC Reports falham e como diagnosticar no Postfix
Falhas de visibilidade quase sempre estão no DNS, na caixa de destino ou no desalinhamento de autenticação, não em um “bug de DMARC” do Postfix. As causas mais comuns são: rua com typo ou domínio sem MX; caixa cheia ou que rejeita .gz; filtro que marca o report como spam; política p=reject agressiva demais cedo demais; e SPF/DKIM falhando para IPs legítimos (relay, CRM, painel). Use dig e os logs do Postfix em paralelo.
dig +short TXT _dmarc.seudominio.com.br
dig +short MX seudominio.com.br
tail -n 50 /var/log/mail.log | grep -i dmarcOutput esperado do TXT: uma única string v=DMARC1 com rua=mailto:... válido. Se dig não retornar nada, a zona não propagou ou o nome está errado (_dmarc no apex do domínio de envio). Nos logs, procure rejeições 550/554 para o endereço de report ou deferrals por greylist. Confirme também o Checklist: como testar se o DKIM e SPF estão configurados antes de culpar o fluxo de reports.
Outro ponto crítico: o domínio no From alinhado deve ser o mesmo (ou pai/filho conforme adkim/aspf) do domínio do SPF e do d= da assinatura DKIM. Envio via IP não listado no SPF ou com seletor DKIM expirado gera disposition fail nos XML mesmo com Postfix “saudável”. Ajuste includes do SPF e rotacione chaves DKIM com cuidado; evite SPF com muitos lookups (limite de 10).
Como ver e interpretar os XML de DMARC no servidor
Os anexos chegam compactados. Salve o .xml.gz, descompacte e leia os nós principais: report_metadata (org_name, date_range), policy_published, e cada record com source_ip, count, row/policy_evaluated (disposition, dkim, spf) e identifiers/header_from. Exemplo de fluxo em shell:
cd /tmp
gunzip -k report.xml.gz
head -n 80 report.xml
grep -E 'source_ip|disposition|dkim|spf|header_from|count' report.xml | head -n 40Output esperado: blocos com source_ip no estilo 203.0.113.10, count numérico, disposition none/quarantine/reject e resultados pass/fail para dkim e spf. IPs desconhecidos com volume alto e fail em ambos costumam indicar spoofing; IPs seus com fail apontam desalinhamento ou relay não autorizado no SPF. Agregue por source_ip ao longo de vários dias antes de bloquear.
Ferramentas open source de parsing geram resumos por domínio e IP; scripts próprios em Python ou awk também bastam para operação pequena. Não publique ruf (forense) sem política de privacidade: esses reports podem conter trechos de mensagens. Comece só com rua e p=none. Documente quais sistemas enviam em nome do domínio (ERP, marketing, tickets) para cruzar com os IPs dos XML.
Problemas comuns e como resolver
Sintoma: nenhum DMARC Report chega há dias
Causa: rua inválido, MX ausente, caixa cheia, antispam descartando .xml.gz ou volume de envio baixo demais para os receptores gerarem report.
Solução: valide o TXT com dig; envie e-mail de teste para o endereço rua; libere anexos gzip na caixa; confira quota; mantenha p=none e aguarde ciclo de 24–48 h após tráfego real para Gmail/Outlook.
Sintoma: reports mostram fail em SPF/DKIM para IP legítimo
Causa: IP de saída não está no SPF, DKIM com seletor errado, From desalinhado ou envio passando por relay não autorizado.
Solução: inclua o IP ou o include correto no SPF (respeitando o limite de lookups); confira o seletor em opendkim e o header DKIM-Signature; alinhe envelope e header From ao domínio do registro DMARC.
Sintoma: Postfix rejeita a mensagem de report na entrada
Causa: restrições de destinatário, greylist, policy de anexo ou mailbox inexistente.
Solução: confirme usuário/alias; revise smtpd_recipient_restrictions e milters; teste com swaks ou mail de outro host; veja mail.log no momento do RCPT TO e da entrega final.
Sintoma: XML corrompido ou ilegível após download
Causa: download incompleto, descompactação dupla ou cliente de e-mail alterando o anexo.
Solução: baixe o .gz original via IMAP/CLI; use gunzip uma vez; valide com file report.xml (deve indicar XML) e abra em editor que preserve UTF-8.
Perguntas frequentes sobre DMARC Reports no Postfix
O que são DMARC Reports no Postfix?
DMARC Reports são relatórios enviados por provedores receptores (Gmail, Outlook e outros) sobre como mensagens do seu domínio foram autenticadas com SPF e DKIM e qual política DMARC foi aplicada. No Postfix, o MTA entrega o e-mail; os reports chegam em caixas rua/ruf que você configura no registro DNS TXT de DMARC para monitorar entrega e abuso.
Qual a diferença entre relatório agregado (rua) e forense (ruf)?
O relatório agregado (rua) chega periodicamente em XML compactado e resume volumes, resultados SPF/DKIM e ações (none, quarantine, reject). O forense (ruf) envia amostras de falhas individuais e é mais sensível a privacidade; muitos operadores começam só com rua e política p=none para observar sem bloquear.
Preciso alterar o main.cf do Postfix só para receber DMARC Reports?
Em geral não: DMARC Reports são recebidos como e-mail normal na caixa definida em rua/ruf. O Postfix precisa aceitar e entregar essas mensagens (MX, caixa local ou relay). O que define o envio dos reports é o registro DNS _dmarc; o Postfix deve estar alinhado com SPF e DKIM para os números do relatório fazerem sentido.
Como ler e processar os XML de DMARC no servidor Linux?
Os anexos costumam vir em .xml.gz. Descompacte com gunzip e analise o XML (org_name, source_ip, contagem, resultados SPF/DKIM e disposition). Ferramentas open source de parsing ou scripts próprios ajudam a agregar por IP e identificar envios legítimos versus spoofing.
Por que os DMARC Reports não chegam mesmo com o registro publicado?
Causas comuns: rua com endereço inválido ou que rejeita XML, caixa cheia, filtro antispam, MX incorreto, ou volume baixo (poucos receptores geram report). Confirme o TXT _dmarc com dig, teste entrega na caixa de reports e mantenha p=none até validar o fluxo de monitoramento.
Conclusão
- Publique _dmarc com p=none e rua entregável; só endureça a política após semanas de XML consistentes
- Trate SPF, DKIM e alinhamento de From como base — reports ruins quase sempre refletem autenticação quebrada, não “falha do Postfix”
- Automatize a leitura dos .xml.gz por IP e cruze com a lista de sistemas autorizados a enviar pelo domínio
Leia também
- configurar Postfix com SPF, DKIM e DMARC no AlmaLinux 9
- Entenda o Postfix no Alpine Linux 3.24: envio para Gmail
- Guia para configurar Postfix com autenticação SASL no Ubuntu 22.04
Precisa de ajuda com DMARC Reports no Postfix?
Um VPS com recursos estáveis e acesso completo ao Postfix e ao DNS facilita publicar _dmarc, receber rua e corrigir SPF/DKIM sem filas compartilhadas. A AviraHost oferece ambientes Linux prontos para MTA e monitoramento de entrega.
