Emails being blocked by Gmail from office 365

Anonymous
2023-03-02T23:25:26+00:00

When the emails is sent to gmail its being blocked stating

Delivery has failed to these recipients or groups:

___@___.___ (***********@gmail.com)

Your message wasn't delivered because the recipient's email provider rejected it.

all my records are up to date..

gmail.com suspects your message is spam and rejected it.

natasha.daniel Office 365 gmail.com
Sender Action Required
<br> --- --- --- --- ---
Messages suspected as spam
How to Fix It
Try to modify your message, or change how you're sending the message, using the guidance in this article: Bulk E-mailing Best Practices for Senders Using Forefront Online Protection for Exchange. Then resend your message.
If you continue to experience the problem, contact the recipient by some other means (by phone, for example) and ask them to ask their email admin to add your email address, or your domain name, to their allowed senders list.

Was this helpful?Send feedback to Microsoft.


More Info for Email AdminsStatus code: 550 5.7.350

When Office 365 tried to send the message to the recipient (outside Office 365), the recipient's email server (or email filtering service) suspected the sender's message is spam.

If the sender can't fix the problem by modifying their message, contact the recipient's email admin and ask them to add your domain name, or the sender's email address, to their list of allowed senders.

Although the sender may be able to alter the message contents to fix this issue, it's likely that only the recipient's email admin can fix this problem. Unfortunately, Office 365 Support is unlikely to be able to help fix these kinds of externally reported errors.

Original Message Details

Created Date: 3/2/2023 11:29:38 PM
Sender Address: *********@*****.com
Recipient Address: *********@gmail.com
Subject: Email check

Error Details

Reported error: 550 5.7.350 Remote server returned message detected as spam -> 550 5.7.1 [2a01:111:f403:700f::715 19] Our system has detected that this;message is likely suspicious due to the very low reputation of the;sending domain. To best protect our users from spam, the message has;been blocked. Please visit; https://support.google.com/mail/answer/188131 for more information. c23-20020aa7c997000000b004ace5dc6b61si945041edt.369 - gsmtp
DSN generated by: PN3P287MB0113.INDP287.PROD.OUTLOOK.COM
Outlook | Windows | Classic Outlook for Windows | For home

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments No comments

100 answers

Sort by: Newest
  1. Anonymous
    2023-09-30T20:33:34+00:00

    5 weeks and Microsoft support couldn't give me an answer.

    This post is the solution. How do we get this marked as the answer so people don't waste hours and hours like I did.

    Please can I thank you for your detailed explanation.

    Best regards

    Rich

    Was this answer helpful?

    3 people found this answer helpful.
    0 comments No comments
  2. Anonymous
    2023-09-25T22:25:45+00:00

    Not saying Google is messing up, but they can accept emails from IPv6 addresses, so long as they resolve to an address that matches an entry in your SPF list.

    Google will reject emails from any source (IPv4 or IPv6) that does not resolve correctly. This is due to them trying to reduce the amount of spam,

    We use other mailers in our environment, they send from IPv6 addresses as well and they have no issues with sending emails to Google.

    Forcing it to use IPv4 forces it to use an address that resolves correctly and thinks work.

    Was this answer helpful?

    0 comments No comments
  3. Deleted

    This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.


    Comments have been turned off. Learn more

  4. Anonymous
    2023-09-25T17:43:54+00:00

    Questions.

    1. Are you using O365 to host your domain/email?
    2. If yes to #1, are you using Forcepoint to scan email inbound AND outbound?
    3. If yes to #2, there are two parts to this equation.
    • a. Inbound from remote domains to Forcepoint (which should be the MX record for your domain) and then it relays it to the O365 instance.
    • b. Outbound from O365 to Forcepoint for *All* email (which is where your connector would be).
    • c. Forcepoint is the responsible party to deliver emails to gmail.
    1. It would be 3b and 3c that you would need to be concerned about.
    • a. You need to make sure that your SPF record includes both the O365 AND Forcepoint statements.
    • b. You will need to check with Forcepoint to verify if they are sending to gmail using IPv6 enabled servers.
    • c. If they are, then you need to ask them how to force a connection to Gmail using IPv4.

    With that said, IF you are using O365 and NOT using Forcepoint for outbound email scanning, then you need to just set up an connector in O365 that was previously described.

    Does that make sense?

    Was this answer helpful?

    0 comments No comments
  5. Anonymous
    2023-09-25T17:34:13+00:00

    <Off topic Content removed by Moderator>

    The IPv6 addresses coming from MSFT being presented to Google, are properly returned in their include record, and yes are correct (as I stated before).

    The issue is that Google is "NOT" interpreting the IPv6 addresses correctly in their proprietary implementation of SPF checking.

    Am not sure how else to explain it. To say that it is not Google messing up is simply not correct. Any service using IPv6 to send mail to google/gmail, is going to bounce back. Only IPv4 IPs are passing Gmail SPF checks. This is not limited to MSFT servers. It's any server that is being routed on the global IPv6 mbone.

    If you notice that when you force it over IPv4, the source FQDN of the O365 servers is VERY different.

    Was this answer helpful?

    0 comments No comments