HoneyBook provides a unified email experience that supports client communication, file sharing, team collaboration, and domain-level authentication. This guide explains how emails are sent, who receives them, how messages appear inside projects, and how multi-company accounts handle integrated email addresses. You’ll also find a breakdown of DKIM, SPF, and DMARC so you can keep your domain authenticated and your emails trusted.
Send emails and files in HoneyBook
Choose who receives your message
When you write an email or share a file, you can control exactly who receives it. Every project lists its participants—clients and team members—so you can add or remove recipients before sending. Removing someone from the “To” list prevents them from receiving or viewing that specific message.
Emails sent outside a project can go to a single contact and are managed through the contact workspace.
Which email address appears as the sender
Your sender address depends on whether you’ve integrated email:
Integrated email: Messages show your actual business email in the “From” field
No integration: HoneyBook uses a secure proxy address that still displays your business name to clients
Either way, clients reply normally, and their responses appear in the project thread.
How team member attribution works
Email and file attribution follows the creator of the content—not the sender. Even if another teammate delivers the message, HoneyBook displays the name of the person who originally drafted the file or template.
Role permissions affect who can edit or send items created by others. Owners, super admins, and admins have broader access, and other roles may be limited.
How automations send emails
When an automation delivers an email or file, it always uses the project owner as the sender. This ensures consistency regardless of who set up or triggered the automation.
Add attachments
Attachments can be added nearly anywhere: project messages, email templates, automations or automated emails (through templates), and bulk or batch emails. Payment reminders are the one exception—they don’t support attachments.
Images can’t be embedded directly in the email body and must be added as files.
How emails and threads appear in projects
How HoneyBook determines whether an email appears in a project
HoneyBook evaluates:
Who sent the message
Who received it
Whether it belongs to an existing thread
A message appears inside a project if it:
Was sent directly from that project, or
Is a reply to a thread that originated in that project, even if the reply was sent from outside the project
Messages started outside HoneyBook won’t appear in a project, even if you have email integration.
How notifications are triggered
HoneyBook sends email notifications based on activity and role:
Project activity feed messages | Messages sent from the activity feed notify:
Replies notify all participants on the thread. |
File delivery and actions | When a file is shared:
When a client views, signs, or pays within the file:
|
Adding participants and notifications
Adding someone to a brand new project sends no notifications
Adding someone to an active project with existing messages or files triggers a notification to clients and team participants
Email signature name
Your email signature pulls its name from your personal account settings. Update your profile name to change what appears in messages.
How email works across multiple companies
Login email behavior
A single HoneyBook login email is used across all companies in your account. This email address:
Can’t be changed per company
Receives all contact form submissions
Appears as the signature email when sending contracts
If you need company-specific inquiry routing, assign a team member as the inquiry recipient in secondary companies.
Email integration per company
Each company can integrate its own business email. Even with multiple companies:
You still use one HoneyBook login email for your entire account, even if you have multiple companies. Each company can have its own separate integrated email, but your account login remains the same.
Each company can use a different integrated email sender
Only one email host can be connected per company per HoneyBook login
Understand DKIM, SPF, and DMARC
What these domain records do
If you integrate an email that uses a custom domain, for example, @studio-name.com, you're responsible for setting up email authentication. These DNS records help receiving servers confirm that your messages are legitimate:
DKIM (DomainKeys Identified Mail) | Applies a cryptographic signature so receiving servers know the email wasn’t altered |
SPF (Sender Policy Framework) | Lists what servers are allowed to send mail for your domain |
DMARC (Domain-based Message Authentication, Reporting, & Conformance) |
|
2024 authentication requirements
Valid DKIM
Valid SPF
A published DMARC policy
Low spam complaint rates
Failing these checks increases the chance that your emails land in spam or get rejected.
Verify your domain settings in HoneyBook
Use HoneyBook’s DKIM and SPF domain tester to confirm your authentication is configured correctly. After fixing any issues with your domain provider, re-run the test and ensure DMARC is aligned as well.
Key takeaways
Control who receives your messages using project participants
Email attribution follows the content creator, not the sender
Automations always send from the project owner
Only messages that originate in a project—plus their replies—appear in the activity feed
Multi-company accounts share one login email but may integrate different sender emails
Custom-domain senders must maintain DKIM, SPF, and DMARC
Still have questions? Feel free to send us a message by clicking the Question Mark icon on any HoneyBook page. Our team is always happy to help!