Хорошо, если я правильно читаю, почта отправляется с @st***er.com в gmail (и DMARC проходит: строка 27). Затем Gmail был настроен на автоматическую переадресацию на адрес @ne***rt.net (и опять-таки это похоже на передачу DMARC: строки 9-13).
Все в этой настройке показывает, что это должно работать. И, так как вы получили электронное письмо, чтобы вы могли посмотреть заголовки, я также предполагаю, что это правда (сообщение было доставлено).
Я быстро проверил запись DMARC на _dmarc.st***er.com и увидел, что у вас включено строгое выравнивание ("... adkim=s; aspf=s ..."). Хотя это и не должно иметь значения (опять же, тест gmail, который вы разместили в заголовках для демонстрации того, что все работает; по крайней мере, в отношении SPF/DKIM/DMARC), есть вероятность, что соблюдение строгого выравнивания вызывает проблемы в *** почтовые серверы rt.net. Это указывает на то, что ne *** rt.net, вероятно, там, где возникает проблема; но вы можете полностью избежать этого, используя расслабленное выравнивание (либо измените те =s на =r , либо просто полностью пропустите термины aspf и adkim ).
Если у вас возникла проблема с адресом переадресации, который использует DMARC Forensic Reporting (их DNS-запись _dmarc будет содержать ruf=mailto: term), вы можете попробовать связаться с почтовыми администраторами этой системы и посмотреть, отправят ли они вам копию судебно-медицинская экспертиза за провал. Отбрасывание монет, многие места не будут беспокоить, но если вы можете заставить кого-то отправить вам копию Криминалистического отчета о сбое, то вы точно поймете, почему его сервер отклонил сообщение.
Это было немного для комментария (и если это работает, это ответ). Но, пожалуйста, дайте мне знать, если это не так, чтобы я мог изменить этот ответ, чтобы люди знали, что он не работает.
NOTE :: for anyone asking for email help):: While I did try to still obscure the messaging domains, since @Ben went through the effort to dummy them in the headers, this isn't useful for privacy or diagnostics. As you can see, I had to work to figure out what the actual domains were (IPs are still listed, so it was do-able) so that I could lookup the SPF and DMARC records for the domains involved. So obscuring isn't helpful for diagnostics. And, email is a public transit system -- as in, everything is designed to work & maintain security in a "white box" fashion where the public is knowledgeable about the interactions. Obscuring public hostnames & IPs in a email header doesn't actually give you any extra security. (Do feel free to redact internal-only hostnames & IPs from within your system, that is a valid approach.) Nothing against Ben here, just noting for anyone seeing this in the future that obscuring already public information doesn't really do anything except slow down the person working to research the issue.
