Why is this SPF record not working?

[thecomputerguy]

Client uses construction software called RedTeam that uses SendGrid to send email out of their system. They have always had inconsistencies in delivery when trying to send out of RedTeam. Upon contacting support at RedTeam they simply just said to set your SPF record to these settings. We've been battling them for more support for months.

The problem is ... this SPF record is already in place and has been in place since they started using the software and they've ALWAYS had delivery issues.

When sending to other Office 365 tenants they are receiving this:

550 5.4.1 Recipient address rejected: Access denied

Here is the SPF Record:

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

 

[YeOldeStonecat]

Only thing I question, is why the SG IPs up front...when you have their domain at the end, I like the -all instead of~ but that's just a preference

 

[YeOldeStonecat]

Actually the "a" you have, v=spf1 a should go before the domains, not before the IPs...but I'd remove the IPs.
I would have
v=spf1 include:spf.protection.outlook.com include:sendgrid.net -all

 

[thecomputerguy]

Actually the "a" you have, v=spf1 a should go before the domains, not before the IPs...but I'd remove the IPs.
I would have
v=spf1 include:spf.protection.outlook.com include:sendgrid.net -all

I just added what they told me to add I want to follow their direction before I start any tinkering ... they now also recommended that I add more CNAMES ...

Type: CNAME
Host: em7793.contoso.com
Value: u8317989.wl240.sendgrid.net

Type: CNAME
Host: rts._domainkey.contoso.com
Value: rts.domainkey.u8317989.wl240.sendgrid.net

Type: CNAME
Host: rts2._domainkey.contoso.com
Value: rts2.domainkey.u8317989.wl240.sendgrid.net

No Idea why this wasn't advised earlier.

 

[YeOldeStonecat]

Yeah these days you should be doing not only...
SPF...
but also DKIM
and
DMARC (just a generic record stating what to do with those that fail)

 

[Markverhyden]

550 5.4.1 Recipient address rejected: Access denied

That's a problem with the recipient. If you were blocked because of a problematic SPF that would be in the error message. And @YeOldeStonecat is right on with DKIM and DMARC. These days you need all three. That being said I remember somewhere that one of the last two mentioned gets taken care of automatically, supposedly, by MS.

 

[Sky-Knight]

mxtoolbox.com has tools to validate and parse that record. The syntax appears valid, but without the domain I can't look things up and make any suggestions.

 

[HCHTech]

I also like to have an email sent to one of the DMARC testing sites to see the response there. There are a few out there, I think dmarctester.com is one - something like that.

 

[phaZed]

I use valimail.com for DKIM/DMARC checking on occasion.

 

[Sky-Knight]

I use Demarcian and MXToolbox, mostly the latter.

In this case it has a breakdown of SPF that can help you find depth issues.

In this case, I suspect the A and MX directives are improper... but again without a domain to look at... I'm rather stuck.

 

[John Kennedy]

SPF records can only have so many lookups as well. Having a and mx in there often adds a bunch of unnecessary lookups. You want it to be only the servers that actually send emails (Sendgrid, Outlook, and maybe those IPs if they are webservers or something that send contact form emails or something). Checking the SPF record with mxtoolbox.com will tell you whether there are too many lookups.

For DMARC, Postmark has a handy service for monitoring and helps you set up the correct record: https://dmarc.postmarkapp.com/

For DKIM, you should be able to look up how to add for MS365 fairly easily (be warned, it fails on verifying the records easily, wait like 30 minutes after you add the new records to verify or you'll be stuck trying for a while). Those additional CNAME records they sent you are the DKIM records for your Sendgrid account.

@Markverhyden, I'm not sure you're necessarily correct about the error being something other than SPF. It depends on the mail filter. Many will state bad SPF in the rejection, but many won't. It could still be bad SPF for such rejections, but it could be any number of other things too since the error is so generic. Might be best to work directly with the recipient's IT/mail team to resolve.

 

[thecomputerguy]

Here is the report from Dmarcian

 

[John Kennedy]

Until you are sure your SPF and DKIM are all good and fully configured, I'd recommend leaving your DMARC at p=none. You don't want a misconfigured record making things worse. Have you set up DKIM in MS365 yet? Did you update the SPF?

 

[Markverhyden]

@Markverhyden, I'm not sure you're necessarily correct about the error being something other than SPF. It depends on the mail filter. Many will state bad SPF in the rejection, but many won't. It could still be bad SPF for such rejections, but it could be any number of other things too since the error is so generic. Might be best to work directly with the recipient's IT/mail team to resolve.

I'm not saying that's the only failure point. It's just the first step I'd look at. Those descriptions after the numeric code are generally pretty accurate based on what I've seen.

Having been around this mass emailing for years my experience is that the problem is usually non-existent/locked email accounts. If it's domain wide then it's blocked sender domain issue. The op made no mention of trouble shooting steps. In the past I've always requested the specific addresses failing for testing. More often than not they were in fact disabled/non-existent