Genuine Spoofing - further question

Question

Hi

I raised a request recently and I accepted answer and it was closed.

I have a further question though.

https://learn.microsoft.com/en-us/answers/questions/378681/genuine-spoofing.html

The original question was

On our customer facing site we have a contact form for users to fill in. This contact form is managed by Sendinblue.

When users complete this form an email is sent to a shared mailbox within our domain.

Sendinblue have spoofing in place so that when the email comes into our shared mailbox it appears to have come from the user that filled in this form (they add their email into the form)

EOP is correctly picking this up as spoofing and sends these emails to the junk folder in the shared mailbox.

We are considering creating a new anti spam policy to resolve this and targeting only the shared mailbox and including an allow for @smtp-relay.sendinblue.com

Doing this however would open this mailbox up to more junk.

Would this be the best way to approach a situation like this?

The response I received was to use a transport rule targeting @smtp-relay.sendinblue.com and to use DMARC as this would be more secure

My question is though if the email is being spoofed then would the dmarc not be pointing to the user who filled in the form rather than sendinblue?

Answer 1

Thanks Andy.

My main role in mt org is mdm intune etc but I have been tasked with this so want to make sure I get it right.

The issue is our sec team dont know as much as they think.

I have put forward this fix as you have suggested and received the following response

sendinblue servers are a spoofing agent, its not just our guys that can use sendinblue to send out emails as @ourcompany.... in theory anyone can, and now they are also getting marked as ok on SPF....Thats the reason I wouldnt have done it that way, far to risky to the business domain externally, not much risk to our guys mind u.

IMO this is incorrect as we have dkim and dmarc in place to stop the above from happening. So there is no concern there if I am correct?

Answer 2

Hi Andy

Sorry for the delayed response.

So looking at the option of the mail rule, dmarc and spf it seems like as you suggest this would be the most secure option to tackle this.

The emails that are coming in at the moment are failing dmarc. Below is an example of the authentication results from the header

spf=pass (sender IP is 999.999.28.109) smtp.mailfrom=bi.d.mailin.fr; mycompany.co.uk; dkim=pass (signature was verified) header.d=sendinblue.com;mycompany.co.uk; dmarc=fail action=none header.from=hotmail.co.uk;compauth=fail reason=001

So I believe the reason DMARC fails is because the from address(spoofed address) does not match the domain in the return-path.

If we add sendinblue IP into our SPF record how would that then change these results?

Answer 3

Hi Andy

Sorry for the delayed response.

So looking at the option of the mail rule, dmarc and spf it seems like as you suggest this would be the most secure option to tackle this.

The emails that are coming in at the moment are failing dmarc. Below is an example of the authentication results from the header

spf=pass (sender IP is 999.999.28.109) smtp.mailfrom=bi.d.mailin.fr; mycompany.co.uk; dkim=pass (signature was verified) header.d=sendinblue.com;mycompany.co.uk; dmarc=fail action=none header.from=hotmail.co.uk;compauth=fail reason=001

So I believe the reason DMARC fails is because the from address(spoofed address) does not match the domain in the return-path.

If we add sendinblue IP into our SPF record how would that then change these results?

Answer 4

I've got another option that has just been released:

(This is currently rolling out - so you may not see this option for a few weeks)

A domain pair for a spoofed sender in the Tenant Allow/Block List uses the following syntax: <Spoofed user>, <Sending infrastructure>.

so for your issue:
yourdomain.com, sendinblue.com

For example, you add an allow entry for the following domain pair:

Domain: gmail.com
Infrastructure: tms.mx.com
Only messages from that domain and sending infrastructure pair are allowed to spoof. Other senders attempting to spoof gmail.com aren't allowed. Messages from senders in other domains originating from tms.mx.com are checked by spoof intelligence.

https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/tenant-allow-block-list?view=o365-worldwide#use-the-security--compliance-center-to-create-allow-or-block-spoofed-sender-entries-in-the-tenant-allowblock-list

Answer 5

Hi Andy

That looks like the way forward although my business won't touch any new services like this for at least 6 months. Its just a rule they have.

In order to get these emails from junk to inbox I am going to go with a mail flow rule for now.

The mail flow rule will target the shared mailbox and bypass spam filtering IF it matches something in the header.

I am looking at what cant be spoofed in the header.

Would it make sense to go with 'header.d=sendinblue.com' from authentication-results or 'd=sendinblue.com' from DKIM-signature

This means only emails coming from sendinblue domain will bypass spam filtering for that particular mailbox. I believe that is pretty much doing what you have suggested above? I also believe that the d= cannot be spoofed is that correct?

Thanks again for all your assistance.