Emails being blocked by Gmail from office 365

I guess we will have to agree to disagree on the root cause but I'm humble enough to change my opinion if the evidence supports it.

It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so. - Mark Twain

B

J

Sorry, I wrote to the wrong topic. I haven't exchange server. Too many threads about similar issues and I follow them all. I am complaining about outlook.cz domain.

(syntax), nice catch apologies, it was probably me changing mine from "my email" to YourEmailAddress

(I'll fix it so no one else wastes their time...)

Onto the question about sub-domains, which is an excellent btw. The answer is both Yes and No.

So, let's start with no. If your sub-domain has no DMARC record, it will inherit the parent domain as long as you have the policy tag (which my example does, which is set to "none" ).

Policy tags are hierarchal. the tag p= is for the top level domain. sp= is for sub-domains. What this means is that you can force different policies for a TLD and its Sub-Domains. So if you want the TLD to be none and the subdomains to be "quarantine" it would look like this;:

p=none; sp=quarantine;

Now. here is where it get's fun. Let's say you have 4 sub-domains and you set your dmarc record at the TLD to p=none; sp=quarantine; ... BUT you want only 3 out of the 4 SD's to follow the TLD SD policy of quarantine, but then want domain 4 to do something differently like "reject"

THEN you need to have a specific dmarc record on domain 4.

BUT!, like everything it is not how you think. You would think that the dmarc record would be "sp=" but it's not. It would be "p=". And here is why. That sub-domain, for the purpose of dmarc, would think that "it is the root domain".

Now let's say in THAT sub-domain, you have 4 sub-domains that have a different policies, a "sub-sub-domain" if you will. Well then remember that the original sub-domain thinks it is the TLD. So you would need the sp= tag in that sub-domain's dmarc.

Confused?

Well, the answer is actually very simple. Unless you need different policies for your sub-domain(s), just leave the policy tag as "p=[none,reject,quarantine]

HOWEVER, if you want to be extra security conscious (which we all should be) it is a good security practice and practice in general, to be as granular as possible and layered security.

So my answer would change from "no" to "yes". Add dmarc records to EVERY TLD and Sub-Domains that you have.

Does that help?

Thank you for the detailed explanation. I have changed my DMARC setting (did one have v=DMARC1; p=quarantine; so far) and will give it a try. Btw. do I only need to set this for the top level domain if the email adresses are ******@topleveldomain.com ? Or do I also need this for all sub level domains like m365.topleveldomain.com?

Your "Value" appears to have a syntax error though. I believe after the second YourEmailAdress a semicolon is missing? Props to CoPilot helping me correct that in one minute despite researching an hour...

HOST: _dmarc

VALUE: v=DMARC1; p=none; rua=mailto:YourEmailAddress; ruf=mailto:YourEmailAddress; fo=1:d:s

TTL: I prefer 1Hour but you can choose anything.

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