SPF (Sender Policy Framework) é essencial, recurso que declara através de quais IPs seu domínio pode enviar e-mail e já vem configuado por padrão quando se usa nosso DN. Veja: https://suporte.lucanet.com.br/kb/outros/entradas-de-dns-do-servico-de-email
DKIM (DomainKeys Identified Mail) também é interessante e recomendado, autenticação com assinatura/criptografia. Detalhes: https://suporte.lucanet.com.br/kb/painel-de-e-mails-do-admin/como-configurar-dkim
Já o DMARC (Mensagem Baseada em Domínio de Autenticação, Relatório e Conformidade), é algo totalmente opcional, um tanto o quanto complexo e que ainda não tem uma implementação em larga escala, por vários motivos técnicos. Caso queira implementar, envolve um estudar o assunto para determinar qual configuração usará.
Você pode começar com uma entrada de básica, criando uma entrada de TXT para _dmarc com o seguinte valor:
v=DMARC1; p=none; rua=mailto:dmarc-reports@seudominio.com
Troque o endereço email acima por um seu, para receber relatórios.
Exemplo:
Basicamente, esta declaração não toma nenhuma ação, devido à ação p=none (nenhuma). A ideia é auditar possíveis bloqueios que ocorreriam, nos relatórios recebidos por e-mail, para depois alterar o p=none para p=reject e efetivamente rejeitar.
De forma resumida, vale entender que o p=reject compara o FROM do header com o Sender (normalmente exibido no header do e-mail) e caso não batam, toma determinada a ação de rejeitar o e-mail no destino. A ideia é rejeitar e-mails falsificados, que se passaram por seu domínio no header do FROM. É o chamado alinhamento entre header/sender do e-mail remetente, em comparação ao SPF e DKIM. Dependendo da sua parametrização de SPF e DKIM, através das diretivas aspf e adkim, a verificação é feita para domínios ou apenas subdomínios. Detalhes nos links abaixo, que entram a fundo na questão da parametrização.
O problema é que DMARC pode gerar falsos positivos, pois você pode realizar envios legítimos por sistemas que usam seu domínio no FROM header e um Sender completamente diferente. Isso é comum, por exemplos, nos envios feitos pela Amazon, onde permitem, entretanto, que se customize o Sender, para usar seu domínio ao invés do deles.
O ideal é começar com a parametrização inicialmente informada (p=none), estudar a tecnologia e relatórios recebidos ir ajustando a parametrização. Partir logo para o p=reject pode certamente evitar que e-mails forjando seu domínio sejam recebidos nos destinos, mas também causaria rejeição de e-mails legítimos que possam ter FROM do header e sender diferentes.
Dicas de implementação do Google: https://support.google.com/a/answer/2466563?hl=en
Outras dicas de implementação: https://www.esecurityplanet.com/applications/how-to-set-up-and-implement-dmarc-email-security/
Dicas do site MX Toolbox: https://mxtoolbox.com/dmarc/details/what-is-a-dmarc-record
Uma opção interessante é ativar o trial neste site: https://dmarc.postmarkapp.com/
Basicamente, eles irão te passar um registro TXT de DMARC a incluir no seu DNS que, inicialmente, não toma nenhuma ação (p=none), apenas gera relatórios mais amigáveis que os fornecidos usando-se a sintaxe inicialmente referenciada nesse tutorial, sem apoio de um serviço de terceiros. Então, pelos relatórios mais amigáveis, você poderá ir ajustando seu registro DMARC, até que esteja seguro para parametriza-lo de forma mais rigorosa, por exemplo, definindo para destinos rejeitarem emails no qual seu SPF ou DKIM não batem com o FROM do remetente real (sender, que fica no header da mensagem), ou seja, p=reject.
Vale ressaltar que o site anteriormente referenciado também possui uma versão gratuita em https://dmarcdigests.com/comparison.
Do mesmo site do serviço acima, alguns tutoriais interessantes:
https://postmarkapp.com/guides/dmarc
https://support.dmarcdigests.com/
Outro tutorial útil para quem realizar envios pelo Amazon SES: https://help.emailoctopus.com/article/68-setting-up-dmarc-spf-dkim
Finalmente, 2 sites bons para se verificar um registro DMARC: