Email Relay Issue.

Sanjay Bhakuni - admin 145

We are using Option 3: Configure a connector to send emails using Microsoft 365 or Office 365 (SMTP relay) using Configure a TLS certificate-based connector to relay email through Microsoft 365 or Office 365https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365

I want to know if we have to add the sending IP of on premises or application in SPF record of our domain to avoid having messages flagged as spam or do we have any other settings to bypass the spam filter for internal emails. Correct me if I am wrong, SPF is only required for email sending to external.

Mike Hu-MSFT 4,140 Reputation points Microsoft Vendor

2024-09-10T05:54:36.54+00:00

Any updates so far? If you have solved your problem, could you share with us? Maybe it will help more people with similar problems. Don't forget to mark it as answer, this will be easy for other community members to find the useful one.
Mike Hu-MSFT 4,140 Reputation points Microsoft Vendor

2024-09-12T09:53:49.0833333+00:00

It's been a while since the last update. Do you need more help from me? If so, please feel free to contact me.

In addition, if the following answer is helpful to you, you can mark it as an answer, which will help the community. Thank you for your understanding.

1 answer

Andy David - MVP 149.2K Reputation points MVP

2024-09-05T18:39:41.7466667+00:00
Adding the IP to SPF should be enough as long as you also meet that criteria:

Configure your setup only when you have fulfilled either of the following conditions:

Sender domain: Ensure that the sender domain belongs to your organization (that is, you've registered your domain in Microsoft 365). For more information, see Add a domain to Microsoft 365.

Certificate-based connector configuration: Ensure that your on-premises email server is configured to use a certificate to send email to Microsoft 365, and the Common-Name (CN) or Subject Alternate Name (SAN) in the certificate contains a domain name that you have registered in Microsoft 365, and you have created a certificate-based connector in Microsoft 365 that has that domain.
Please sign in to rate this answer.
Sanjay Bhakuni - admin 145 Reputation points

2024-09-06T03:24:36.8766667+00:00

hello @Andy David - MVP , I have another question which i have asked in my other thread.

Here, in our scenario IPs are not added in SPF and emails coming via SMTP relay from on premises connector are falling SPF, DKIM and DMARC, but still showing SCL: 1 and reaching to the inbox of the internal user. I want to know how it is possible. Are there any other settings which are allowing those emails and bypassing spam filter and even DMARC getting failed, but still emails are reaching to inbox.

Mike Hu-MSFT 4,140 Reputation points Microsoft Vendor

2024-09-06T09:30:14.78+00:00

@Sanjay Bhakuni - admin Based on my experience, the IP address of your on-premises server might be on an allow list within the Exchange Online Protection (EOP) settings. This can cause the emails to bypass certain spam checks. To check this, go to the Security & Compliance Center and review the IP Allow List settings.

Andy David - MVP 149.2K Reputation points MVP

2024-09-06T09:45:41.6166667+00:00

1 or -1? -1 means it bypassed SPAM checks. Note that if you are using a connector configured correctly, you will prob still see these delivered.

Sanjay Bhakuni - admin 145 Reputation points

2024-09-06T10:09:24.7+00:00

It is SCL: 1 and SPF, DKIM and DMARC are getting failed. i have read in one of MS article.

https://techcommunity.microsoft.com/t5/exchange-team-blog/demystifying-and-troubleshooting-hybrid-mail-flow-when-is-a/ba-p/1420838

From a hybrid mail flow perspective, there is an important header which we often check in security assessment situation or any spam, spoof, or phish analysis called: X-MS-Exchange-Organization-AuthAs. We should focus on two possible values of that header: Internal or Anonymous.

Messages are considered Internal if they authenticated in some manner:

Authenticated mailbox on-prem or Exchange Online (StoreDriver)

Authenticated mailbox using SMTP client submission (SMTP AUTH)

Received through an on-prem receive connector with ExternalAuthoritative (Externally Secured) permission enabled

Came into Exchange Online via an inbound connector with TreatMessagesAsInternal set to “true” and the sender is an accepted domain.

I am getting in header Exchange-Organization-AuthAs : Internal and found this setting in on-premises connector.

Received through an on-prem receive connector with ExternalAuthoritative (Externally Secured) permission enabled

Is this setting allowing those emails and ignoring SPF, DKIM and DMARC and making SCL:1.

Sanjay Bhakuni - admin 145 Reputation points

2024-09-06T10:36:27.6333333+00:00

@Mike Hu-MSFT , the IP address of our on-premises server are not allowed in EOP.

It is SCL: 1 and SPF, DKIM and DMARC are getting failed. i have read in one of MS article.

https://techcommunity.microsoft.com/t5/exchange-team-blog/demystifying-and-troubleshooting-hybrid-mail-flow-when-is-a/ba-p/1420838

From a hybrid mail flow perspective, there is an important header which we often check in security assessment situation or any spam, spoof, or phish analysis called: X-MS-Exchange-Organization-AuthAs. We should focus on two possible values of that header: Internal or Anonymous.

Messages are considered Internal if they authenticated in some manner:

Authenticated mailbox on-prem or Exchange Online (StoreDriver)

Authenticated mailbox using SMTP client submission (SMTP AUTH)

Received through an on-prem receive connector with ExternalAuthoritative (Externally Secured) permission enabled

Came into Exchange Online via an inbound connector with TreatMessagesAsInternal set to “true” and the sender is an accepted domain.

I am getting in header Exchange-Organization-AuthAs : Internal and found this setting in on-premises connector.

Received through an on-prem receive connector with ExternalAuthoritative (Externally Secured) permission enabled

Is this setting allowing those emails and ignoring SPF, DKIM and DMARC and making SCL:1.It is SCL: 1 and SPF, DKIM and DMARC are getting failed. i have read in one of MS article.

https://techcommunity.microsoft.com/t5/exchange-team-blog/demystifying-and-troubleshooting-hybrid-mail-flow-when-is-a/ba-p/1420838

From a hybrid mail flow perspective, there is an important header which we often check in security assessment situation or any spam, spoof, or phish analysis called: X-MS-Exchange-Organization-AuthAs. We should focus on two possible values of that header: Internal or Anonymous.

Messages are considered Internal if they authenticated in some manner:

Authenticated mailbox on-prem or Exchange Online (StoreDriver)

Authenticated mailbox using SMTP client submission (SMTP AUTH)

Received through an on-prem receive connector with ExternalAuthoritative (Externally Secured) permission enabled

Came into Exchange Online via an inbound connector with TreatMessagesAsInternal set to “true” and the sender is an accepted domain.

I am getting in header Exchange-Organization-AuthAs : Internal and found this setting in on-premises connector.

Received through an on-prem receive connector with ExternalAuthoritative (Externally Secured) permission enabled

Is this setting allowing those emails and ignoring SPF, DKIM and DMARC and making SCL:1.

Andy David - MVP 149.2K Reputation points MVP

2024-09-06T11:01:29.2866667+00:00

Yes, if the connector is externally secured, you are essentially telling Exchange its authenticated and it bypasses SPAM checks. I would still add your on-prem IPs of the sending servers to the SPF record to ensure that ExO authenticates the connections
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Email Relay Issue.

1 answer

Your answer