Should I put my email address on my website?
Yes. The spam argument is weaker than it was, and being uncontactable costs more than the spam does.
Publish a real address. Modern spam filtering handles harvested-address spam well, while having no reachable human is one of the strongest negative trust signals a site can send. Use a role address rather than a personal one if you prefer.
The trade, honestly
- Cost: your address gets harvested and you receive more spam. Filtering catches the overwhelming majority.
- Benefit: customers, journalists, partners and people reporting problems can reach you. Some of those messages are worth a great deal more than the nuisance.
A contact form alone is not equivalent. Forms fail silently, land in nobody's inbox, cannot be replied to from a phone, and read as a barrier. Many people simply will not use one.
Obfuscation mostly is not worth it
| Technique | Effect |
|---|---|
name [at] example [dot] com | Stops naive scrapers. Annoys every human and breaks click-to-email. |
| Address as an image | Stops scrapers. Unreadable to screen readers and uncopyable. Avoid. |
| JavaScript assembly | Stops basic scrapers. Invisible to crawlers, and fails if scripts do not run. |
| HTML entity encoding | Stops almost nothing. Trivially decoded. |
Plain mailto: | Harvested. Works perfectly for everyone, including assistive technology. |
Serious harvesters render pages and handle every one of these. You are inconveniencing legitimate visitors to slow down the least capable scrapers.
A sensible arrangement
- Publish a role address —
hello@,support@,security@— rather than a personal one. Rotatable, and survives staff changes. - Put it in plain text with a
mailto:link. - Add
Organizationstructured data including the contact point. - Publish
/.well-known/security.txtwith a security contact. - Let your provider's spam filtering do its job.
- Offer a form as well if you like, but never instead.
Addresses that should not be public
- Individual staff addresses, unless the person chose to publish theirs.
- Internal aliases such as
accounts-payable@, which are precisely what invoice fraud targets. - Addresses that bypass filtering or route into automation without validation.
What our audit reports about this
Every item below is measured directly, not inferred. Run it against your own site and the result names the exact rule or header responsible.
- Every email address found on the page, where it was found, and whether it is obfuscated.
- Whether addresses are role accounts or personal, and whether any look internal.
- Whether a contact page, phone number or postal address is present.
- Whether
security.txtexists and names a contact.
For agents and scripts, the same measurement is at
/api/v1/contact?url=yoursite.com —
see the API documentation.
Related questions
Will I get more spam?
Some, yes. Filtering at any mainstream provider removes nearly all of it. The volume is usually a handful a day, against the cost of being unreachable to everyone who wanted to talk to you.
Is a contact form enough?
For trust, no. Forms are commonly broken without anyone noticing, cannot be replied to easily, and read as deliberate distance. Offer both; the address is the one that matters.
What about GDPR?
A business contact address is not a problem. The obligation is around what you do with data people send you — that belongs in your privacy policy.
Read next
How do I make my website look trustworthy?
The signals people and machines actually use — most of which cost nothing and are missing from most small sites.
ReadWhat is a security.txt file and do I need one?
A standard file telling researchers how to report a vulnerability. Five lines, and it is the difference between a private report and a public one.
ReadHow do I stop people sending email that looks like it came from my domain?
Three DNS records. Without them anyone can forge your address, including to your own customers — and this applies even if you never send email.
ReadDo I need a privacy policy on my website?
Almost certainly yes, and probably a cookie notice too. What actually triggers the requirement, and why generated policies often make things worse.
Read