If you’re not tech-savvy and don’t have your own custom (professional) email address, it’s very tempting to use an email address from a free domain service like firstname.lastname@example.org to send your email campaigns on Brevo.
You’ve probably been using the same old email address for years on your free webmail app to contact your subscribers, clients, or partners, and it’s never been an issue. So why would you change?
There are a few reasons why you should consider using a custom email address on your domain name.
Free webmail accounts are designed for one-to-one emails
Moving your email campaigns from your own personal or professional Gmail account to Brevo can be pretty traumatic for webmail providers. It may sound a bit dramatic, but imagine if you had been driving a very old car for years and then suddenly switched to a racing car. If you’re not adapting how you’ve been driving your old car, you’ll likely end up hitting a wall and breaking everything.
Free webmail accounts (from Gmail, Outlook, Yahoo, etc.) are designed for one-to-one communication. These free services were never intended to be used to send bulk emails, and for that reason, most webmail providers make it pretty hard to send an email to many people at once.
Free webmail providers impose technical limitations to ensure that most of the email traffic exchanged within their own environment is clean and legitimate. That's why a spammer will not bother adding each contact manually in BCC, they need much more optimized tools to reach a maximum amount of people in a short space of time.
ESPs, like Brevo, are specifically designed to send mass email campaigns. These systems allow you to import (very) large contact lists, design and send your email campaigns to thousands of people in no time. This sounds great for marketers, right?
The downside is that what’s helpful for marketers is also helpful for spammers, so they tend to look for these solutions to send unsolicited messages. As you can imagine, this doesn’t go well with ISPs and webmail providers. To protect their users from over-flooded inboxes, they have strong spam filtering systems to catch a maximum of emails sent from these external environments.
Brevo, like all other ESPs, works very hard on preventing spam to maintain the best possible relationship with the ISPs and webmail providers. But from a webmail’s perspective, an email coming from an ESP will always look more suspicious compared to an email sent from a private environment to a limited number of recipients. Therefore, the sender needs to reassure the ISPs and webmail by being transparent about who they are and what they send. This starts with showing your real identity as the sender.
Since anyone can hide behind a Gmail address, there is no way of showing who you are when using such an email address to send emails.
Domain authentication for an optimal delivery
To understand why domain authentication is so impactful, it’s important to know that it’s very easy for any spammer to spoof someone’s domain and send emails from that domain.
Spoofing a domain is when a spammer uses a domain that doesn’t belong to them to send spam or fraudulent emails, pretending to be someone else. This practice is, of course, totally illegal but very popular among spammers.
Although the most frequently spoofed domains are well-known ones like amazon.com, apple.com, netflix.com, etc., smaller companies may also have their domain name used illegally to send malicious emails.
While there is no way to prevent such practices, it is possible to make your own emails look legit to webmail providers by using email security protocols such as:
- Digitally signing your emails with your domain name (DKIM)
- Defining a set of rules to help the webmail provider decide what to do with incoming emails sent from your domain without proper DKIM implementation.
If you don’t have your own domain registered and you are using a free email address to send your email campaigns on Brevo, then you won’t have the possibility to authenticate your emails, which doesn’t look great for the receiving servers.