Este é um problema que estamos vendo com o Exchange Online, mas seria um problema com a maioria dos emails hospedados que eu suspeito. Quando o Office 365 / Exchange Online envia uma resposta automática (Fora do escritório, por exemplo), ele segue o RFC 2298 e o RFC5321.MailFrom é nulo:
RFC 2298 – Message Disposition Notifications
https://tools.ietf.org/html/rfc2298
The From field of the message header of the MDN MUST contain the
address of the person for whom the message disposition notification
is being issued.
The envelope sender address (i.e., SMTP MAIL FROM) of the MDN MUST be
null (<>), specifying that no Delivery Status Notification messages
or other messages indicating successful or unsuccessful delivery are
to be sent in response to an MDN.
Quando o RFC5321.MailFrom é nulo, o SPF usa a identidade "HELO / EHLO" do servidor de envio:
RFC 7208 - Sender Policy Framework (SPF)
https://tools.ietf.org/html/rfc7208
SPF verifiers MUST check the "MAIL FROM" identity if a "HELO" check
either has not been performed or has not reached a definitive policy
result by applying the check_host() function to the "MAIL FROM"
identity as the <sender>.
[RFC5321] allows the reverse-path to be null (see Section 4.5.5 in
[RFC5321]). In this case, there is no explicit sender mailbox, and
such a message can be assumed to be a notification message from the
mail system itself. When the reverse-path is null, this document
defines the "MAIL FROM" identity to be the mailbox composed of the
local-part "postmaster" and the "HELO" identity (which might or might
not have been checked separately before).
Os problemas começam quando você está usando o DMARC porque um OOF ou NDR será assim:
Quando o servidor de recebimento de emails faz suas verificações de spam, eles farão algo assim:
Snippet de cabeçalho real (anonimizado):
Return-Path: <>
From: John Doe <[email protected]>
Received: from xxx00-xx0-xxx.outbound.protection.outlook.com (mail-xxx00xx0xxx.outbound.protection.outlook.com. [104.47.xx.xxx])
by mx.google.com with ESMTPS id y11si90960plg.98.2017.09.07.10.27.33
authentication-results: spf=none (sender IP is ) smtp.mailfrom=<>;
Received-SPF: pass (google.com: domain of [email protected] designates 104.47.xx.xxx as permitted sender) client-ip=104.47.xx.xxx;
Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=selector1-company-com header.b=gb5VTzi+;
spf=pass (google.com: domain of [email protected] designates 104.47.xx.xxx as permitted sender) smtp.helo=xxx00-xx0-xxx.outbound.protection.outlook.com;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=company.com
Nesse exemplo, p é igual a 'none', então a mensagem chega de qualquer maneira, mas com rejeição ou quarentena, a mensagem nunca chegará e porque o caminho de retorno é nulo, nenhuma notificação de falha na entrega é entregue ao usuário que enviou a resposta automática ( esse é o ponto e porque é nulo.) Assim, o contato externo não recebe uma resposta automática e não sabe que deveria ser feito, e o usuário interno não sabe que o contato externo não o recebeu. Perca-se.
Somente por meio de rastreamentos de mensagens você encontrará o problema:
Event : Fail
Action :
Detail : Reason: [{LED=550-5.7.1 Unauthenticated email from company.com is not accepted due to 550-5.7.1 domain's DMARC policy. Please contact the administrator of 550-5.7.1 company.com domain if this was a legitimate mail. Please visit 550-5.7.1
https://support.google.com/mail/answer/2451690 to learn about the 550 5.7.1 DMARC initi. OutboundProxyTargetIP: 74.125.xx.xx. OutboundProxyTargetHostName: gmail-smtp-in.l.google.com
Com servidores de e-mail internos onde a identidade HELO / EHLO dos servidores de e-mail é o que for.mail.company.com, isso não é um problema, pois aspf = r no registro DMARC permitirá que o subdomínio passe o alinhamento; No entanto, como a identidade HELO / EHLO é um domínio * .Microsoft e não o alinhamento * .company.com sempre falhará.
Existe uma maneira de superar essa limitação? Algum tipo de exceção ou sinalizador de política? Usando uma regra para enviar respostas automáticas ou usando uma regra de transporte não estão na minha mente soluções; Eles são soluções alternativas e os usuários inevitavelmente esquecem / ignoram as mensagens e definem as respostas automáticas de qualquer maneira.
Se você definir o DKIM para seu domínio personalizado "company.com" (d = company.com), ele será alinhado com o cabeçalho RFC5322.From e passará pelo DMARC.
O DMARC passará se QUALQUER uma das duas (SPF ou DKIM) passar alinhada com a RFC5322.A partir de.
Você pode definir o DKIM do seu domínio personalizado no centro de administração do Exchange - > Proteção - > DKIM