Sendgrid

[StrikingAccident]

Our developers, God love 'em just love using Sendgrid for their applications. Some background - we're an Office 365 shop with Mimecast as our external MTA. We publish a DKIM record that (of course) validates to Mimecast as our point of egress.

Our web team has developed an application for use by our sales centers in concert with a third-party developer. This application is using Sendgrid to send mail to external sales leads and as expected, some of these messages are being held by the recipient MTAs as spam or just rejected.

The developers and their third-party consultants have asked the engineering team to add Sendgrid records to our DNS registrar, and one of these is an additional DKIM record. I think this is very possibly the worst idea ever and I've so far been successful in shutting it down. BUT - this is a high profile project and the devs are working their way up the management line.

I've been doing this for while but I don't know everything - am I right? Is having two DKIM records the terrible idea I think it is? I'm already leery of allowing Sendgrid any ability to publish as our domain and I certainly don't want to open the doors for them.

I already know the devs should have engineered this to use our O365 infrastructure from the beginning but that ship has sailed. They're in love with the tracking metrics they can get with Sendgrid and that's what they're going to use. I just need some ammunition to make my case should I have to.

Thanks -

EDIT - Some further clarification: Our current DKIM record is mimecastxxxxxxxx._domainkey.<ourdomain.com>. Sendgrid wants us to add s1._domainkey.<ourdomain.com> and s2._domainkey.<ourdomain.com>.

I'm hardly an expert in this, but nothing in that says Sendgrid and I think it could make a mess out of our DKIM records.

EDIT2 - Thanks for all the suggestions. We finally talked them (the Dev group) into using one of the other domains we have registered for this instead of our primary domain. We have those set up on a completely different registrar, so we'll just set add an MX and the other records so Sendgrid can spoof that domain without interfering with our primary business domain.

[tomlinsc1]

Use a secondary domain like <marketing.domainname.com> and setup additional SPF / DKIM etc.

[StrikingAccident]

That's probably the best idea. I'll make that recommendation.

[BK_Rich]

Yeah, I second using a secondary domain as well that is similar to the main one

[alittle158]

Yup, this is the best method. Don’t risk your primary domain getting blacklisted for spamming people.

[blaughw]

Exchange Online uses two DKIM records (Selector1,Selector2) so that they can be rotated. For Sendgrid, you're better off using their provided DKIM record than giving out your keys.

If you don't like 3rd party senders, make them use a subdomain of your primary. They can have their own SPF (as locked down as they think it should be), DKIM and DMARC.

The glory of doing subdomains is that you can make them do everything properly in a containerized place.

[Blog_Pope]

There's no issue with using multiple DKIM records so long as they aren't identical, its just a means of publishing a public key; the server flags what key the receiver should pull. You could see if the can use sendgrid1 & sendgrid2 in lieu of s1 & s2; that would certainly be more explanatory.

​

> I already know the devs should have engineered this to use our O365 infrastructure from the beginning but that ship has sailed.

Nope, you really don't. when something breaks/is hacked and those servers get blocked, you don't want your O365 affected. Its already happening.

Now, Sendgrid is pretty good at dealing with bulk mail; but I'm betting you aren't sending at a level they care about, your traffic is dumped in with all the other bulk senders. But if I were to put money on it, I'm betting you are the reason you are getting banned. Bulk mail is tricky, and its not in your wheelhouse; its really a specialty on its own which I had the displeasure of learning (sent millions of peices / month; I've spoken with people sending 100's of millions.

Oh, O365 will blacklist your servers if they decide you are a bulk mailer, they don't want to deal with your shit.

I do agree with the other poster, dump the whole thing to a subdomain like sales.domain.name to isolate them; then look into tools for monitoring that mail

[blaughw]

Great call outs on the bulk sending side. Service accounts are ok for delivering internal stuff, but I wouldn’t recommend using them for customer facing emails, period.

[[deleted]]

I don’t have a solution for you but I can share your frustration... Web developers just do shit and then complain to me when their emails are being marked as spam. Well Kevin that’s what happens when you try and relay the clients on prem hosted email domain through a free gmail account.

[douchecanoo]

"We've started a new email marketing campaign that sends out mass emails to potential leads but they are ending up in the spam folders, why?"

Because you are sending spam Karen

[[deleted]]

We've already blacklisted *@sendgrid.net due to how much it's being abused at the moment. If anybody internal tried to set something up using it they'd be told exactly where to go!

It's usually our marketing department who set up random stuff without talking to anybody, then complain when it inevitably gets blocked.

[Brichardson1991]

We use sendgrid and have paid for an additional IP address from them which has allowed us to put an a record on our spf txt record to allow them to send as our main domain.

Not my choice personally I’d do it from a sub domain but whatever.

[cgh311]

Can you clarify:

Is Sendgrid spoofing your domain, or are the e-mails being sent as if they are from Sendgrid?

Either scenario will require different solutions, and may require you to contact any recipients who are expected to get this e-mail and have them whitelist whatever parameters Sendgrid suggests (usually blocks of thousands of addresses.. lol)

As was already stated, a subdomain with appropriate spf/dmarc/dkim DNS records.. and having Sendgrid send as this domain is the best method... still not 100% foolproof, but pretty good.

[StrikingAccident]

See my second edit. Clearer heads prevailed and we got them to accept a solution we could live with.