Emails being blocked by Gmail from office 365

My apologies Pavlína for being blunt (and this goes for everyone complaining about MSFT); but all because it is "hosted in the cloud" does not mean it does not require an understanding of how email servers works.

Having an "Exchange Server" (which is what O365 is) in the "cloud" is no different than building a machine in your home, (1) installing windows server on it, (2) make it a domain controller, (3) then install microsoft exchange server on it, (4) configure it for mail functions, and then finally (5) create mailboxes and users, and anything else that is not a default.

MSFT just took steps 1-4 away by doing that heavy lifitng work for you. You still need to do step 5 as well as DNS entries (which even then they have tools for that).

SO! If you are expecting them to do ALL the work for you, then do NOT use a hosted exchange service for a custom domain name. Get yourself a free personal gmail/yahoo/aol/hotmail address if you do not want to have to deal with any sort of work getting your email to work.

Again, sorry for being blunt, but this is a pet peeve of mine for people blaming others for their own lack of responsibility or knowledge.

Michael B. Morell, CISSP #431307 CCSK (he/him/his/sir)

DirectionWeb

Owner and Information Security Professional

@Pavlína Kvapilová,

The issue you are seeing has to do with using the country domain outlook.cz. There is a Known Issue posted about it at the top of the list for Outlook.com known issues, Fixes or workarounds for recent issues on Outlook.com - Microsoft Support. A workaround would be to create an Outlook.com alias such as ******@outlook.com and when you send to Gmail click the From drop down and send from that domain.

Issue: Your O365 hosted email bounces back as SPAM from any g-mail/google hosted domain.

SOLUTION: Create a DMARC record for your domain

The "TRUE" solution is to add a DMARC record to your domains DNS records.

The thread that keeps on keeping on...

@Michael B. I totally agree every domain should have a DMARC but I still do not agree this is the root cause of this issue. Why?

As stated here "Messages that aren’t authenticated with these methods might be marked as spam or rejected with a5.7.26error." Email sender guidelines - Google Workspace Admin Help

I would expect to see this error message or one of the others listed under 5.7.26.

5.7.26 This mail has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM. Authentication results: DKIM = did not pass SPF [domain-name] with ip: [ip-address] = did not pass. For instructions on setting up authentication, go to Email sender guidelines. 

NOT

The bounce clearly states that the sending domain has a very low reputation. In simple terms this means that google has seen the domain relaying spam or other reputation related triggers. Granted having a DMARC record might help the domain reputation but in my opinion it's not the root cause of the issue but that's just my 2 cents.

Br.

Joshua

P.S. RUF is not recommended if you are in the EU as it is not GDPR compliant. It's also important to note, if you use RUF or RUA you should use a email address with the same domain unless you setup some wildcard DNS responders like all DMARC reporting services.

I understand the workaround, but that is exactly what it sounds like "a workaround" not a permanent fix. The workaround of NOTE is by adding an OUTLOOK.COM alias which that domain has a good reputation and be sent from. That is NOT a fix, that is a band-aid.

The PERMAMENT fix for ALL CUSTOM DOMAINs IS below.

ALL domains need to have very specific items to be RFC 2142 complaint. That is: abuse@, postmaster@ and webmaster@ email addresses. (rfc2142)

ALL domains "should" have at a minimum these items set up:

1. SPF records
2. DMARC records.

ALL domains are highly encouraged to set up DKIM and Domain Keys (two different things that achieve the same goal).

By doing those items, your emails SHOULD have no issues, regardless of their country of origin.

With that said, take my advice or not. As I am an CISSP with over 26yrs of being in Information Security and using ever version of exchange server since version 5.5 back in 1999. I encourage you to take my FREE advice.

Michael B. Morell, CISSP #431307 CCSK (he/him/his/sir)

DirectionWeb

Owner and Information Security Professional

I hate to have to throw credentials around, but I am an CISSP (Certified Information Systems Security Professional) with over 26yrs in Information Security and am an literal expert whom is the one that "experts" go to. Am freely giving information. As I said many times across my career, it is your choice to follow advice from experts who live and breath this stuff, or not. You are free to disagree, but that still does not change the technical realities of email.

Sender reputation is DIRECTLY a result of lack of SPF/DKIM/DomainKey/DMARC. That does not mean you can send spam to people, or not clean up your email lists (i.e. remove bounced emails immediately) or rate limit outbound email sending to specific public domains. You will absolutely be flagged for bad reputation (AOL is probably the most egregious of this rate limiting enforcement and flagging it as bad reputation. If I had a penny for every removal request I have had to submit for AOL removal, I would be a millionaire)

With that said, You do not need both RUF (failures) and RUA (aggregate) in dmarc. Just one or both.

The RUA is aggregate of YOUR OWNED domains and in such GDPR rules does not directly apply. Where as RUF contains failures TO your domains from outside orgs. That is where the issue lies because you are not "entitled" to that information because the sender has not explicitly authorized it and has no way of initiating "right to be forgotten". THAT is why RUF violates GDPR natively without taking further action on it.

While RUF "may" violate GDPR, if you have a need for RUF there are ways to ensure compliance. Such as immediately stripping out info immediately, or deleting the reports immediately. Or even encrypting it after receipt makes it compliant.

So to just say it is not compliant out of hand and "can't" be used, is just not true.

But again, you are free to disagree. It does not make it any less true.

Michael B. Morell, CISSP #431307 CCSK (he/him/his/sir)

DirectionWeb

Owner and Information Security Professional