Re: [dmarc-discuss] Mimecast and Office 365

2018-04-27 Thread Simon Tyler via dmarc-discuss
OK. I will chase this up internally – I am surprised we make body encoding only 
changes, I can believe that the same encoding is used but the encoding results 
differ.

If you can reply off list with more specific examples (customer detail not 
required) then that would be good.

In terms of the option to switch off. They should for the “pass through policy” 
which can be set to cause to preserve the original message as received (invalid 
linefeeds might change sometimes) as long as a more aggressive policy doesn’t 
override it. This can be set at as fine a granularity as they wish.

Simon


[ YouTube: http://www.youtube.com/user/mimecast#p/u/15/_523kC3lcNQ]  [ Twitter: 
http://twitter.com/mimecast ]  [ Our Blog: http://blog.mimecast.com/ ] 

Simon Tyler
VP of Engineering and Product Research
c: +44 7590 735958
p: +44 207 847 8700
http://www.mimecast.com

Johannesburg Map 
GPS: 26' 05.940" S, 18o 28' 04.278" E
(http://maps.google.com/maps/ms?hl=en=UTF8=0=104153695170153523925.000469102c74a808b138c≪=-26.099685,28.069403=0.011986,0.026178=16)

Cape Town Map
GPS: 33o 56.068" S, 18o 28.320" E
(http://maps.google.com/maps/ms?source=s_q=en≥ocode==all=UTF8=Fir+Street,+Observatory,Cape+Town=0≪=-33.934753,18.4721=0.00413,0.009656=17=100887237870528382628.00046a80a3916c933dad3)



Disclaimer

This email, sent at 11:56:40 on 2018-04-27 from sty...@mimecast.com to 
dmarc-discuss@dmarc.org has been scanned for viruses and malware by Mimecast, 
an innovator in software as a service (SaaS) for business. 's email continuity, 
security, archiving and compliancy is managed by Mimecast's unified email 
management platform. 
To find out more, email i...@mimecast.co.za or request a demo.

Mimecast SA (Pty) Ltd is a registered company within the Republic of South 
Africa, company registration number: 2004/000965/07  VAT No. 4650210547

From: Roland Turner <rol...@rolandturner.com>
Date: Thursday, 26 April 2018 at 07:39
To: Simon Tyler <sty...@mimecast.com>, "dmarc-discuss@dmarc.org" 
<dmarc-discuss@dmarc.org>
Subject: Re: [dmarc-discuss] Mimecast and Office 365

Hi Simon,

Many thanks for following this up!

I'm not in a position to name the Mimecast customer in question, but will 
certainly forward your message to them.

Their understanding was that the unpacking and repacking was unconditional, 
that Mimecast provided no option to turn it off for specified recipients whose 
live mailboxes were hosted elsewhere (there was MTA-level forwarding happening 
within the customer's environment) and for whom DKIM-preserving forwarding was 
therefore a requirement, the only Mimecast features required for those 
particular users being upfront spam filtering. In the test messages that I saw, 
Mimecast was making no policy-relevant content changes at all, it was merely 
changing the body encoding; this breaks DKIM signatures and therefore DMARC but 
has little other practical effect.

A non-"body based" DKIM signature is essentially an invitation to phish, as it 
allows an adversary to present - and have pass DKIM validation - any body and 
attachments that they wish. It is technically possible to sign headers only but 
this is not a widespread practice, and not an obviously useful one.

The recent discussion on this list about internal DMARC checks appears to have 
been a discussion at crossed purposes: internal to Office 365 vs. internal to a 
single tenant.

Regards,

- 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)

Re: [dmarc-discuss] Mimecast and Office 365

2018-04-26 Thread Roland Turner via dmarc-discuss
eged. It is intended solely for use by 
*rol...@rolandturner.com * and others authorized to receive it. If you 
are not *rol...@rolandturner.com * you are hereby notified that any 
disclosure, copying, distribution or taking action in reliance of the 
contents of this information is strictly prohibited and may be unlawful.


This email message has been scanned for viruses by Mimecast. Mimecast 
delivers a complete managed email solution from a single web based 
platform. For more information please visit http://www.mimecast.com




*From: *dmarc-discuss <dmarc-discuss-boun...@dmarc.org> on behalf of 
Roland Turner via dmarc-discuss <dmarc-discuss@dmarc.org>

*Reply-To: *Roland Turner <rol...@rolandturner.com>
*Date: *Thursday, 12 April 2018 at 09:07
*To: *"dmarc-discuss@dmarc.org" <dmarc-discuss@dmarc.org>
*Subject: *Re: [dmarc-discuss] Mimecast and Office 365

On 11/04/18 22:07, Ivan Kovachev via dmarc-discuss wrote:

Hello guys,

I have three questions for you that I am unsure about and hoping
that someone at Microsoft will be able to help:

First two questions are related to Mimecast acting as inbound
security gateway to O365:

1. When Mimecast acts as inbound gateway solution and it receives
an email, it does DMARC checks and lets the email through to O365
environment. Even if an email passes DMARC checks at Mimecast and
the email is let through, then O365 also seems to also be doing
DMARC checks but both SPF and DKIM fail because of the change that
Mimecast does. As a results DMARC fails. My questions is, what is
the best practice here in this scenario? Is there a way to turn
off DMARC checks at O365? Mimecast suggest that it is whitelisted
in O365 but that means that all the spam will be let through as well.


DMARC checking should only occur at the host referred to be the MX 
record as SPF is still relevant for at least some email. I believe 
Office 365 has a trusted inbound relays option (i.e. Office 365 trusts 
the specified hosts to filter their email) although I can't quickly 
find it.


Mimecast is apparently unwilling to change their service to stop 
damaging incoming messages that don't breach the policies being 
enforced (they unconditionally unpack and then repack every message, 
rather than only those whose contents they have reason to modify).



2. Would O365 send DMARC reports back to the sender in the above
case? And, if O365 sends DMARC reports back to the sender then
emails will be shown as originating from Mimecast but failing DMARC.


Yes and yes if you've not listed Mimecast as a trusted inbound relay. 
(Assuming that the trusted inbound relays setting is not a figment of 
my imagination, one would hope that Office 365 would not set feedback 
in this case.)



3. Would O365 do DMARC checks for internal emails ie. O365 tenant
employee to another O365 tenant employee? And would it send DMARC
reports in this case?


Yes and hopefully yes.

- 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)

Re: [dmarc-discuss] Mimecast and Office 365

2018-04-23 Thread Roland Turner via dmarc-discuss

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)

Re: [dmarc-discuss] Mimecast and Office 365

2018-04-23 Thread Terry Zink via dmarc-discuss
> 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?

> 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.

> 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

Our all-up guide for antispoofing (of which SPF, DKIM, and DMARC play a part) 
is here: http://aka.ms/LearnAboutSpoofing.

--Terry

From: dmarc-discuss <dmarc-discuss-boun...@dmarc.org> On Behalf Of Roland 
Turner via dmarc-discuss
Sent: Sunday, April 22, 2018 11:00 PM
To: dmarc-discuss@dmarc.org
Subject: [EXTERNAL] Re: [dmarc-discuss] Mimecast and Office 365

DMARC checking within a service provider doesn't make much sense, however DMARC 
reporting probably would when/if you implement it:

  *   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.
  *   Aggregate reporting likewise seems like something that would make sense 
for inter-tenant communication.

Related question: does Office 365 DKIM sign inter-tenant email? (This would not 
be terribly important for end delivery at the addressed tenant, but would be 
important for messages that were automatically forwarded elsewhere.)

- Roland


On 23/04/18 12:55, Terry Zink via dmarc-discuss wrote:

>> 3. Would O365 do DMARC checks for internal emails ie.
>> O365 tenant employee to another O365 tenant employee?
>> And would it send DMARC reports in this case?

I didn’t see this answered, so answering it now.

Office 365 doesn’t do DMARC checks for internal emails since they don’t leave 
the network perimeter. Since no DMARC check is done, no DMARC report is sent 
(Office 365 doesn’t send DMARC reports anyway, but if it did, it wouldn’t in 
this case). There are some advanced reporting capabilities for Advanced Threat 
Protection customers that can quasi-approximate DMARC reports, and you could 
use Transport rules in the service to approximate a RUF report. But there’s no 
official DMARC reporting at this time.

--Terry

From: dmarc-discuss 
<dmarc-discuss-boun...@dmarc.org><mailto:dmarc-discuss-boun...@dmarc.org> On 
Behalf Of Roland Turner via dmarc-discuss
Sent: Thursday, April 12, 2018 12:57 AM
To: dmarc-discuss@dmarc.org<mailto:dmarc-discuss@dmarc.org>
Subject: [EXTERNAL] Re: [dmarc-discuss] Mimecast and Office 365

On 11/04/18 22:07, Ivan Kovachev via dmarc-discuss wrote:
Hello guys,

I have three questions for you that I am unsure about and hoping that someone 
at Microsoft will be able to help:

First two questions are related to Mimecast acting as inbound security gateway 
to O365:

1. When Mimecast acts as inbound gateway solution and it receives an email, it 
does DMARC checks and lets the email through to O365 environment. Even if an 
email passes DMARC checks at Mimecast and the email is let through, then O365 
also seems to also be doing DMARC checks but both SPF and DKIM fail because of 
the change that Mimecast does. As a results DMARC fails. My questions is, what 
is the best practice here in this scenario? Is there a way to turn off DMARC 
checks at O365? Mimecast suggest that it is whitelisted in O365 but that means 
that all the spam will be let through as well.

DMARC checking should only occur at the host referred to be the MX record as 
SPF is still relevant for at least some email. I believe Office 365 has a 
trusted inbound relays option (i.e. Office 365 trusts the specified hosts to 
filter their email) although I can't quickly find it.

Mimecast is apparently unwilling to change their service to stop damaging 
incoming messages that don't breach the policies being enforced (they 
unconditionally unpack and then repack every message, rather than only those 
whose contents they have reason to modify).



2. Would O365 send DMARC reports back to the sender in the above case? And, if 
O365 sends DMARC reports back to the sender then emails will be shown as 
originating from Mimecast but failing DMARC.

Yes and yes if you've not liste

Re: [dmarc-discuss] Mimecast and Office 365

2018-04-23 Thread Roland Turner via dmarc-discuss
DMARC checking within a service provider doesn't make much sense, 
however DMARC reporting probably would when/if you implement it:


 * 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.
 * Aggregate reporting likewise seems like something that would make
   sense for inter-tenant communication.

Related question: does Office 365 DKIM sign inter-tenant email? (This 
would not be terribly important for end delivery at the addressed 
tenant, but would be important for messages that were automatically 
forwarded elsewhere.)


- Roland


On 23/04/18 12:55, Terry Zink via dmarc-discuss wrote:


>> 3. Would O365 do DMARC checks for internal emails ie.

>> O365 tenant employee to another O365 tenant employee?

>> And would it send DMARC reports in this case?

I didn’t see this answered, so answering it now.

Office 365 doesn’t do DMARC checks for internal emails since they 
don’t leave the network perimeter. Since no DMARC check is done, no 
DMARC report is sent (Office 365 doesn’t send DMARC reports anyway, 
but if it did, it wouldn’t in this case). There are some advanced 
reporting capabilities for Advanced Threat Protection customers that 
can quasi-approximate DMARC reports, and you could use Transport rules 
in the service to approximate a RUF report. But there’s no official 
DMARC reporting at this time.


--Terry

*From:*dmarc-discuss <dmarc-discuss-boun...@dmarc.org> *On Behalf Of 
*Roland Turner via dmarc-discuss

*Sent:* Thursday, April 12, 2018 12:57 AM
*To:* dmarc-discuss@dmarc.org
*Subject:* [EXTERNAL] Re: [dmarc-discuss] Mimecast and Office 365

On 11/04/18 22:07, Ivan Kovachev via dmarc-discuss wrote:

Hello guys,

I have three questions for you that I am unsure about and hoping
that someone at Microsoft will be able to help:

First two questions are related to Mimecast acting as inbound
security gateway to O365:

1. When Mimecast acts as inbound gateway solution and it receives
an email, it does DMARC checks and lets the email through to O365
environment. Even if an email passes DMARC checks at Mimecast and
the email is let through, then O365 also seems to also be doing
DMARC checks but both SPF and DKIM fail because of the change that
Mimecast does. As a results DMARC fails. My questions is, what is
the best practice here in this scenario? Is there a way to turn
off DMARC checks at O365? Mimecast suggest that it is whitelisted
in O365 but that means that all the spam will be let through as well.


DMARC checking should only occur at the host referred to be the MX 
record as SPF is still relevant for at least some email. I believe 
Office 365 has a trusted inbound relays option (i.e. Office 365 trusts 
the specified hosts to filter their email) although I can't quickly 
find it.


Mimecast is apparently unwilling to change their service to stop 
damaging incoming messages that don't breach the policies being 
enforced (they unconditionally unpack and then repack every message, 
rather than only those whose contents they have reason to modify).



2. Would O365 send DMARC reports back to the sender in the above
case? And, if O365 sends DMARC reports back to the sender then
emails will be shown as originating from Mimecast but failing DMARC.


Yes and yes if you've not listed Mimecast as a trusted inbound relay. 
(Assuming that the trusted inbound relays setting is not a figment of 
my imagination, one would hope that Office 365 would not set feedback 
in this case.)



3. Would O365 do DMARC checks for internal emails ie. O365 tenant
employee to another O365 tenant employee? And would it send DMARC
reports in this case?


Yes and hopefully yes.

- 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)



___
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)

Re: [dmarc-discuss] Mimecast and Office 365

2018-04-22 Thread Terry Zink via dmarc-discuss

>> 3. Would O365 do DMARC checks for internal emails ie.
>> O365 tenant employee to another O365 tenant employee?
>> And would it send DMARC reports in this case?

I didn’t see this answered, so answering it now.

Office 365 doesn’t do DMARC checks for internal emails since they don’t leave 
the network perimeter. Since no DMARC check is done, no DMARC report is sent 
(Office 365 doesn’t send DMARC reports anyway, but if it did, it wouldn’t in 
this case). There are some advanced reporting capabilities for Advanced Threat 
Protection customers that can quasi-approximate DMARC reports, and you could 
use Transport rules in the service to approximate a RUF report. But there’s no 
official DMARC reporting at this time.

--Terry

From: dmarc-discuss <dmarc-discuss-boun...@dmarc.org> On Behalf Of Roland 
Turner via dmarc-discuss
Sent: Thursday, April 12, 2018 12:57 AM
To: dmarc-discuss@dmarc.org
Subject: [EXTERNAL] Re: [dmarc-discuss] Mimecast and Office 365

On 11/04/18 22:07, Ivan Kovachev via dmarc-discuss wrote:
Hello guys,

I have three questions for you that I am unsure about and hoping that someone 
at Microsoft will be able to help:

First two questions are related to Mimecast acting as inbound security gateway 
to O365:

1. When Mimecast acts as inbound gateway solution and it receives an email, it 
does DMARC checks and lets the email through to O365 environment. Even if an 
email passes DMARC checks at Mimecast and the email is let through, then O365 
also seems to also be doing DMARC checks but both SPF and DKIM fail because of 
the change that Mimecast does. As a results DMARC fails. My questions is, what 
is the best practice here in this scenario? Is there a way to turn off DMARC 
checks at O365? Mimecast suggest that it is whitelisted in O365 but that means 
that all the spam will be let through as well.

DMARC checking should only occur at the host referred to be the MX record as 
SPF is still relevant for at least some email. I believe Office 365 has a 
trusted inbound relays option (i.e. Office 365 trusts the specified hosts to 
filter their email) although I can't quickly find it.

Mimecast is apparently unwilling to change their service to stop damaging 
incoming messages that don't breach the policies being enforced (they 
unconditionally unpack and then repack every message, rather than only those 
whose contents they have reason to modify).


2. Would O365 send DMARC reports back to the sender in the above case? And, if 
O365 sends DMARC reports back to the sender then emails will be shown as 
originating from Mimecast but failing DMARC.

Yes and yes if you've not listed Mimecast as a trusted inbound relay. (Assuming 
that the trusted inbound relays setting is not a figment of my imagination, one 
would hope that Office 365 would not set feedback in this case.)


3. Would O365 do DMARC checks for internal emails ie. O365 tenant employee to 
another O365 tenant employee? And would it send DMARC reports in this case?

Yes and hopefully yes.

- 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)

Re: [dmarc-discuss] Mimecast and Office 365

2018-04-12 Thread Roland Turner via dmarc-discuss

On 11/04/18 22:07, Ivan Kovachev via dmarc-discuss wrote:


Hello guys,

I have three questions for you that I am unsure about and hoping that 
someone at Microsoft will be able to help:


First two questions are related to Mimecast acting as inbound security 
gateway to O365:


1. When Mimecast acts as inbound gateway solution and it receives an 
email, it does DMARC checks and lets the email through to O365 
environment. Even if an email passes DMARC checks at Mimecast and the 
email is let through, then O365 also seems to also be doing DMARC 
checks but both SPF and DKIM fail because of the change that Mimecast 
does. As a results DMARC fails. My questions is, what is the best 
practice here in this scenario? Is there a way to turn off DMARC 
checks at O365? Mimecast suggest that it is whitelisted in O365 but 
that means that all the spam will be let through as well.


DMARC checking should only occur at the host referred to be the MX 
record as SPF is still relevant for at least some email. I believe 
Office 365 has a trusted inbound relays option (i.e. Office 365 trusts 
the specified hosts to filter their email) although I can't quickly find it.


Mimecast is apparently unwilling to change their service to stop 
damaging incoming messages that don't breach the policies being enforced 
(they unconditionally unpack and then repack every message, rather than 
only those whose contents they have reason to modify).


2. Would O365 send DMARC reports back to the sender in the above case? 
And, if O365 sends DMARC reports back to the sender then emails will 
be shown as originating from Mimecast but failing DMARC.


Yes and yes if you've not listed Mimecast as a trusted inbound relay. 
(Assuming that the trusted inbound relays setting is not a figment of my 
imagination, one would hope that Office 365 would not set feedback in 
this case.)


3. Would O365 do DMARC checks for internal emails ie. O365 tenant 
employee to another O365 tenant employee? And would it send DMARC 
reports in this case?


Yes and hopefully yes.

- 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)

Re: [dmarc-discuss] Mimecast and Office 365

2018-04-11 Thread A. Schulze via dmarc-discuss


Am 11.04.2018 um 16:07 schrieb Ivan Kovachev via dmarc-discuss:
> Hello guys,
> 
> I have three questions for you that I am unsure about and hoping that someone 
> at Microsoft will be able to help:
> 
> First two questions are related to Mimecast acting as inbound security 
> gateway to O365:
> 
> 1. When Mimecast acts as inbound gateway solution and it receives an email, 
> it does DMARC checks and lets the email through to O365 environment. Even if 
> an email passes DMARC checks at Mimecast and the email is let through, then 
> O365 also seems to also be doing DMARC checks but both SPF and DKIM fail 
> because of the change that Mimecast does. As a results DMARC fails. My 
> questions is, what is the best practice here in this scenario? Is there a way 
> to turn off DMARC checks at O365? Mimecast suggest that it is whitelisted in 
> O365 but that means that all the spam will be let through as well.

Hello Ivan,

I'm unrelated to the companies but had a similar issue.
A customer use a domain hosted at Mimecast and forward to us. DMARC validation 
failed for a portion of messages sent from p=reject domains.
I had to disable "reject on DMARC fail" for the servers sending from Mimecast 
to us. That's fragile as Mimecast may change them at any time.

Andreas
___
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)


[dmarc-discuss] Mimecast and Office 365

2018-04-11 Thread Ivan Kovachev via dmarc-discuss
Hello guys,

I have three questions for you that I am unsure about and hoping that someone 
at Microsoft will be able to help:

First two questions are related to Mimecast acting as inbound security gateway 
to O365:

1. When Mimecast acts as inbound gateway solution and it receives an email, it 
does DMARC checks and lets the email through to O365 environment. Even if an 
email passes DMARC checks at Mimecast and the email is let through, then O365 
also seems to also be doing DMARC checks but both SPF and DKIM fail because of 
the change that Mimecast does. As a results DMARC fails. My questions is, what 
is the best practice here in this scenario? Is there a way to turn off DMARC 
checks at O365? Mimecast suggest that it is whitelisted in O365 but that means 
that all the spam will be let through as well.

2. Would O365 send DMARC reports back to the sender in the above case? And, if 
O365 sends DMARC reports back to the sender then emails will be shown as 
originating from Mimecast but failing DMARC.

3. Would O365 do DMARC checks for internal emails ie. O365 tenant employee to 
another O365 tenant employee? And would it send DMARC reports in this case?


___
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)