پویان Pouyan Mar 11

RFC7208 aka SPF experts! Please clarify this for me:

RFC allows adding a subnet mask to a and mx mechanisms. The examples section lists the following:

v=spf1 mx/30 mx:example.org/30 -all

Which means with respect to the sender IP address resolve A or AAAA for target domain (implicit in mx/30) and apply the subnet mask. This would mean that the same mask is defined for both IPv4 and IPv6 depending on the MX server IP.

This sounds like trouble, for example, if I have a dual stack MX server, any mask value over 32 would break my SPF policy if the server send the email over IPv6. Are there any advantages to this? Are people using this? What am I missing here?

#rfc7208 #spf #email

RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1

TrustyAug 11, 2025

🚨 We’re updating how we handle SPF records! In alignment with RFC 7208 recommendations, we are discontinuing support for the dedicated SPF record type (RR type 99). Going forward, all SPF records should be defined exclusively as TXT records. 📖 Read more in our blog post or contact us. 👉 https://blog.dnsimple.com/2025/07/discontinuing-spf-record-type/

#SPF #DNS #EmailSecurity #RFC7208 #EmailAuthentication #TXTRecord #SPFRecord #EmailDeliverability #DNSConfiguration #CyberSecurity

Show threadGuillaume-Jean HerbietJun 21, 2024
@shaft OK. So I believe it is legitimate to consider TXT multi-strings concatenation makes sense for SPF records in #rfc7208 and “tokenization” is more appropriate for catalog zones in #rfc9432.
Guillaume-Jean HerbietJun 21, 2024
#dns question about multi-string TXT records: #rfc7208 section 3.3 says they shall be concatenated w/o space.
Is this applicable only to #spf records?
Looking at #rfc9432 (catalog zones) section 4.3.2.1 the group example "operator-y" "bar" seem to suggest this shall be interpreted as some sort of key/value (e.g. “operator-y=bar” or “operator-y bar”) where “operator-ybar” would not make any sense.
Neither #rcf1035 nor #rfc1464 mention multi-string TXT records.