What are some examples of common but unusual SPF and MX records?
Summary
What email marketers say8Marketer opinions
Email marketer from Super User explains that an MX record pointing to `localhost` (127.0.0.1) indicates that the domain only accepts email from the local server. It's sometimes used on development or test environments, but it's unusual in production.
Marketer from Email Geeks shares an example of a `v=spf1` record including multiple includes and ip4 addresses: `v=spf1 include:<http://registrarmail.net|registrarmail.net> include:<http://sparkpostmail.com|sparkpostmail.com> ip4:10.10.0.0/19 ip4:127.0.0.1 ...`
Email marketer from dmarc.org explains that the 'ptr' mechanism is fragile, slow and often gives wrong results. Best practice is to avoid its use.
Email marketer from EasyDMARC notes that having too many nested includes can cause validation issues when sending email. It also can make it difficult to manage all the various includes required in a large organization.
Marketer from Email Geeks suggests that the idea to include localhost in SPF records comes from seeing headers like `Received: from localhost (localhost [127.0.0.1]) by <http://mail2.wdc01.mcdlv.net|mail2.wdc01.mcdlv.net> (Mailchimp)` and then IT adds it as a precaution.
Email marketer from Stack Overflow explains that SPF records have a lookup limit of 10 DNS lookups. Using too many `include:` mechanisms or nested lookups can exceed this limit, causing SPF to fail. Complex setups can be a common cause of unusual SPF behavior.
Email marketer from MXToolbox explains that an empty MX record (no MX records defined) technically means that the domain does not accept email. This is unusual, as most domains are configured to receive emails.
Email marketer from Reddit notes that having multiple SPF records for a single domain is invalid according to the SPF specification and can lead to unpredictable results. This is a common misconfiguration.
What the experts say4Expert opinions
Expert from Email Geeks shares that `mx .` is also acceptable.
Expert from Email Geeks explains that `MX localhost` is common and acceptable, indicating the domain does not accept mail.
Expert from Word to the Wise explains that the -all mechanism should be at the end of the SPF records because anything after that will be ignored. However, some SPF records don't have it which means the receiver will accept mail from any IP address.
Expert from Spam Resource explains that SPF void lookups happen when an SPF record queries a domain that does not exist. This wastes time during SPF evaluation and can contribute to exceeding the 10 DNS lookup limit. This often happens with typo's in the SPF include statements.
What the documentation says3Technical articles
Documentation from RFC 7208 specifies that when an SPF check encounters an `mx` mechanism, it should resolve the MX records for the specified domain and then perform an A record lookup on each resulting hostname to determine if any of the IP addresses match the client's IP address.
Documentation from Google Workspace Admin Help mentions that an SPF record with `v=spf1 -all` indicates that no mail should originate from that domain. It's commonly used when a domain is reserved for future use but should not send emails, or it's used only for receiving emails.
Documentation from Microsoft Learn explains that a basic SPF record might include the `v=spf1` version tag, followed by mechanisms like `ip4:` or `include:` to specify authorized sending sources, and ends with a qualifier such as `-all` (fail) or `~all` (softfail).