Why blocklists do not work on a contact form

Every other mailbox can learn who to trust. A contact form cannot, because a stranger writing to you for the first time is the whole point. What sender checks miss, and what still helps.

Email spam filtering has spent thirty years getting good at one question: is this sender trustworthy? Reputation services, SPF, DKIM, DMARC, allow-lists, blocklists — all of it measures the sender, and all of it works, because most email arrives from somebody you have corresponded with before, or from a domain that has a history.

A contact form inverts that completely.

What sender checks actually check

It helps to be precise about what each of these tools answers, because none of them answers "did a person write this to me".

SPF lets a domain owner publish which servers may send mail for it. The standard, RFC 7208, is explicit that it covers the "MAIL FROM" address and the HELO/EHLO name used in the delivery conversation between servers — not the From line you see in your mail client.

DKIM adds a cryptographic signature. RFC 6376 says it lets the owner of the signing domain "claim some responsibility for a message", and that verifying the signature "asserts that the hashed content has not changed since it was signed". It says nothing about whether the content is welcome.

DMARC ties those two to the domain in the visible From address, and lets the domain owner say what should happen when mail fails. It was updated this year: RFC 9989, published in May 2026, replaces RFC 7489. The new text says DMARC "does not attempt to solve all problems with spoofed or otherwise fraudulent emails".

Reputation and blocklists sit on top. Authentication gives a receiver a reliable name to attach a history to; the DKIM standard puts it as "an authenticated email creates a predictable identifier by which other decisions can reliably be managed, such as trust and reputation". Spamhaus, for example, publishes several lists: the SBL lists IP addresses it has identified as sending spam or hosting malicious services, the XBL lists addresses of hijacked devices, and the DBL lists domain names with poor reputation, which can be looked up against the domains that appear in a message, such as its links.

Check	The question it answers	What it tells you about a form message
SPF	Is this server allowed to send for this domain?	Whether your website's mail setup is right
DKIM	Was this signed by that domain and left unaltered?	The same
DMARC	Does the visible From domain line up with SPF or DKIM?	The same
IP blocklist	Has this connecting address misbehaved?	Something about your web host, not the visitor
Domain blocklist	Does this domain have a bad reputation?	Useful for links in the message body

Notice the right-hand column. On a form, almost everything these checks look at belongs to you.

The sender is always a stranger

A form exists so that people who have never contacted you can contact you. The first message from a new customer is not an edge case; it is the product. Any filter that scores unfamiliar senders as suspicious will hold back exactly the mail the form was installed to collect.

That is also why allow-lists do little here. The people worth hearing from are, by definition, not on one yet.

The sender on form mail is you

Worse, the sender headers on form mail are not the visitor at all.

Take WordPress, where a great many business contact forms live. It sends mail through wp_mail. When nothing else is configured, its code sets the From name to "WordPress" and the address to wordpress@ followed by your site's domain. Contact Form 7's default mail template does the same: the sender is your site title with a wordpress@yourdomain address (or your admin address if it is on the same domain), and it adds a Reply-To: [your-email] header, where [your-email] is whatever the visitor typed into the email field.

That Reply-To is not a sender identity. RFC 5322 defines it as the address "to which the author of the message suggests that replies be sent". Nothing authenticates it. A visitor can type any address, including one belonging to somebody else.

So every message arrives from the same sender, with the same reputation. At best it is perfectly authenticated; at worst it fails authentication for reasons that have nothing to do with the visitor — which is a delivery problem, covered in how a form notification is authenticated. Either way there is nothing there to discriminate with.

The visitor's IP address will not save you either

The one thing a form does see about the visitor is the IP address the submission came from. It is tempting to check that against a list. It works less well than it sounds.

Addresses are shared and reassigned. Spamhaus itself warns against using its Exploits Blocklist to deny access to web forums, journals or blogs, because end users are often on dynamic addresses and may be given one that was listed because of a previous user.

Residential proxies exist to defeat exactly this. These networks route traffic through ordinary home connections so that it looks like it comes from ordinary people. A 2019 IEEE Security and Privacy study, Resident Evil, detected 6 million residential proxy IPs and found that 90% were used for a short relaying time (870 seconds), "which renders IP-blacklist based defense on the server side less effective". Only 2.20% had been reported by at least one blacklist.

The networks are large and current. In January 2026, Google described disrupting IPIDEA, which it believes is one of the largest residential proxy networks in the world. Devices were enrolled through software kits embedded in otherwise ordinary apps, and in a single seven-day period Google saw over 550 threat groups using its exit nodes.

None of that is specific to contact forms. It simply means that the address a submission comes from says little about who sent it.

What is left

Three things, in increasing order of usefulness.

Where it came from. Mail that genuinely arrived through your form comes from your form's own infrastructure. Mail that arrives at the same address from somewhere else has skipped the form, which is worth noticing — not because it is necessarily spam, but because it means somebody has the address directly.

The shape of it. Link counts, an entirely uppercase subject, a body that is one URL. These still catch the crude end, and the crude end has not disappeared. But they catch less every year and they misfire on real mail — a customer sending four reference links is not spamming you.

What it says. Whether the message contains anything only its sender could have written. This is the signal that survives, and until recently it could only be evaluated by a person reading the message.

Sender-side checks that are still worth doing

Sender checks are not useless. They are just pointed at a different problem. These are worth the effort:

Make your own notifications authenticate. Send form mail through a service your domain's SPF and DKIM actually cover. This does not stop spam; it stops your real enquiries being filtered as spam.
Watch for mail that bypassed the form. If the address your form sends to starts receiving mail from other senders, the address has leaked. Change it, rather than trying to block your way out.
Check the domains of links, not the sender. A domain blocklist is still useful against URLs in the message body. That is the part of the message the visitor actually controls.
Limit repeats. The same text arriving twenty times in an hour is a campaign, whatever address it claims to be from.
Treat attachments and "legal" threats separately. A message pressing you to open a file is a security problem, not a sales one. See contact form malware and fake legal threats.

And these are not:

Blocking free email providers. Plenty of genuine customers, and many sole traders, write from a Gmail or Outlook address.
Blocking the Reply-To domain after one bad message. It was typed into a box.
Blocking countries. Proxies make the location unreliable, and your next customer may be abroad.

The cost of getting it wrong, in both directions

A filter on a contact form is not like a filter on a mailbox. In most setups nobody scrolls a contact form's spam folder. If a message is held somewhere nobody looks, it is functionally deleted — and one held enquiry can cost more than a year of the spam it was protecting you from.

Which is why the interesting question is not "how strict should the filter be" but "what does the filter show you when it is unsure". A decision with no reasoning attached is one you cannot check, and a filter you cannot check is one you either trust blindly or turn off.

Where this is hard

Reading the message instead of the sender is not free of problems. A short genuine enquiry carries few signals. Some legitimate mail is templated. And a message-level filter still has to be tested against your own real mail before it is trusted.

That is the approach Humainbox takes: you change the recipient address in your form's notification settings (each builder's exact field is listed on the integrations page), and a language model reads each message and records why it decided what it did, with held mail kept where you can release it.