Are SPF needed for domains that do not send mails and do not have MX record?

Solution 1:

No spf records are NOT required if your domain doesn't send emails

however for benefit of reducing the risk of spam mail coming from that domain setting the spf record of

"v=spf1 -all"

is good so that spf checking servers see this and automatically reject email from that domain

Solution 2:

You don't strictly need to publish any SPF records at all, it is a voluntary system.

That said, if you do publish an SPF record, you can:

• Help the Internet at large a tiny, tiny bit because it gives spammers one less domain to spoof. (Marginal benefit, but...)
• Help preserve your domains 'reputation' by making it less likely to be spoofed in spam.
• Proactively show that your domain isn't engaged in some MX-record-less hack yet still (by mistake perhaps) sending emails.

Update after OPs update: OK, so first off, it sounds a bit wrong that there are "many" domains on this IP and adding SPF for them all is difficult -- you shouldn't have domains you don't have a reasonable need for.

Regarding blacklisting: Generally, most IPs won't blacklist anyone for 'smaller' spam volumes. There is no way to say what criteria an ISP might blacklist on, since there are many different ISPs out there, and each is entitled to his own opinion. That said, if it came to blacklisting for you (unlikely), then the most likely targets are MX records and ranges of IP addresses.

---

Solution 3:

If you don't intend to send mail from this domain, why let anyone else to use it as they wish? But things have changed since this question was asked eight years ago. SPF can only protect your domain from being used as the envelope sender, but SPF can't protect the From: header.

I'd go even further by adding a DMARC alignment.

@       IN      TXT     "v=spf1 -all"
_dmarc  IN      TXT     "v=DMARC1; p=reject; aspf=s; adkim=s;"

All subdomains inherits the DMARC policy, but SPF isn't inherited by the subdomains. Therefore, you'd need to add a corresponding SPF record for every A record you have, too.

There's no need to publish any DKIM records as there's no-one signing the messages anyway.

I didn't add the rua= and ruf= because in this situation there shouldn't be any false positives to be fixed. If you are curious enough to collect data on how much this domain is used for spoofing, you can add e.g.

rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=0:d;

---

Solution 4:

You can add those SPF records and they will help prevent some of your concerns. SPF is always optional but nice to do.

UPDATE

As to the second part of your question, it sounds like the issue is really about how email works and how "banning" works.

1. OK
2. OK
3. It bounces the message. That is different than banning. There is a separate process that can result in listing the offending IP address, not of domainA, but of the sender's network IP address and potentially IP addresses also in the same network, in a blacklist.
4. See above.

Banning isn't done only by domain. Rather the offending network is where the battle is most frequently fought. It's generally a DNS mechanism but other methods exist in addition.

Your fear about affecting legitimate email from another domain really comes down to how that IP network behaves and whether it is generally spammy or not. Even getting banned is usually a temporary thing. You get listed on a blacklist and they you eventually get removed.

Stay ontop of any abuse emails from your ISP. This is a sign that someone is reporting you for spam and you may have some trouble.