Here is a story involving a web-based contact form that indicates that this may be the case.
A wise man once noted that only two things in life are inevitable: death and taxes.
Just how taxes and interactions with the tax authorities are handled vary widely from jurisdiction to jurisdiction, but in Norway, where I live, the default mode of contact with the tax authorities for most of us is via web forms protected by sometimes cumbersome authentication procedures and the occasional alert via SMS text message to your phone.
And we're used to that the things just work with only occasional and very minor technical embarrassments for the people who operate the thing.
Then in August 2016, I tried to report a bug via the contact form at Altinn.no, the main tax authorities web site.
The report in itself was fairly trivial: The SMS alert I had just received about an invoice for taxes due contained one date, which turned out to be my birth date rather than the invoice due date. Not a major issue, but potentially confusing to the recipient until you actually log in and download the invoice as PDF and read the actual due date and other specifics.
The next time I checked my mail at bsdly.net, I found this bounce.
The meat of the message is
SMTP error from remote mail server after RCPT TO:
host mx.isp.as2116.net [184.108.40.206]: 550 5.7.23 SPF validation failed
which means that somebody, somewhere tried to send a message to email@example.com, but the message could not be delivered because the sending machine did not match the published SPF data for the sender domain.
SPF expands to "Sender Policy Framework", which is one of the early and still valid ways for a domain to publish which hosts are supposed to be sending mail on the domain's behalf.
There is no requirement to refuse delivery of mail from a host that is not in a domain's SPF record, and emphatically so when no such record exists. On the other hand, when a domain does publish SPF data, rejecting mail from hosts that are not in the set published is a valid and accepted action.
What happened is actually quite clear even from the part quoted above: the host mx.isp.as2116.net [220.127.116.11] tried to deliver mail on my behalf (I received the bounce, remember), and since I have no agreement for mail delivery with the owners and operators of that host, it is not in bsdly.net's SPF record either, and the delivery fails.
The bounce message contained one Received: header which tells part of the story, and after decoding the MIME-encoded part it becomes clear that it contains my bug report with some slightly odd markup.
So it's clear that what produced the bounce was that the contact form had tried to deliver mail using the address I had given the contact form.
I can hear your groans all the way from there to here.
My original bug report had not been delivered, but I thought perhaps I could help them with the other problem, so I sent off a new message to the addresses that were given as contacts in the altinn.no domain's whois info, taking care to send it from a machine that was properly authorized to send mail for my domain.
The full text of the message is available here, in Norwegian. The message includes the bounce with a short introduction that said essentially "this is the result of trying to submit a bug report via your web contact form. This is clearly an SPF problem, please look into that".
Then that message bounced, too.
The exact reason is likely buried in the configuration files for altinn.no's MX, but it could be that it has some reservations against accepting mail from what it sees as a subdomain that doesn't have an MX record of its own.
Anyway, by then I had spent far too much time on this rather trivial matter while I was supposed to be doing other things, so I quickly wrote up a summary and sent it off to the same contact addresses, this time from my gmail.com account, with the various accumulated data as attachments.
Then, as often happens when dealing with the authorities, nothing happened. For quite a while.
It was only on October 18, 2016 that my gmail.com account received a reply from the support address, which quoted my last message in full, and added their resolution text saying:
Det kan se ut som du har Sender Policy Framework (SPF) aktivert på din mailserver, Det er en kjent svakhet ved vårt kontaktskjema at mailservere med SPF ikke støttes."
It looks like you have Sender Policy Framework (SPF) enabled on your mailserver, It is a known weakness of our contact form that mailervers with SPF are not supported."
Once again, I can hear and fully sympathize with your groans.
This is as perfectly wrong as can be, in fact the exact opposite of right.
The obvious answer should be, as you will agree if you're still reading: The form's developer should place the user's email address in the Reply-To: field, and send the message as its own, valid local user. That would solve the problem.
So I put it to you: Is SPF, the Sender Policy Framework, simply too hard for application developers to understand?
Yes, I'm well aware that SPF also breaks traditional forwarding of the type generally used by mailing lists and a few other use cases. Just how afraid should we be when those same developers come to do battle with the followup specifications such as DKIM and (shudder) the full DMARC specification?
I anticipate your feedback in comments, or if you have things you really want me to only paraphrase in public, email.