Trouble Sending to Gmail / Google Workspace domains
Hello, we have been having ongoing issues sending to gmail or Google workspace addresses for months now. I know that Google tightened up their requirement so domains had to have solid SPF, DKIM and DMARC setup, which we do and always have. We've worked around the issue all this time by using a connector and mail flow rule in Exchange online. This has worked OK, but every time we run into a new company we are dealing with that uses Google for email, we need to manually add them to the rule. This has lead to some problems and is disruptive and of course I fear that it may break at some point. We've registered our domain with the Google postmaster tools and it's verified there. We've opened tickets with Google months ago and get no response. Microsoft support tells us everything is fine on our end and it's Google's issue. This is the error we get: Error: 550 5.7.350 Remote server returned message detected as spam -> 550 5.7.1 [2a01:111:f403:2412::72e 19] Gmail 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. For more information, go to; https://support.google.com/mail/answer/188131 98e67ed59e1d1-2e059080a69si2208538a91.116 - gsmtp Message rejected by: mx.google.com There is no spamming or anything coming out of our domain and we have a very small volume of email. Online checks of our domain don't show any reputation issues or blacklists. I've seen I think dozens of other people complaining about this issue, but don't really see any actual solution other than the email connector workaround. Anyone have any suggestions? Thanks!Exchange Online Adds Delicensing Resiliency
Microsoft announced Delicensing Resiliency, a new feature for tenants with over 10,000 paid seats, to avoid inadvertent data loss due to licensing errors. Essentially, the feature adds an extra 30-day grace period post license removal during which mailboxes work as normal. The idea is that administrators will have extra time to detect and fix licensing errors that lead to mailbox removal. Overall, the new feature seems like a great idea (for large tenants). https://office365itpros.com/2024/11/06/delicensing-resiliency-exo/
Error 554 5.7.5 Permanent error evaluating DMARC policy
Recently ran into this error when sending email from our domain. Could not find much help about this error so posting my solution as a reference. What ended being a problem is DMARC recodrd in DNS Our record was: v=DMARC1; p=none; rua=mailto:Demarc@onmicrosoft.com; ruf=mailto:Demarc_forensic@onmicrosoft.com; fo=1:d:s. The problem was period(dot) at the end of the record, after removing period and DNS repopulated, everything worked! Corrected record: v=DMARC1; p=none; rua=mailto:Demarc@onmicrosoft.com; ruf=mailto:Demarc_forensic@onmicrosoft.com; fo=1:d:s
Setting up rules on Outlook for Android for outgoing messages
Hello there! I'd like to ask for your help as one of our users would like all outgoing messages, sent from her mobile device to be copied into her Inbox once sent so she can remember to categorize these messages. I haven't been able to set up rules that would handle this neither on Outlook.com, Android Outlook or the Outlook App. Does any of you have an idea how this could be done? Thank you so much in advance. GáborEmail not being delivered to M365 and being forwarded back on-prem
Hi All Hopefully I can explain the issue given it is a bit puzzling and a complex setup. We have 2 environments/tenants. contosedev.com for dev work and contoso.com for production. We have an on-prem Exchange 2019 infrastructure for contosodev.com and a on-prem Exchange 2016 infrastructure for contoso.com. Between the on-prem environment we have an Exchange 2019 edge server (not AD Sync'd) for each environment (dev and production) that takes email from on-prem and sends to M365. The on-prem Exchange server has a send connector that routes email destined for contosodev.mail.onmicrosoft.com (dev) or contoso.mail.onmicrosoft.com (production) via these edge servers. The edge servers have a receive connector to take this email and a send connector to then send on to M365. The connectors use certificate validation in each case. The M365 tenants have an inbound connector to receive this email also with certificate validation. All connectors are setup the same apart from the obvious difference in domains. The tenants are authoritative for their respective domains. For dev contosodev.com & contosodev.mail.onmicrosoft.com (and also the default contosodev.onmicrosoft.com). For production contoso.com & contoso.mail.onmicrosoft.com (and also the default contoso.onmicrosoft.com). The tenants have outbound connectors to route all email via on-premise Exchange servers. So any email in M365 for say contosodev.com (dev) and contoso.com (production) get routed to the outbound connector and hence on-prem Exchange where they can either be delivered locally or if it an external address they are routed out via our gateway infrastructure. Each tenant has a test mailbox (shared). The mailbox has been migrated from the on-prem infrastructure to M365. Each has email addresses of contosodev.mail.onmicrosoft.com & contosodev.com for the dev environment and contoso.mail.onmicrosoft.com & contoso.com for production. Now the puzzling bit. In the dev environment, if I send an email from an on-prem mailbox to email address removed for privacy reasons, Exchange on-prem sees this as a remote mailbox and sends the email via the edge servers. It arrives in M365, sees it has a mail.onmicrosoft.com address and is delivered successfully to the test mailbox. In the production environment, If I send an email from an on-prem mailbox to email address removed for privacy reasons, Exchange on-prem sees this as a remote mailbox and sends the email via the edge servers. It arrives in M365, sees it has a mail.onmicrosoft.com address, but instead of delivering it to the mailbox, it then routes it back to on-prem using the contoso.com address, which then causes a mail loop that eventually fails. The message trace seems to indicate the email is being forwarded, however there are no forward rules or inbox rules. I've even tried another completely blank mailbox that I migrated to M365 with the same result. Now I've been over the config of both environments, looked at various articles in regards to attribution, but cannot see any difference between what I've setup in the dev environments vs the production one. I just can't work out why, when the mailbox obviously exists in M365 with all the correct email addresses, it just doesn't get delivered. M365 seems to ignore that and decide to send it out via the outbound connector. The other weird part is if I disable that outbound connector in M365, the email is delivered to the mailbox correctly! Anyway, lengthy I know and hopefully have explained the infrastructure, so if anyone has any ideas where I might check next it would be greatly appreciated. Cheers Peter
Microsoft Update Affects How Wildcards Work with Dynamic Distribution Groups
It's time to check recipient filters for dynamic distribution groups to ensure that you don't have any wildcard prefixes used with the -eq operator to find recipients based on their email addresses. A November 30 update will stop this kind of recipient filter working, and might have a knock-on effect on other processes. https://practical365.com/dynamic-distribution-group-wildcard/
