They should all be including a record you control rather than listing the IP
directly.
The point of the include directive is to prevent situations like this.
> On 22 May 2019, at 3:22 pm, Martin - StudioCoast
> wrote:
>
> We tried that initially, however it is a shared hosting server and a
We tried that initially, however it is a shared hosting server and a lot
of sites on it have SPF records listing the IP which we don't have
access to, so we're a bit stuck at the moment
short of contacting all the customers to manually change their SPF!
On 22/05/2019 1:48 pm, Bradley Amm
ct: Re: [AusNOG] Office365 Exchange Security contact
In this case, the email messages are delivered correctly into the Office365
network for domains hosted by Office365.
(Our logs show the outlook.com MX records accepting delivery)
The problem is happening internal to their network, where a rogu
In this case, the email messages are delivered correctly into the
Office365 network for domains hosted by Office365.
(Our logs show the outlook.com MX records accepting delivery)
The problem is happening internal to their network, where a rogue mail
flow rule for one customer is rerouting all
Martin,
Just so we're all on the same page, email routing is never directly related
to IP allocations, it's MX bound if properly standards compliant. And if
the canonical MX record is directing to the alternate customer, the problem
lies with DNS not email.
Kind regards
Paul Wilkins
On Tue, 21
Been there, done that. The support responses I have received show a lack
of understanding of the issue unfortunately...
On 21/05/2019 8:16 am, Greg Lipschitz wrote:
Hi Martin
The best way to get Office 365 support is log in to the portal as the
tenancy administrator and open a support
Hi all,
Does anyone have a contact on the Office365/Exchange security team?
The issue we are seeing is any emails sent from one of our IPs to any
Office365 customer ends being hijacked and routed to a completely
different, unrelated Office365 customer.
Looks like they have a global mail flow
