Freshdesk very long SPF record is a problem

  • 10 January 2022
  • 32 replies
  • 6744 views

Userlevel 1
Badge

Hi, we are using Freshdesk support desk and until now Freshdesk has been sending email’s on our behalf. This means that we have to add email.freshdesk.com to our SPF record. This means that Freshdesk alone adds 8 DNS queries to our SPF record and the standard allows for only 10 in total.

For comparison Microsoft adds two for the whole of Office 365.

Now, what i have feared has happened and we have passed the limit and our SPF record is not valid anymore. I don’t know if we added the one or if Freshdesk added another sub record.

There is really two problems, one is the size of the record to begin with and the other is that Freshdesk can add subrecords at anytime without any of their customers knowing and pushing that client over the limit.

I think therefore it is very important for suppliers that have SPF that is used by alot of customers to be very small and maintained correct.

One solution is to create your SPF record and then only add ip addresses to this record that you then maintain when something is moved or reconfigured. This would reduce the number of DNS queries from 8 to 1.

We are depended on our SPF, Dkim and DMARC to be perfect to run our business and we are therefore reconfiguring the service to send the mail directly through our Office 365 tenant so we can remove the records.

This can be a solution for other customers that have the same problem.


32 replies

Userlevel 7
Badge +7

Hello @Ant-TTG - thank you for flagging this and i’m sorry for the inconvenience. I have passed this on to my team, please let me get back to you

  

Hi there,

 

In anticipation of Google and Yahoo’s upcoming change to require DMARC on bulk senders, I’ve been reviewing my SPF records for Fresh Service and have confirmed that email.freshservice.com now commands an incredible 11 lookups - 10 nested lookups within the main DNS entry.

 

This means that Fresh Service lookups alone exceed the maximum allowed by SPF, which is quite remarkable.

 

I’m relieved to see that I’m not the only person who has highlighted this, and if I’m understanding the advice correctly, it seems that we only need to include one of the nested lookups - fdspfeuc.freshemail.io (EU). [source]

 

Can I confirm this is a solution, and not a work-around?

 

I’m also not clear on why, if this is acceptable, we were ever asked to include the other lookups in the first place?

 

Lastly, I can see that fdspfeuc.freshemail.io is not one of the nested lookups within email.freshservice.com. Is this not a problem?

 

Regards,

Robert

 

Just an additional note to say that I removed email.freshservice.com and added emailus.freshservice.com and this reduced the total number of lookups to 2, which is far more reasonable.

 

I believe fdspfeuc.freshemail.io is for Freshdesk, which is not the service we use - worth bearing this distinction in mind when troubleshooting your own environment.

 

Also, as we’re based in the UK we incorrectly assumed we would be part of the Fresh Service EU server farm; consulting with FS support, we were informed we’re hosted on US servers. This is also something you will have to check when trying to whittle down your lookups.

 

Another thing we were advised to do was include 3 DKIM records, and a 4th, which was described to me as relating to SPF. Now, anyone who knows how SPF works will tell you that’s not possible, as there can be only one SPF record for a domain, and unfortunately nobody from Fresh Service could sufficiently explain the syntax of the record to me. Despite having published it, I’m still unclear what it’s for or why it’s needed.

 

All in all, quite a needlessly challenging issue.

 

Robert

Userlevel 1
Badge

Hi @Ant-TTG 

Greetings for the day!

Apologies for the inconvenience caused here.

Glad to hear that the issue has been resolved now. Regarding the SPF query, as you mentioned you can add the region specific lookup which is "fdspfeuc.freshemail.io" and "sendgrid.net" to avoid this issue.

That said, we will pass on your feedback to our backend team to update the documentation accordingly.
Feel free to drop a note for any further help.

Cheers,
Kajal, Freshworks Community

@Kajal Vats I’m not sure this issue is resolved yet for many of us - the “workaround” still consumes a minimum 4 lookups, which if you have other platforms that send on behalf of a domain quickly ends up past the 10 lookups limit.

I am also affected by this issue and I must say it's such a big mess. Especially if you are not expert in this field you have no chance to solve this issue. I also dont want to spend 370$ for a SPF flattener.  It's incredible that Frehsdesk has no solution to this. We have a lot of issue with Emails going to spam from Freshdesk. They are doing an incredible bad job here in documentation as well.

Hi @Ant-TTG 

Greetings for the day!

Apologies for the inconvenience caused here.

Glad to hear that the issue has been resolved now. Regarding the SPF query, as you mentioned you can add the region specific lookup which is "fdspfeuc.freshemail.io" and "sendgrid.net" to avoid this issue.

That said, we will pass on your feedback to our backend team to update the documentation accordingly.
Feel free to drop a note for any further help.

Cheers,
Kajal, Freshworks Community

Nothing is solved here…. ?? Why are you telling that?

You always mention "fdspfeuc.freshemail.io"  and "sendgrid.net" together. Do I need "sendgrid.net" if I have nothing running on Twilio?? is this mandatory or just a specific case of someone using this service Twilio?

Reply