On 24/04/18 00:51, Terry Zink via dmarc-discuss wrote:

> Failure reporting seems odd (because it's always legitimate)
> until you recall that part of the purpose of failure reporting
> is to discover errors by the domain registrant, particularly

> including errors in the DNS zone file, which may or may not

> be under Office 365 control

If Office 365 isn’t doing any DNS checks for SPF, DKIM, and DMARC for internal email, then how would a DMARC report help with any of that?


On this line of reasoning, it would be necessary to perform those checks during message handling.

(I note that you refer here to "internal mail" and below to "inter-tenant communication". To be clear, I'm referring specifically to DMARC reporting - both failure and aggregate - for inter-tenant email, rather than for intra-tenant email.)

> Aggregate reporting likewise seems like something that would
> make sense for inter-tenant communication

Inter-tenant communication is treated the same (more or less) as an inbound message that originates from outside the service, so any DMARC reports that are sent would not different between tenant-to-tenant mail vs. outside-to-Office365 mail.


So long as the checks are being performed, yes, this is what I'm suggesting.

You might reasonably object that the incremental benefit in performing these tests is too small to warrant performing them of course (presumably there are no large mailing-list operators using Office 365).

> Does Office 365 DKIM sign inter-tenant email?

Yes. Inter-tenant mail is treated the same for DKIM purposes as Tenant-to-external mail. Our customer guidance is here for DKIM: https://technet.microsoft.com/en-us/library/mt695945(v=exchg.150).aspx


Great.

- Roland

_______________________________________________
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
http://www.dmarc.org/mailman/listinfo/dmarc-discuss

NOTE: Participating in this list means you agree to the DMARC Note Well terms 
(http://www.dmarc.org/note_well.html)

Reply via email to