What is the correct solution for a vendors SMTP usage to us?

[thecomputerguy]

Client uses redteam.com

As a part of the setup process they instructed us to modify our SPF record to the following:

v=spf1 a mx ip4:168.245.113.179 ip4:168.245.125.157 include:spf.protection.outlook.com include: sendgrid.net ~all

So RedTeam is using sendgrid to be able to get stuff out of their system and back to us via email. One thing I thought was weird is that they are using our own email addresses to be able to send mail. Example being, John logs into Redteam and needs to send himself a sales order. When he sends it it ends up in his inbox as:

from: john@email.com
to: john@email.com

Some things I've noticed is that we are getting quite a bit of spam that looks like its coming from ourselves to ourselves. Some of which is also from Send Grid.

One other thing is that I am only able to get emails OUT of Redteam to us if I whitelist our own domain, which I know is a no no, which I also know is why we are getting so much spoofing that looks like its from ourselves to ourselves. When I remove the whitelisting of our own domain Redteam emails no longer get delivered.

Digging into the logs I can see that these spoofing emails are failing SPF, DMARC, DKIM but are still being delivered presumably because of the whitelist.

We have had 3 phone calls with Redteam to try and rectify this but we end up just getting shuffled around and then forgotten about.

I'm curious as to why Redteam insists on using our OWN domain to send email instead of using their own generic email like noreply@redteam.com

I'm not sure if they use Redteam to send mail to clients, and in that case you would want the replyto to come back to us but this all seems crazy.

I've used SMTP2GO with no issues like this at all in the past but all Redteam had us modify was SPF when I know SMTP2GO has you modify several CNAME records as well.

In the meantime I have just had to create a mail flow rule to prepend and email that looks like its from john@email.com to john@email.com with a [WARNING]. This does flag all those spoofing emails but also flags Redteam emails as expected.

 

[YeOldeStonecat]

If Sendgrid sends emails on behalf of your domain, you add them to your SFP record. The SPF record permits other mail resources (domains or IP addresses) to send email on behalf of your domain. "on behalf" meaning..the return email address is from your domain.

So if RedTeam sends email that shows to come from RedTeam...you DO NOT have to do add their resources to your SPF record.
If those emails get junked or quarantine, it's not because of SPF but from other common rules your antispam system leverages, and you likely need to make an exception (bypass rule, or whitelist) for their servers so their send mail will travel through your antispam gauntlet unmolested.

But if RedTeams sends emails that come from say, thecomputerguy.com, you DO need to add their resources to your SPF record....else any email system that obeys your DMARC settings will see that sendgrids servers are not blessed to send email on behalf of your domain..and those emails will not make it through your antispam gauntlet or most others.

Example. We use SyncroMSP for our RMM and helpdesk ticketing system. We have an email address our clients can send TO...to our shortened domain. And ticket replies/responses as well as various reports from Syncro will COME FROM that same email address...and those emails spew out of SendGrids servers...so I have added "include:sendgrid.net" to our shortened domains SPF record.

 

[NETWizz]

I strongly suggest you also do DKIM, but the entire purpose of SPF and DKIM is for a domain to authorize an IP and sever respectively.

 

[SAFCasper]

Grab the message headers of a redteam email and copy/paste into here - https://mha.azurewebsites.net/

Should point to you down the right direction of where it's failing.


Might be able to save you some time though. There's a space in include: sendgrid.net which shouldn't be there.

 

[trevm999]

Spam shouldn't be able to be sent fully as your domain name from Sendgrid (as not a via) only accounts authorized for you domain should be able to send as your domain from their system.

More than SPF should be set up https://docs.sendgrid.com/ui/account-and-settings/how-to-set-up-domain-authentication

Also, I wouldn't authorize the same domain as your email users use as the sendgrid domain, since Sendgrid authorizes the whole domain and so then anyone with the Sendgrid api key can send emails as your users.

The only reason I can think of for using the same email of a user is if the system is sending emails out to clients and expect clients to reply back directly via email. But that is a flaw of the system (I.e. it wants to half ass a CRM without providing real CRM capabilities, like built in communication)

 

[Sky-Knight]

Sendgrid has documentation on how to integrate their service with SPF, DKIM, and subsequently DMARC.

If Sendgrid is not an authorized service, you shouldn't be adding them to your DNS in anyway. If you add SendGrid to your DNS, and integrate it into your mailflow, and someone breaches the SendGrid API key... they get to transmit via SendGrid in your name.

Redteam is your what? ERP vendor? If this is the case it might make sense to send as you instead of them to your customers. But if you're getting junk from it, then their system is likely compromised... and you've got a huge issue on your hands.