SPF record wildcards and spam detection

It’s kinda off topic but I think I have to explain this.
If you don’t specify a wildcard SPF record you risk impersonation of your domain.
Just as an example: Some mail server (that check the SPF record but nothing relevant else) will accept any email from fraud@support.letsencrypt.org or example@news.eff.org from every ip address out there!
Just because there is no SPF record set for this non existing domain.

So it should be good practice to set up an wildcard SPF record like suav.ec already did:
*.example.com 3600 IN TXT “v=spf1 -all”

Hope this finds the right minds.
Please read the entire thread an don’t apply it to your configuration directly.
Depending on your threat model this could be positive and or negative.

1 Like

You’d also need SPF records for every existing name too, no?

Just test it with dig / nslookup / mxtoolbox to be sure.

I wouldn’t recommend synthesizing SPF records for nonexistent domains (e.g. via wildcard records). Most providers will treat NXDOMAIN as a stronger spam signal than SPF hardfail, some even by rejecting the mail outright.

By decreasing your spamminess with some smaller providers that just ticked SPF off a a checklist, you may be increasing your spamminess with other providers that actually care. :wink:

For existing domains, explicit SPF records may indeed be a good idea. Since email falls back to A records if MX records don’t exist, even a great implementation will allow at least one server to send mail.

1 Like

Wildcards don’t apply if a name exists, whether or not it has any records of the requested type.

1 Like

What? :confused:
Adding a hardfail doesn’t change the NXDOMAIN check of huge providers, right?

@lbehm thanks for taking interest. In my platform I actually let websites take over the whole subdomains and also allow them to handle dynamic hostnames, so I essentially never have an NXDOMAIN for such websites.
And although I was purely opportunistic in letting the TXT SPF records behave the same as A/AAAA, it’s good to know it was actually the right thing to do.

As for the cases with NXDOMAIN, I don’t have any empirical data, but I think I’m with you. From what you’re saying, it doesn’t hurt to add this little extra to block an attack vector, even if it’s just to protect users with email at some obscure providers. Likewise, I wouldn’t think the big providers would consider this as something that increases your spamminess index, as I can’t see how such practice could correlate with spamming.

If some record exists for the domain, even just a TXT record, then the domain exists and your DNS server either returns an existing record or NOERROR if you ask a record that doesn’t exist.

So with no record for the domain, this happens:

Hey DNS server, what’s the TXT record for fake.example.com?

NXDOMAIN. There is no fake.example.com.

That’s really bad, this domain doesn’t exist at all. There’s no reason to let this mail through, they don’t even have a website.

Whereas with a TXT record, this happens:

Hey DNS server, what’s the TXT record for fake.example.com?

It is “v=spf1 -all”.

That’s bad, this domain says it shouldn’t be sending mail. SPF misconfigurations happen though, so our policy is to let N% of mail like this through.

Well, It seems that @lbehm is claiming that some software behaves in a way that make SPF records the safer option. @patches talks about other software that prefers the opposite.

Although, I must say, I don’t feel this is very important because both seem to be talking about somewhat rare cases, to make our minds up, we’d need to gather concrete examples. Otherwise we might as well toss a coin and hope we chose to protect against the more prevalent vector.

One concrete that comes to my mind is the fact that not all DNS providers actually return NXDOMAIN. Name.com, rather infamously, actually returns NOERROR for that TXT scenario provided by @patches.
Expanding on DNS hijacking, another example: Although hosting a mail server from a ‘retail ISP’ while using their DNS is probably not a very common thing, any user of such email would be even more doomed (interestingly, adding a wildcard TXT record is even one of the prescribed remedies to this hijacking).

I don’t understand the jump form there is no TXT record to there is no record at all.
There could be answers to A/AAAA/etc. record requests.

@rg305 . Well, some DNS servers do seem to return NXDOMAIN for TXT query when there are no records of any type for the name (e.g. for blah.google.com), while they return NOERROR with 0 answers if there are some others (e.g. for www.google.com), but as I am saying in my previous comment, this is not guaranteed to be observed in all [resolver&DNS server] combinations.

Now I understand your point!
Well… I hope no provider at all thinks about -hardfails that way. There are ~softfails for that.
But if they do, which I really hope they don’t, I would practically increase my risk that someone misuses my domain. (what you mean by spamminess)
That’s unsettling…

I disagree with this opnion. There is a lot of providers which send mails from domains that don’t exist ( for example: autoresponder@noreply.example.com , where noreply.example.org don’t exist ). I have to check logs and put exceptions for this all the time.

However, with a explicit wildcard SPF record, you are explicitly saying the policy for a domain.However, I do not recommend “v=spf1 -all”. Better with something like: "v=spf1 +mx:<BASE_DOMAIN> -all"
For example:

*.sebbe.eu IN TXT “v=spf1 +mx:sebbe.eu -all”

This explicitly sets the policy that your mailservers at MX = sebbe.eu is permitted, thus a SPF validation system will not interpret this as a misconfiguration, which “v=spf1 +all” or “v=spf1 -all” might be.
(Some SPF validators have hardcoded values what should be treated as an misconfiguration)

Do you have any example of that? Pretty much everybody will drop that. You send normally from noreply@example.com

Yes, for example the service microsoft uses when a Customer needs to sign a agreement online, they send from for example @esign.docusign.com (SERVFAIL) and that domain is completely nonexistent, had to put it as exception to get the papers I needed to sign.

Name: esign.docusign.com
esign.docusign.com MX preference = 10, mail exchanger = mail.en25.com
docusign.com MX preference = 0, mail exchanger = docusign-com.mail.protection.outlook.com
esign.docusign.com text =
“v=spf1 include:_netblocks.eloqua.com -all”

They actually fixed it pretty Quick after I mailed their support.

But as you see, there are systems out there that are misconfigured, and a non-existing domain is more common of a misconfiguration than a SPF explicitly telling a policy. A explicit SPF on wildcard is Always good, but don’t blanket accept or blanket deny Everything, instead permit the MX for the base domain. That will ensure the SPF will not be treated as a misconfiguration.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.