Troubleshooting email flow issue

[Dashrender]

Here's most if not all of the header

Delivered-To: [email protected]
Received: by 2002:a0c:a265:0:0:0:0:0 with SMTP id f92csp1104939qva;
        Fri, 13 Dec 2019 10:03:09 -0800 (PST)
X-Google-Smtp-Source: APXvYqz8LlpLnBWm7NYYOdjCpnynong9bH4pRDDsORsxhFuJ2Vt33B7pACd4JUJHkGTCf7N2OPck
X-Received: by 2002:a17:902:b702:: with SMTP id d2mr628196pls.134.1576260189568;
        Fri, 13 Dec 2019 10:03:09 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1576260189; cv=none;
        d=google.com; s=arc-20160816;
        b=cVteAcqekbphlQDnkn7ZrEmg8vL1ZlIuEfqJR3nVad8NSYXNmIeHcGT/ZDbNCEpvSk
         5hU3m2HI7/V1iQQ3Q+xS/UNKwa8W9bpDcH91JhLcEcqiNUZ6clzF25MEPcOD/16sqmy3
         VNNwhqq8rWqhfajJaV7aX0S7e4D+h2eTwQ5+9+WfNloXi96pp85dnjGSQfRBAq9Cnk6y
         WcOGRMaMoFNOECv7rmnKpImGaLozXSmZyGdeCbxtsLlYBhdJm2cOkTrdADmyHDyfSifw
         SYBSxt7jStgvTFmonxbLIcX2UxB5JBD+zQ/kkZZUyPpMqVSPTLUqqKk3KGKTo0dSXM6F
         ImAg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=list-unsubscribe:mime-version:subject:message-id:to:reply-to:from
         :date:dkim-signature:dkim-signature;
        bh=NLN0Rntz+uy9J/0mJNjxiYspQe2bno4WihjicDA3IrM=;
        b=CiocJm/o0FVOoWD4l0l4XHAQaDWuLJuXJXcY2xEY1FjVV1+VXCeRZ2ZAhNe5vBoinL
         hJmiVLMi+Bz5Lq86cYZ1Oije+LWqlHWzovL7fj9iXm8kfeJJEYkGbZHLSGt2ErXOabkS
         xhiUlxKaLva1eKRfHaWplE+BZJrcj1pkbcpmj/ZDnqjqB9pdiKxlEq0o0jmgM6RKGilW
         Rx+A46J275GZckSOFnff3HyMrr7BZne+R9Alg9u4IeoyqECnK9OSPiAlOYQcL5BETDYn
         3KURnMxdzhN35Vgkjt/XPUCIPF4ILME00MaRiTXNzk8JR89eqAZv5xoQ8CiuuwbyVOEv
         B1Zw==
ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass [email protected] header.s=m1 header.b=SvsTPKB2;
       dkim=pass [email protected] header.s=m1 header.b="E5/o2S0z";
       spf=pass (google.com: domain of [email protected] designates 199.15.215.81 as permitted sender) smtp.mailfrom=763-DVL-293.0.68121.0.0.9255.9.180510@em-sj-77.mktomail.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=copper.com
Return-Path: <[email protected]>
Received: from em-sj-81.mktomail.com (em-sj-81.mktomail.com. [199.15.215.81])
        by mx.google.com with ESMTPS id j32si8659355pgb.289.2019.12.13.10.03.08
        for <[email protected]>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Fri, 13 Dec 2019 10:03:09 -0800 (PST)
Received-SPF: pass (google.com: domain of [email protected] designates 199.15.215.81 as permitted sender) client-ip=199.15.215.81;
Authentication-Results: mx.google.com;
       dkim=pass [email protected] header.s=m1 header.b=SvsTPKB2;
       dkim=pass [email protected] header.s=m1 header.b="E5/o2S0z";
       spf=pass (google.com: domain of [email protected] designates 199.15.215.81 as permitted sender) smtp.mailfrom=763-DVL-293.0.68121.0.0.9255.9.180510@em-sj-77.mktomail.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=copper.com
Return-Path: <[email protected]>
X-MSFBL: VOmIfBN5+LvoqxVl+7LGSVw8iOoINuu7rqB3YJYCWNQ=|eyJ1IjoiNzYzLURWTC0 yOTM6NTk2MjoxMTM3NDo1ODk2NjowOjkyNTU6OTo2ODEyMToxODA1MTAiLCJnIjo iYmctc2otMDEiLCJiIjoiZHZwLTE5OS0xNS0yMTUtODEiLCJyIjoicnluZUBzdHJ hZGFoZWFsdGhjYXJlLmNvbSJ9
Received: from [10.0.87.249] ([10.0.87.249:60934] helo=sjmas04.marketo.org) by sjmta22.marketo.org (envelope-from <[email protected]>) (ecelerity 4.2.38.62370 r(:)) with ESMTP id 06/F1-16685-C52D3FD5; Fri, 13 Dec 2019 12:03:08 -0600
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1576260188; s=m1; d=copper.com; [email protected]; h=Date:From:To:Subject:MIME-Version:Content-Type; bh=NLN0Rntz+uy9J/0mJNjxiYspQe2bno4WihjicDA3IrM=; b=SvsTPKB2DNtHEjYP5ddkpgLCTGtT0cljyKPG+I3SV+M5eo0YGyc+t7DJTyYrPQZa dS8Y6GWeMX05XoDBmY1dezmYneaevvmyEiuP6x5z7hUZS7gKYTQv6l8ebO95Sxeix++ HKJVBACTzozWc38GH+bWL81VUtjRtF8YZEjzj17g=
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1576260188; s=m1; d=mktomail.com; [email protected]; h=Date:From:To:Subject:MIME-Version:Content-Type; bh=NLN0Rntz+uy9J/0mJNjxiYspQe2bno4WihjicDA3IrM=; b=E5/o2S0zzmK69PrnxsF61UVEep/MlQfyyBebW+RaEuphhPEliiu5z/JXPGfW+PW3 cy+mc6Vwk13nNetesIKJ6n965gtmxKDTIkNQtIx2tIMmsyEXD0CB+M/O1TSVPJhwugM QXCuHyYr8S9HkRqfU+tw4Sz9W+qv4uQpa3m9gMvU=
Date: Fri, 13 Dec 2019 12:03:08 -0600 (CST)
From: Jenna from Copper <[email protected]>
Reply-To: [email protected]
To: [email protected]
Message-ID: <1806479636.953825638.1576260188788.JavaMail.mktmail@sjmas04.marketo.org>
Subject: Let's get prepped for 2020
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_953825637_790734750.1576260188788"
X-Binding: bg-sj-01
X-MarketoID: 763-DVL-293:5962:11374:58966:0:9255:9:68121:180510
X-MktArchive: false
List-Unsubscribe: <mailto:INCVQRCWFVZTG5DHPBFWO6CWJIZWSV2UNVTT2PI.68121.9255.9@unsub-sj.mktomail.com>
X-Mailfrom: [email protected]
X-MSYS-API: {"options":{"open_tracking":false,"click_tracking":false}}
X-MktMailDKIM: true

------=_Part_953825637_790734750.1576260188788

[Dashrender]

I sent a few test messages from my personal gmail account to [email protected] and they did not show up in the G Suite account - I haven't heard from my user yet, I'm assuming he got them over on O365.

[Dashrender]

if this is spam email coming from google's own platform - I suppose I could see them not actually checking the MX record, and instead just looking at google's own records - sees this G Suite account for the domain in question, and poof - the message stays in google's platform and is delivered there.

Though why Google would treat this spam different than emails coming from their own gmail system is something I don't understand. (now ready to hear why it totally makes sense )

Thoughts?

[Dashrender]

Pretty sure I figured it out.

The domain in question had 2 MX records,

1. O365
2. gmail

O365 has the higher priority, and there have never been any complaints of missing messages.

I'm assuming this spam made it to google, because I know some spammers specifically use the secondary, etc MX records in hopes of bypassing spam filters. So I'm assuming that's what was happening here.

Now that said - I did see a single Twitter email in the G Suite - so I'm guessing there was glitch at O365 once, and Twitter hit it and tried the secondary...

[dbeato]

@Dashrender said in Troubleshooting email flow issue:

if this is spam email coming from google's own platform - I suppose I could see them not actually checking the MX record, and instead just looking at google's own records - sees this G Suite account for the domain in question, and poof - the message stays in google's platform and is delivered there.

Though why Google would treat this spam different than emails coming from their own gmail system is something I don't understand. (now ready to hear why it totally makes sense )

Thoughts?

Most of the time, if you have a domain in the same system as a big platform as G-suite or Office 365, the email will be routed internally instead of looking at an MX record. This happens with Exchange same with other email systems because it looks internal before going to do a DNS lookup.

[JaredBusch]

@dbeato said in Troubleshooting email flow issue:

@Dashrender said in Troubleshooting email flow issue:

if this is spam email coming from google's own platform - I suppose I could see them not actually checking the MX record, and instead just looking at google's own records - sees this G Suite account for the domain in question, and poof - the message stays in google's platform and is delivered there.

Though why Google would treat this spam different than emails coming from their own gmail system is something I don't understand. (now ready to hear why it totally makes sense )

Thoughts?

Most of the time, if you have a domain in the same system as a big platform as G-suite or Office 365, the email will be routed internally instead of looking at an MX record. This happens with Exchange same with other email systems because it looks internal before going to do a DNS lookup.

I have O365 in mid migration for a client right now. All email from Microsoft admin portal such as password reset follow MX records. Which means they go to the on prem server still. No AD sync or anything on this. Making a clean cut away fromthe local AD for O365.

[Dashrender]

@dbeato said in Troubleshooting email flow issue:

@Dashrender said in Troubleshooting email flow issue:

if this is spam email coming from google's own platform - I suppose I could see them not actually checking the MX record, and instead just looking at google's own records - sees this G Suite account for the domain in question, and poof - the message stays in google's platform and is delivered there.

Though why Google would treat this spam different than emails coming from their own gmail system is something I don't understand. (now ready to hear why it totally makes sense )

Thoughts?

Most of the time, if you have a domain in the same system as a big platform as G-suite or Office 365, the email will be routed internally instead of looking at an MX record. This happens with Exchange same with other email systems because it looks internal before going to do a DNS lookup.

actually, this is not true - and I'm thankful it's not. My tests proved that it was true, because my gmail based tests made it to O365.

[Obsolesce]

@Dashrender said in Troubleshooting email flow issue:

I'm wondering - does the 10. address imply that this server is internal a google?

No it's saying the email originated from that server.

[dbeato]

@JaredBusch said in Troubleshooting email flow issue:

@dbeato said in Troubleshooting email flow issue:

@Dashrender said in Troubleshooting email flow issue:

if this is spam email coming from google's own platform - I suppose I could see them not actually checking the MX record, and instead just looking at google's own records - sees this G Suite account for the domain in question, and poof - the message stays in google's platform and is delivered there.

Though why Google would treat this spam different than emails coming from their own gmail system is something I don't understand. (now ready to hear why it totally makes sense )

Thoughts?

Most of the time, if you have a domain in the same system as a big platform as G-suite or Office 365, the email will be routed internally instead of looking at an MX record. This happens with Exchange same with other email systems because it looks internal before going to do a DNS lookup.

I have O365 in mid migration for a client right now. All email from Microsoft admin portal such as password reset follow MX records. Which means they go to the on prem server still. No AD sync or anything on this. Making a clean cut away fromthe local AD for O365.

I see, but to be more specifically. Try sending an email account from within Office 365 to the same domain. It will not go through the MX records one. What you are saying is that Microsoft notifications would go from Microsoft to the domain MX records while anything within the domain in Office 365 won't follow the same.

[JaredBusch]

@dbeato said in Troubleshooting email flow issue:

I see, but to be more specifically. Try sending an email account from within Office 365 to the same domain.

Not true. Our domain bundystl.com is on O365 and all my email to users went to the on prem server.

[JasGot]

@Dashrender said in Troubleshooting email flow issue:

Pretty sure I figured it out.

The domain in question had 2 MX records,

1. O365
2. gmail

O365 has the higher priority, and there have never been any complaints of missing messages.

I'm assuming this spam made it to google, because I know some spammers specifically use the secondary, etc MX records in hopes of bypassing spam filters. So I'm assuming that's what was happening here.

Now that said - I did see a single Twitter email in the G Suite - so I'm guessing there was glitch at O365 once, and Twitter hit it and tried the secondary...

Often, spammers will send mail to a higher MX record on purpose. There are many reason they do this, Less protected routes to a gullible user is one of them.