Does the use of the non-registered domains in SPF records introduce a security risk?

Question

Recently I was reading about the Sender Policy Framework (SPF) record syntax on OpenSPF.com.

Sender Policy Framework (SPF) is a simple email-validation system designed to detect email spoofing by providing a mechanism to allow receiving mail exchangers to check that incoming mail from a domain comes from a host authorized by that domain's administrators. - Wikipedia

I noticed that the SPF syntax allows us to use the "exists-mechanism". The following is given as an example:

In the following example, the client IP is 1.2.3.4 and the current-domain is example.com.

v=spf1 exists:example.com -all.

If example.com does not resolve, the result is fail. If it does resolve, this mechanism results in a match. - OpenSPF.com

If I'm correct, only example.com is allowed to send email, all other senders are marked as SPAM because of the fail -all flag. Let's assume that I used the above SPF-record on the domain example.org.

So, example.org allows example.com to send emails in name of example.org.

Now let's assume the the domain example.com expires and is free for registration again and the above SPF record on example.org stays unchanged (read: pointing to example.com). In this case the SPF record of example.org will fail on all email since the only allowed domain doesn't exist anymore.

Now if an attacker registers the available example.com domain. Then he is able to send SPAM in name of example.org, while the SPF record won't stop it from doing so?

In other words, should the use of the SPF exists-mechanism be marked as a potential risk? Or, does the use of the SPF "exists" mechanism introduce a security risk?

The same applies to include:, ptr:, a: and mx: when they point to an non registered domain.

Answer 1

You didn't really get the meaning of the EXISTS, I believe. What you describe (allow example.com to send mail from example.org) would be INCLUDE! INCLUDE:example.com means see the spf record for example.com and apply the rules.

EXISTS is much simpler. It means "If the given DN resolves to any address, it will match (no matter the address it resolves to)."

So the rule "v=spf1 exists:example.com -all" is pointless really. It means if example.com has any IP set, pass the rule, else fail.

The EXISTS rule only makes sense with macros. For example, you could use v=spf1 mx -exists:%{ir}.sbl.spamhaus.example.org ?all to make the recipient check a IP blacklist and fail if the sender IP address is blacklisted. You could also do things like check if the user exists for the domain and a lot more powerful stuff.

To your question if this should be "marked as a potential risk". No, there is not more risk than in any other SPF setup. If you setup SPF wrong, you could create problems. But this is always a risk. If you use something wrong, bad things can happen. EXISTS or even INCLUDE is not any more risk than other SPF options.

Answer 2

SPF uses qualifiers (Pass, HardFail, SoftFail, Neutral) in order to determine the validity level of a request.

The qualifiers are determined by checking any or even all the following configured mechanisms:

ALL: Matches anything not already defined by another mechanism will match the all mechanism

A: If the domain name has an address record (A or AAAA) that can be resolved to the sender’s address, it will match.

IP4 / IPv6: If the sender is in a given IPv4 / IPv6 address range, it will match.

MX: If the domain name (DN) has an MX record resolving to the sender’s address, it will match (like if the mail comes from one of the domain’s incoming mail servers).

PTR: If the DN (PTR record) for the client’s address is in the given domain and that DN resolves to the client’s address (forward-confirmed reverse DNS), match. This is no longer be used.

EXISTS: If the given DN resolves to any address, it will match (no matter the address it resolves to). This is rarely used. Along with the SPF macro language it offers more complex matches like DNSBL-queries.

INCLUDE: If the included policy passes the test this mechanism matches. This is typically used to include policies of more than one ISP.

So it is up to the administrator to choose an appropriate security level what will cover his needs. The answer is no, an attacker will not be able to profit as in your example, given that the administrator has made the minimal necessary for a correct implementation of SPF.