I’ve set up DMARC on a clients domain. Recently, I started seeing rejected emails from SendGrid.net associated IP 167.89.61.112. I determined for my client that it was an approved service they use sending out emails on behalf of my client.
I added “include:sendgrid.net” to my clients SPF record which used ~all, that translates to “included:167.89.0.0/17”, which covers the source IP.
In my experience, getting SPF or DKIM to at least align with ~all set will prevent DMARC reject from being applied - but I could be wrong on this point. ( We have emails from Google Calendar send out that only pass DKIM and the reject is NOT applied to those)
I considered this to just be temporary until I was able to verify SPF and DKIM and it up properly with help from SendGrid.net or the service sending the emails. However, according to dmarcian, even with the “include:sendgrid.net” in place, the emails are still failing to align and the reject policy is still being applied.
Unfortunately, neither the service sending the emails or SendGrid seem to know what I’m asking. The service doesn’t appear to know anything about DMARC as they just want to suggest Firewall rules. Since the emails are compliant with SPF and DKIM for SendGrid, I suppose it makes sense that the sending service would not know about DMARC.
SendGrid, on the other hand, is taking the position that since the emails they send are compliant to SendGrid’s SPF and DKIM, they should be passing. They seem to be completely missing the point that the emails appear to come from my client’s domain, not SendGrid and thus they ultimately fail. I’ve sent them screenshots of Dmarcian showing this, but they still do not seem to understand.
If there are any suggestions on what I’m doing or saying wrong, what I might show SendGrid to get this fixed, or if anyone has experience dealing with SendGrid, I’d appreciate the help.
Hi @baebjb,
SendGrid is a 3rd party sending email on your clients behalf. As most ESPs they will handle any non-delivery reports or bounces on the mails they send for your client, so they set the return-path pointing to their servers. While the return-path may align (via a CNAME record on your clients DNS, e.g. newsletter. yourclient. com CNAME someserver. sendgrid. com) it will NOT match your client’s domain, and your client’s SPF record will not be checked for mails originating from SendGrid.
To get DMARC compliant mail from ESPs involves setting up DKIM signing in the ESP account admin panel, and authorising/publishing the signing keys in DNS.
Thank you for your response.
I did finally get the same answer from SendGrid. Of course, my client is using a service that uses SendGrid… and getting that service to understand what is needed has been challenging - even after I shared SendGrid’s response directing the third party service to SendGrid’s guide on Domain Authentication.
I think the issue boils down to this 3rd party service just not being familiar with DMARC.
We’ve had this experience with SendGrid and our webhost, which also uses SendGrid. The webhost immediately setup it up in their admin panel and shared the appropriate DNS records for us to use.
I have a call setup with this problem service’s engineer in about an hour.
The support engineer knew exactly what I need and generated the necessary authentication keys. I just needed to get to the correct support tier. I still need to test and verify that it is working, but I have fairly high confidence.
Also, thanks for pointing out that my SPF record is not referenced for ESP sourced emails in this kind of setup. I was able to verify that with their support engineer and clean up my SPF record which was getting bloated.
