The problem: a website but no address
Most public listings give you a company name and a website. Far fewer give you an email address. A trade fair list, a directory export or a scraped overview often has an email for one row in three, if that.
The website is not useless, though. The domain in www.bakery-miller.com is almost always the domain the company uses for email too. From there you can make an educated guess. This guide explains how far that guess goes and where it stops.
Start by cleaning the domain
Before you add anything, reduce the website to its bare domain:
- Strip the protocol:
https://andhttp://. - Strip
www.at the start. - Strip everything after the domain: paths, query strings and trailing slashes.
- Check for directory or social links posing as a website. A Facebook page or a directory profile is not the company's domain.
So https://www.bakery-miller.com/contact?ref=list becomes bakery-miller.com. Riftjaw does this for you when it derives addresses, but it helps to know what happens.
Common address patterns
Companies build their addresses in a handful of ways. For people, the usual patterns are:
firstname@domain, common in small companies.firstname.lastname@domain, the most widespread pattern in larger organisations.f.lastname@domainorflastname@domain.firstnamelastname@domain.
Personal patterns need a name, and the right one. Without knowing who works there, and how the company writes names with prefixes or double surnames, a personal guess is a long shot. For outreach from public listings, generic role addresses are usually the more practical route.
Generic role addresses
Almost every business uses one or more shared inboxes. The common ones are info@, contact@, hello@, sales@, office@ and support@. Which one fits depends on your message: a supplier offer belongs at sales@ or info@, a partnership question at hello@ or contact@.
Role addresses have two advantages. They are read by whoever handles incoming business mail, so your message reaches the right desk more often than you would think. And they are usually less tied to one specific person, which matters for the GDPR point below.
In Riftjaw you tick the prefixes you want when deriving from the domain, and you can add your own, such as orders@ or a sector specific one. There are no credits, so trying several prefixes costs nothing extra.
Why a derived address is a guess
A derived address is built from a pattern. Nobody has checked that the mailbox exists. info@bakery-miller.com might be live, might forward to the owner, might have been switched off years ago, or might never have existed.
Some domains accept mail for every address, so even a mail that does not bounce proves little. Others reject anything unknown straight away. You find out which one you are dealing with only by sending.
Treat derived addresses accordingly. Keep them marked as derived, and when a real address turns up in the source file, use that one. In Riftjaw an existing email column always wins over a derived address.
Bounce risk, and how to keep it small
Every mail to a non-existent address comes back as a hard bounce. Mailbox providers watch your bounce rate. A handful is normal. A large share in one send tells them you mail lists you have not checked, and your next mails start landing in spam, including the ones to real customers.
- Send a small first batch. Mail twenty or thirty derived addresses first and look at what bounces before you send to the rest.
- Remove hard bounces the same day. Tag the record, set it aside and never mail that address again.
- Prefer one good prefix. Sending to
info@,sales@andhello@at the same company triples your bounce risk and looks like spam to the person who gets all three. - Keep your sending setup in order. SPF, DKIM and DMARC matter even more when some addresses are guesses. The deliverability guide covers them.
Riftjaw sends campaigns in small batches of ten, with pause and resume, so you can stop the moment the first results look wrong.
The GDPR angle
A personal work address like anna.smith@company.com is personal data. A generic address like info@company.com usually says less about a specific person, which is one reason role addresses are the more careful choice for a first contact. Sole traders are the exception: their info@ address often is them.
Deriving does not change your duties. You still need a basis such as legitimate interest, you still inform people at first contact, and you still stop when someone objects. Record where the domain came from and that the address was derived. The GDPR guide goes through it step by step. This is general information, not legal advice.
