Pense no SPF e no DKIM como formas de validar o caminho do email e pense no DMARC como uma extensão que também valida o remetente da mensagem. Pense nisso como entregar uma carta da FedEx. É fácil validar de onde o envelope foi enviado e que o correio era legítimo, mas não fornece uma maneira de provar que a carta dentro do envelope é realmente da pessoa cujo nome foi impresso.
Seu servidor da Web é um servidor SMTP válido para mywebserver.com e seu endereço de Remetente é legítimo, mas isso não é suficiente para outros servidores confiarem que você tenha permissão para enviar como [email protected]. Como o GMail sabe que o seu servidor não foi invadido ou usado para intenções maliciosas? Os servidores do Gmail não confiam cegamente em você para enviar e-mails como um de seus usuários - a menos que você esteja hospedado por eles e, provavelmente, tenha problemas para enviar para o Yahoo.
Para abordar sua primeira parte da pergunta, sim, é muito provável que seja por isso que o Gmail o classifica como spam. As formas mais antigas de spam centram-se na falsificação do endereço "De". Isso é o que a maioria dos usuários vê quando recebe uma mensagem e é o principal campo em que deseja confiar. Quando uma mensagem de um servidor de e-mail legítimo é enviada usando um endereço De que não pertence a esse servidor de e-mail, ainda é um sinal vermelho.
Como você mencionou, o DMARC opera no endereço De como parte da especificação. Concedido, torna-se mais difícil escrever aplicativos da web que enviam em nome de alguém, mas esse é o ponto. Quanto a por que eles fazem isso - bem, isso é algo que cabe aos projetistas da especificação, mas é um trade-off. Eles estão tomando a estrada e fazendo um sistema que funciona muito bem se você ficar dentro dessa limitação. Talvez mecanismos futuros encontrem uma maneira de contornar isso.
A solução infeliz é usar apenas endereços dos quais você tem controle. Para resolver sua terceira pergunta, assine suas mensagens com o nome do seu domínio e mencione no corpo que ele foi enviado em nome do [email protected]. Caso contrário, você terá que solicitar que seus destinatários adicionem o endereço à lista de permissões. Não é muito divertido para um desenvolvedor de aplicativos da Web legítimo, mas protege a santidade da caixa de entrada do destinatário. Você pode ter sorte ao usar o cabeçalho Reply-To com o endereço de e-mail do usuário da Web.
Há uma discussão sobre essa limitação em este tópico do DMARC .
Nesse meio tempo, você pode tentar garantir que seu servidor não esteja na lista negra de nenhuma RBL. Pode ser que você possa falhar no DMARC, mas ainda assim passar por alguns filtros de spam se tiver uma reputação boa o suficiente ... mas eu não confiaria nele.