• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Question PTR value part of email SPF configuration

Ehud

Basic Pleskian
Server operating system version
OS version: Ubuntu 22.04 x86_64 Server version: Apache/2.4.57 (Ubuntu) Server built: 2023-04-08T12:56:02nginx version: nginx/1.22.1
Plesk version and microupdate number
Product version: Plesk Obsidian 18.0.52.3 OS version: Ubuntu 22.04 x86_64 Build date: 2023/05/16 12:00 Revision: a3b74dbc9de2e47afd4e532d02fa7759b29d3fa5
Hi,

According to this post, PTR could part of the SPF. This is a reverse DNS chackup to the best of my understanding.

May I ask if it's automatically supported by a Plesk server? Only on shared hosting?

And if not, what should be done:

1) To achieve the value (hosting provider service? CLI?)

2) Can you please provide an example for its implementation in an SPF, TXT DNS record.

• Matches if the DNS PTR record for the sending mail server’s IP address is in the SPF record’s domain and the DNS A or AAAA record received from the PTR lookup resolves to the sending mail server’s IP address
• Optionally, another domain can be provided, and the sending mail server’s PTR and A or AAAA records will be checked for a match with that domain instead.
• This mechanism is deprecated and should not be used.
 
The SPF can be edited in your DNS settings for however you need but the PTR is set by your hoster and you're limited to one domain per IP address. If you have multiple IPs assigned to your server and you assigned a different IP for each domain then each IP could have it's own PTR, otherwise if you only have 1 IP address that is shared between multiple domains then you're limited to whichever you've assigned it to. In my case I've configured my PTR to rDNS to my server's hostname of akheera.simon-soft.com which makes other email servers happy as is since the HELO responses with akheera.simon-soft.com.
 
Using the PTR mechanism in a SPF record seems to be highly discouraged according to these sources:

 
oh and that too, forgot to mention that in all spf records I've created, I had never added the ptr record inside the spf record because of what kaspar pointed out.
 
I would suggest you forget of PTR and focus on strong SPF records making sure they are not duplicated or most email providers will reject email coming from your server.
The template we use and works fine is:

v=spf1 a mx a:<domain> ip4:<ip> ~all

- if you use ip6 may add it as well
 
[...] The template we use and works fine is: v=spf1 a mx a:<domain> ip4:<ip> ~all

@jorge ceballos although your SPF record isn't wrong and might be a good fit for your use case, I do like to point out that it looks like you're using redundant mechanisms. The a and a:<domain> mechanisms accomplish the same. Most likely the mx and ip4:<ip> are too. As far as I can tell all mechanisms point to the same IP address.

Now, there isn't a one sizes fits all solution when it comes to SPF records. So a degree of redundant mechanisms is to be expected (but not necessary). An example of a SPF template record that's useable in most scenario's when using Plesk would be v=spf1 a mx a:<hostname> -all. A more strict example would simply be v=spf1 a:<hostname> -all.

Also, when possible, it's usually best to avoid soft fail in SPF records (but I know opinions differ on this subject).
 
Back
Top