wikipedia.org:
https://en.wikipedia.org/wiki/Sender_Policy_Framework (SPF)
https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme (SRS)

Specialist SPF Knowledge Check:

  • DNS lookup limits: SPF evaluation must return permerror when more than 10 DNS lookups are required, in accordance with RFC 7208.
  • Single SPF record rule: A domain must publish exactly one v=spf1 record; multiple SPF records result in permerror.
  • IP-based authorization: Mechanisms such as a, mx, include, and redirect ultimately authorize sending IP addresses; using domain names does not increase security and may unintentionally authorize shared-hosting IPs.
  • exists mechanism behavior: The exists mechanism performs a DNS A and/or AAAA lookup on the specified domain and matches if any record exists.
  • Implicit qualifiers: The a mechanism is implicitly interpreted as +a (PASS) when no qualifier is specified.
  • Domain-scoped a mechanism: A mechanism such as a:example.com authorizes the A and AAAA addresses of the referenced domain.
  • Evaluation order: SPF mechanisms are evaluated from left to right, and the first matching mechanism determines the result.
  • Record syntax integrity: SPF records are syntactically strict; double spaces or malformed formatting can invalidate evaluation and cause errors.
  • Underscores in SPF records: An underscore (for example _spf.example.com) is valid in DNS record names but not as a hostname; this is acceptable and commonly used for SPF include and redirect targets.
  • Scope of all in includes: The all mechanism in an included SPF record does not override the final all; only the all in the final evaluated policy (e.g. including via redirect=) is decisive.
  • Softfail versus fail behavior: The ~all (softfail) qualifier allows non-authorized mail to be accepted with reduced trust, which can help with third-party senders or forwarded mail flows. Read more: https://www.mailhardener.com/blog/why-mailhardener-recommends-spf-softfail-over-fail
  • Forwarding and SRS considerations: In Exim-based mail setups, the Sender Rewriting Scheme (SRS) is commonly used during forwarding to preserve SPF validity when redirecting mail. See also: https://webhostingtech.nl/monitoring-email/solve-exim-issues/
  • Dynamic SPF optimization: Dynamic SPF provisioning or flattening can convert includes into explicit IP addresses, reducing DNS lookups and preventing SPF permerror.

Analyze SPF:
https://www.mailhardener.com/tools/spf-validator

My number of DNS lookups with SPF:
– 0x: v=spf1 include:amazonses.com (-all; generic SRS)
– 2x: v=spf1 include:outgoing.spamport.com (-all; generic SRS)
– 1x: v=spf1 include:relay.mailchannels.net (~all; generic SRS)
– 0x: v=spf1 include:spf.sendinblue.com (-all; both transactional and non-transactional mail)
– 4x: v=spf1 include:_spf.sparkpostmail.com (~all; no SRS; ptr void lookups ensure pass)
– 2x: v=spf1 include:_spf.transip.email (~all; no SRS; for VPS customers of TransIP)

Example for SPF:
– outbound via the server’s MTA (Mail Transfer Agent)
– outbound via Exim or Postfix configuration to a mail service
– outbound via SMTP (or via SDK via HTTP) to Amazon SES
– bounces on incoming of the server
– use of a tilde in ‘~all’ may unblock for a foreign mail service

dogshowentry.nl: v=spf1 include:amazonses.com redirect=_spf.hostfusion.nl

amazonses.com: v=spf1 ip4:199.255.192.0/22 ip4:199.127.232.0/22 ip4:54.240.0.0/18 ip4:69.169.224.0/20 ip4:23.249.208.0/20 ip4:23.251.224.0/19 ip4:76.223.176.0/20 ip4:54.240.64.0/19 ip4:54.240.96.0/19 ip4:76.223.128.0/19 ip4:216.221.160.0/19 ip4:206.55.144.0/20 -all

_spf.hostfusion.nl: v=spf1 include:_spf.transip.email ip4:93.119.10.229 ip6:2a01:7c8:bb09:262:5054:ff:fee2:a101 ip4:136.144.238.43 ip6:2a01:7c8:d008:32:5054:ff:fee8:665a ip4:85.10.131.117 ip6:2a01:7c8:bb0a:44e:5054:ff:fe0e:819f ~all

_spf.transip.email: +include:_mailcluster.transip.email

_mailcluster.transip.email: [IP’s] ~all

Syntax of SPF: http://www.openspf.org/SPF_Record_Syntax
How DNS lookup counts (and about void lookups): https://tools.ietf.org/html/rfc7208#section-4.6.4