How I Got a Professional Email on My Own Domain for Free, and the Gmail Change Coming in 2027

Picture this. A company sends you a quote for a big job. The letterhead looks sharp and the prices are fair. Then you look at who sent it: yourbusinessname2019@gmail.com.

Be honest. Something small inside you trusts them a little less.

I had my own version of this problem. For years I juggled two Gmail addresses. The older one, more than ten years old, kept filling up its storage and needed clearing out every so often. And neither of them matched my website. When I rebuilt chukwumaukaha.com, I wanted a proper address on my own domain: hello@chukwumaukaha.com. But I did not want to pay a monthly bill per user just to send a few emails a week.

So I built a free setup. Emails sent to hello@ land in my Gmail inbox, and when I reply, the reply goes out from hello@, not from Gmail. It passes every security check that Gmail itself runs. I tested it, and it has worked perfectly.

Then, while researching this post, I found out that Google has announced a change that affects exactly this kind of setup, starting January 2027.

So this post does two things. It shows you, step by step, how I set up a professional email on my own domain for free, including the three records that keep your emails out of spam. And it tells you honestly what is changing, what still works, and what I would choose if I were setting this up today.

Why an email on your own domain matters

There are two reasons, and the second one is less obvious.

The first is trust. An address like hello@yourbusiness.com tells people you are an established business with your own corner of the internet. It matches your website, your business cards and your invoices. When a customer sees it, they don't have to wonder whether they are dealing with the real company.

The second is whether your emails get delivered at all. Email providers have become strict about checking who is really sending a message. Since February 2024, Google's email sender guidelines have required everyone who sends to Gmail accounts to authenticate their email with at least one of two records, called SPF and DKIM. Senders who send around 5,000 or more messages a day to Gmail must have both, plus a third record called DMARC. Google recommends that everyone set up all three, whatever their size.

Don't worry about those three names yet. I will explain each one in plain English later in this post. For now, just know this: when you own your domain, you can set up these records properly. That is how you tell Gmail, Outlook and Yahoo that an email claiming to come from you really did come from you.

Receiving and sending are two different jobs

The biggest thing I learned is that email is really two separate jobs, and the free tools each do only one of them.

Think of it like a business address at the post office.

• Receiving is like having a post office box at your business address that automatically forwards every letter to your house. People write to your business name, and the letters still reach you.

• Sending is like posting a letter in an official envelope that carries your company's stamp, one the post office recognises as genuinely yours.

My free setup used three pieces:

1. Cloudflare Email Routing receives. Anything sent to hello@chukwumaukaha.com is forwarded to my Gmail inbox. It is free on Cloudflare's free plan.
2. Resend sends. Resend is an email sending service with a free plan. It sends my replies out as hello@chukwumaukaha.com, properly signed as my domain.
3. Gmail is where I read and write. I connected Gmail to Resend with a feature called "Send mail as", so I could reply from hello@ without leaving my inbox.

That third piece is the one Google is changing. I will show you the whole setup first, then what to use instead of piece number three.

Part 1: Receiving email with Cloudflare Email Routing

This part still works perfectly, costs nothing, and is the foundation of everything else.

One requirement first: Cloudflare's documentation says your domain must use Cloudflare DNS. My domain is registered with Namecheap, but its nameservers point to Cloudflare, so Cloudflare manages its DNS records. Moving your nameservers to Cloudflare is free.

Here is what I did:

1. Open Email Routing. In the Cloudflare dashboard, open your domain and go to Email Routing.
2. Let Cloudflare add its records. It adds MX records, which tell the world where to deliver email for your domain, plus records that authorise and sign the forwarded mail.
3. Add and verify your destination. Enter the Gmail address that should receive your mail. Cloudflare sends it a verification link. Nothing works until you click it.
4. Create the address. I created a rule that sends hello@ to my Gmail. I also turned on the catch-all rule, so mail sent to any address at my domain, even a typo, still reaches me instead of bouncing.
5. Test from a different account. Send a message to your new address from an email account that is not your destination Gmail. Cloudflare's own guide warns that some providers quietly drop messages that look like they came from the same account they are being delivered to.

Here is the error that stopped me. When I clicked to activate Email Routing, Cloudflare refused with a message saying that existing non-Cloudflare MX records conflicted with Email Routing. My domain still had five old MX records left over from Namecheap's free email forwarding, which I had never used. A domain can only send its mail to one place, so those old records had to go. I deleted them, clicked activate again, and it worked. Before you delete records like these, copy their values somewhere safe, just in case.

If you see that error, that is almost certainly what it means.

One more thing I learned on a client project. The online French school I built uses this same Cloudflare setup for its contact@ address. Receiving worked perfectly from day one. But because Email Routing only receives, every reply went out from the founder's personal Gmail address. A careful customer could see the seam: they wrote to contact@ and got an answer from a Gmail address. That is exactly the gap Part 2 closes.

Part 2: Sending as hello@ through Resend

Cloudflare Email Routing cannot send email at all. To reply from hello@, you need a service that sends on your behalf, and DNS records that prove you allowed it.

Step 1: Create a Resend account. Resend's free plan allows 3,000 emails a month, up to 100 a day, which is far more than enough for replying to enquiries.

Step 2: Add and verify your domain. Resend gives you a few DNS records to add, including a DKIM record that lets it sign emails as your domain. I added them in Cloudflare exactly as shown. Two things to watch here. Set these records to "DNS only", the grey cloud, not the orange one, because mail records must not be proxied. And if Resend asks for an MX record on a sending subdomain, like send.yourdomain.com, that is fine. It does not clash with Cloudflare's MX records on your main domain.

Step 3: Create an API key to use as your password. This surprised me. Resend's SMTP settings don't use a normal username and password. The host is smtp.resend.com, the username is literally the word "resend", and the password is an API key you create in the dashboard. Give it sending access only, and copy it immediately, because Resend shows it just once.

Step 4: Connect Gmail. In Gmail settings, under Accounts and Import, I used "Send mail as" to add hello@chukwumaukaha.com with Resend's SMTP details. Gmail sent a verification code to hello@, which Cloudflare forwarded straight back into the same Gmail inbox. I entered the code and set hello@ as my default sending address.

Step 5: Test properly. I sent a message from hello@ to an address on a different provider, not another Gmail, because Gmail to Gmail can hide problems. It arrived in the inbox, not spam, and the sender showed as hello@chukwumaukaha.com. Then I replied to confirm the round trip.

The change coming in January 2027

Here is what I found while writing this post. Several tech publications, including Android Authority, have reported Google's announcement that from January 2027, Gmail will no longer support "Send as" for third party email addresses on the web or in its mobile apps. That includes addresses on your own domain sent through an outside service, which is exactly what Step 4 does. Google is already restricting new setups of this kind, and existing ones like mine keep working during the transition. "Send as" for Google Workspace accounts is not affected.

So my own setup will need to change before January 2027 too. Parts 1 and 3 of this post stay exactly the same. Only the place where you read and write your email changes. Here are the options I would consider:

• Keep it free with a mail app. Use an email app such as Thunderbird, Apple Mail or Outlook. It reads your Gmail inbox, where Cloudflare still delivers your mail, and sends as hello@ through Resend's SMTP settings from Step 3. Same cost: nothing.

• Use a free mailbox on your domain. Zoho Mail's Forever Free plan gives up to five users on one domain, with 5GB each. The catch: it works only through Zoho's own website and apps, without IMAP or POP, and it is only offered in some regions.

• Pay for a full business mailbox. Google Workspace, Microsoft 365 or Zoho's paid plans give you a real mailbox, calendar and team features. If several people need email, this is usually the right answer.

If you are setting this up for the first time today, I would skip Gmail's "Send as" entirely and go straight to one of these.

Part 3: The three records that keep you out of spam

This is the part most people skip, and it is the part that decides whether your emails land in the inbox or the spam folder. Here are the three records in plain English.

SPF is the guest list. It is a record in your DNS that lists which services are allowed to send email for your domain. When Gmail receives a message from you, it checks whether the server that sent it is on your list. One rule to remember: a domain should have only one SPF record. If you use several services, they all go into that one record.

DKIM is the wax seal. The sending service signs every email with a digital signature tied to your domain. The receiving server checks the signature against a public key you published in your DNS. If the seal is intact, the email was really sent with your permission and was not changed along the way.

DMARC is the instruction note. It tells receiving servers what to do when an email claiming to be from you fails those checks, and it asks them to send you reports about what they saw. A DMARC policy can say three things:

• p=none means "don't block anything yet, just send me reports".

• p=quarantine means "treat failures as suspicious, usually by sending them to spam".

• p=reject means "refuse failures completely".

I started where everyone should start, with p=none. My DMARC record looks like this:

v=DMARC1; p=none; rua=mailto:hello@chukwumaukaha.com

The rua part tells providers where to send their reports. I added DMARC only after confirming that sending worked, so I was never debugging two things at once.

Soon after, I got my first report from Google. It arrived as a zipped file full of computer code, which looked frightening at first. But what it said was simple. Google had seen two emails claiming to be from my domain, both sent through Resend. SPF passed. DKIM passed. And most importantly, both lined up with my own domain, which is called alignment. Alignment is where many setups quietly fail. A message can pass SPF and DKIM for the sending service's domain, but DMARC only counts it when those checks match the domain in the From line. Mine did.

My next step is to move from p=none to p=quarantine, once the reports have stayed clean for a while. That gives my domain real protection against anyone who tries to send fake emails pretending to be me.

A practical tip: these reports arrive daily from each provider you send to. Set up a Gmail filter so they skip your inbox and go into their own label. You will rarely need to read them, but you will be glad they are there if something ever goes wrong.

Six mistakes to avoid

These come from my own setup and from a client website. Each one cost me time, so let them cost you nothing.

1. Leaving old MX records in place. If your domain registrar or old host added MX records, Cloudflare Email Routing will refuse to activate until you remove them. Your domain's mail can only go to one place.
2. Proxying mail records. In Cloudflare, mail related records must be set to "DNS only" with the grey cloud. The orange cloud is for websites, not email.
3. Testing from Gmail to Gmail. Gmail can treat messages between its own accounts differently. Always test with an address on a different provider, like Outlook or Yahoo.
4. Rushing to a strict DMARC policy. Start with p=none, read the reports, and only tighten the policy once you know every service that sends for your domain is passing. A strict policy with a mistake in it can block your own legitimate email.
5. Letting Cloudflare hide your email address by accident. On the French school website, the footer suddenly showed "[email protected]" instead of the real address. A Cloudflare feature called Email Address Obfuscation was rewriting it to protect it from spam bots. It is a clever feature, but it confused real visitors. We turned it off and cleared the cache so the address displayed normally.
6. Forgetting what you set up. Write down which service does what, where each DNS record came from, and where your passwords and API keys are stored. Six months from now, you will not remember, and neither will the next person who works on your domain.

The limits of free, and when to pay

Free is wonderful, but it is not magic. Here is where this setup stops being the right choice:

• Volume. Resend's free plan allows 100 emails a day. That is plenty for replying to enquiries, but not for newsletters or marketing campaigns. Those need a proper email marketing tool, and they come with their own rules, like an easy way to unsubscribe.

• Teams. Forwarding works beautifully for one person. When three people need their own addresses, shared calendars and a shared inbox, a paid business mailbox like Google Workspace, Microsoft 365 or Zoho is simpler and worth the money.

• Storage and backup. With forwarding, your emails live in your personal Gmail. If that account fills up, as my old one kept doing, or gets locked, your business mail goes with it.

• Changing rules. As the Gmail change shows, a free setup built from several services depends on each of those services keeping its features. Paid business email is usually more stable.

Cloudflare has also started offering email sending in beta on its paid Workers plan. Options in this space are changing quickly, which is one more reason to check the current state of things before you set anything up.

My honest advice: if you are a solo professional or a very small business, the free route gives you a professional address and proper authentication today. If your business depends on email every day, pay for a real mailbox. It costs less per month than one lost client.

Your checklist

1. Own your domain, and point its nameservers to Cloudflare.
2. Remove any old MX records you don't use.
3. Set up Cloudflare Email Routing for your address, verify your destination inbox and turn on the catch-all.
4. Test receiving from an account on a different provider.
5. Add your domain to a sending service like Resend and add its DNS records as "DNS only".
6. Choose where you will write your email: a mail app like Thunderbird or Apple Mail, Zoho's free plan, or a paid mailbox. Avoid starting new setups on Gmail's "Send mail as", since it ends for outside addresses in January 2027.
7. Test sending to a different provider and check the email is not in spam.
8. Once sending works, add DMARC with p=none and filter the reports into their own folder.
9. When the reports stay clean, tighten DMARC to p=quarantine.
10. Write down what you set up and where.

The address is the easy part

Getting hello@ on my own domain was the easy part. Getting it right, so that my emails land in inboxes and nobody can easily pretend to be me, took a little more care. That care is what separates an email address that looks professional from one that actually works professionally.

And as the Gmail change shows, the internet keeps moving. The best setup is not the cleverest one. It is the one you understand well enough to change when the rules change.

If you would like a professional email on your own domain set up properly, with SPF, DKIM and DMARC done right from day one, send me an email at hello@chukwumaukaha.com or a message on WhatsApp. And yes, that email address was set up exactly the way this post describes.