How to correctly use the internal relay domain in MS Exchange to receive emails from Mail.ru?

Question

Email

Mail.ru enabled strict DMARC not too long ago.
This is good, thank you very much for developing the service, keep it up!
On 05/20/2016, I encountered the fact that mail from @mail.ru @list.ru addresses and, in general, from all addresses of the mail.ru mail service (this did not affect mail for business) stopped reaching @firma.ru mail addresses
Part of the @firma mail addresses .ru is hosted on google apps
Another part of the MS Exchange 2010 corporate mail server
MX records of the @firma.ru domain tell the whole world that any letter should be sent to Exchange
In Exchange, the @firma.ru domain is configured as an internal relay domain.
- for the @firma.ru domain, a send connector has been created, which indicates that it is necessary to route mail through intermediate Googlemail nodes
- for the @firma.ru domain, MX records of Google mail are specified in the corporate DNS.
When a letter arrives at [email protected], Exchange looks for the address [email protected] in its list, and if it finds it, it puts the letter there.
If it doesn't find it, it sends it to Google.
The scheme is very old, working, proven. Was)
Now it doesn’t work like that if a letter arrives from @mail.ru to an addressee whose mailbox is in google mail.
The response returned
is mx.google.com #550-5.7.1 Unauthenticated email from mail.ru is not accepted due to domain's 550-5.7.1 DMARC policy
That's understandable. you cannot send on behalf of mail.ru to servers that are not allowed by DMARC
@firma.ru users who have mail on google apps there for a reason .. they cannot be transferred to Exchange for a number of reasons.
I hope that there is some way to drive letters through itself as before without violating DMARC, maybe someone has already solved such a problem.
I will be glad and grateful if Vladimir Dubrovin answers

Answer 1

Ordinary redirects should not change the content of the message, and therefore should not spoil the DKIM signature, and DMARC in this situation does not interfere with the passage of the message. There are errors like https://support.microsoft.com/en-us/kb/2993556 that Microsoft fixes, try installing the latest service packs and rollup updates.
Perhaps it is in your configuration for some reason that the letter is rebuilt, for example, in the format settings there is a forced format change to RTF/HTML. I am not strong in the Exchange settings, but check that this does not happen. Try to send a letter from any other address to recipients on both servers, compare the result with diff to understand why DKIM is beating.
And keep in mind that if the DKIM signature of the letter is beating, then you are not receiving letters not only from mail.ru, but also from yahoo, aol, linkedin, facebook, Vkontakte, paypal and many others, including letters from Google itself (@ google.com) - because all of these domains also have strict DMARC.

Answer 2

DMARC is DKIM + SPF technology at least.
Those. you have a problem with SPF, not with DKIM, because your service is not in ranges
"v=spf1 ip4:94.100.176.0/20 ip4:217.69.128.0/20 ip4:128.140.168.0/21 ip4:188.93.58.0/24 ip4:195.211.128.0/22 ​​ip4:188.93.59.0 /24 ip4:128.140.170.0/24 ip4:178.22.92.0/23 ip4:185.5.136.0/22 ​​ip4:5.61.237.0/26 ip4:5.61.237.128/25 ip4:5.61.236.0/24 ~all"
google reject mail , although mail.ru does not have a strict (~all - that is, the receiving party must make a decision) correspondence, Google finally decides what is spam and what is not spam.
And probably nothing can be done here, it will only get worse with such schemes, because the spammers have already got everyone.

Answer 3

Good afternoon!
Big thanks to everyone who responded!
Exchange 2010 has not really been updated with the latest update. It was the penultimate one.
It was possible to update to Rollup 13.
Unfortunately, nothing has changed.. I did
some experiments, I want to share with you.
Using a public mailbox:
1. Through the web interface, I tried to create letters with and without text in the body of the letter.
turned off the design and cleared the format (Buttons "Advanced design / remove design" and the button " Clear formatting" when "Advanced design" is enabled) text
All letters sent from Mailru returned with the same error about DMARC
After that, I used the public boxes on Yandex. To see the original letter sent from Yandex when it reaches Gmail.
1. Through the web interface, I tried to create letters with and without text in the body of the letter. turned off formatting and cleared the format (Buttons "Format letter/disable formatting" and the button "Remove formatting" when the button "Format letter" is pressed)
ALWAYS in the letter that reached gmail there are such deadlines:
Authentication-Results: mx.google.com;
dkim=fail [email protected];
spf=softfail (google.com: domain of transitioning [email protected] does not designate XXX.XXX.XXX.XXX as permitted sender) [email protected];
dmarc=fail (p=NONE dis=NONE) header.from=yandex.ru
At the same time, the DKIM-Signature block in letters from Mailru and in letters from Yandex does not change .
To check, I send a letter to two mailboxes of the @firma.ru domain at
once, one in Exchange and the other in Gmail. Block DKIM-Signature one to one . Is there a way to compare them somehow?
BUT! that's not all ))
I found a sequence of actions that still gives dmarc=pass
, you need to go to sent, go to the letter, click answer,
delete the text in the body of the letter and
then send
Authentication-Results: mx.google.com;
dkim=pass [email protected];
spf=softfail (google.com: domain of transitioning [email protected] does not designate XXX.XXX.XXX.XXX as permitted sender) [email protected];
dmarc=pass (p=NONE dis=NONE) header.from=yandex.ru
It turns out that Exchange changes something in the body of the letter, though? how does it reformat it?
Haven't found such a setting in Exchange yet. Maybe I'll find more)
To be honest, I still don't understand why, for example, a response to a letter in Yandex web mail passes the DMARC check.
------------------------------------
After a month and a half, we managed to test in the environment freshly installed Exchange 2013
the result is the same.