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.
[EDIT]
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.
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.
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.
@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.
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).
@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)
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.
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.
