Why You Need email@yourdomain

This stopped being a question about looking professional in 2024. Google now requires every sender to authenticate their mail, and the way you do that is by publishing records on a domain you control, at your domain provider. A gmail.com address gives you no domain to publish anything on, so there is nothing to authenticate in your name. That is a mechanism, not a matter of taste, and it lands on exactly the mail a guide cannot afford to lose: deposit requests, trip confirmations, the message with the meeting spot and the time. The presentation argument is real too, and it is now the smaller of the two. If you have not registered a domain at all yet, start with choosing one properly, because everything below hangs off it.

Is this actually about looking professional?

Partly, and that used to be the whole argument. The bigger reason now is mechanical: since 2024 Google requires senders to authenticate mail sent to personal Gmail accounts, and authentication is something you can only do on a domain you own. A free address cannot satisfy it in your name.

The presentation case has not gone away. An address at your own business reads as a business, and a booking confirmation asking someone to send a deposit lands differently depending on what is after the at sign. Guides know this intuitively, which is why the advice has been around for years.

What changed is that the advice acquired teeth. It used to be a soft recommendation you could reasonably ignore for a season or two. It is now tangled up with whether your mail arrives at all, and that moves it from the nice-to-have list to the same list as having a phone that works.

Fishing Guide Service with Lee Tauchen, WI

What does Google now require of every sender?

At minimum SPF or DKIM, set up for your own sending domain. Bulk senders need SPF, DKIM and DMARC together. Google states plainly that messages which are not authenticated with these methods might be marked as spam or rejected outright.

The relevant language is worth reading in the original. Google's email sender guidelines say that starting in 2024, senders must meet the stated requirements to send mail to personal Gmail accounts, and that the authentication methods must be set up "for your domain," at "your domain provider." Mail failing those checks "might be marked as spam or rejected with a 5.7.26 error."

Note who this applies to. A personal Gmail account is anything ending in gmail.com or googlemail.com, which is a very large share of the people booking fishing trips. This is not an enterprise concern that trickles down eventually. It is the inbox your clients are actually using.

These requirements do change, and Google revises the page as it goes, so confirm the current rules on their guidelines page before you rely on any specific detail here.

Why can a gmail address not meet that requirement?

Because authentication is published as a DNS record on a domain, and you do not control gmail.com. Google does. There is no place for you to state which servers may send as you, because the domain making that statement would have to be Google's, about Google's own mail.

Work through what the receiving server is actually doing. A message arrives claiming to be from an address. The server looks up the domain part of that address in DNS and asks: does this domain vouch for the server that sent this? For a domain you own, you have published an answer. For gmail.com, the answer belongs to Google and describes Google's infrastructure, not your boat business.

This is why the usual workarounds do not work the way people hope. You cannot add records to somebody else's domain. Registering your own is not a formality that makes the address prettier; it is the thing that gives you a place to stand when a receiving server asks who you are.

Google is also direct about the display-name version of this. In the section on deceptive practices it lists using an @gmail.com domain as the display name for bulk email as a form of spoofing to avoid. Dressing a free address up as a business is specifically called out.

What are SPF, DKIM and DMARC in plain terms?

Three short public notes attached to your domain. SPF lists which servers may send mail as you. DKIM adds a signature proving a message really came from your domain and was not altered. DMARC tells receiving servers what to do when a message fails the first two.

SPF is the guest list. You publish a record naming the mail services allowed to send on your behalf, and Google notes that the record should include all of your senders. If you send through your email host and also through a booking system that emails clients on your behalf, both belong in that record, or the booking mail starts looking suspicious.

DKIM is the signature. Your sending service signs each message with a private key, and the matching public key lives in your DNS so anyone can check it. Google specifies a key of at least 1024 bits for personal Gmail and recommends 2048 where your provider supports it.

DMARC is the instruction. It tells receivers whether to deliver, quarantine or reject mail claiming to be from you that fails the checks, and it can send you reports about who is sending mail in your name. That reporting is the part guides find most useful once it is running, because it makes impersonation visible instead of invisible.

What happens to mail that fails these checks?

It is marked as spam or refused. Google names a specific rejection, a 5.7.26 error, for unauthenticated mail. The failure mode that costs a guide money is quieter than a bounce though: the message is accepted and filed in a folder your client never opens.

Think about which of your emails this hits hardest. A reply to somebody who wrote to you first is relatively safe, because the recipient's history with you counts for something. The mail at risk is the mail you initiate: the deposit request, the confirmation with the ramp and the time, the note to last year's client about spring dates. Exactly the mail that carries money and logistics.

The quiet failure is what makes this hard to notice. You do not get told that your confirmation landed in spam. You get a client who did not show up, or a deposit that never arrived, and no obvious reason why. Guides usually attribute those to the client, because there is nothing else to attribute them to. It belongs on the same list as the other silent failures worth auditing when you are deciding what to rebuild.

Does this apply if I only send a few emails a day?

Yes, at the SPF-or-DKIM level. Google's requirements distinguish between all senders and bulk senders, but the baseline applies to everyone. The heavier obligations, including DMARC and one-click unsubscribe, attach above 5,000 messages a day, which no guide business is doing.

So the practical read for a one-boat operation is reassuring: you need the basics, not the whole apparatus. Set up SPF and DKIM through whoever hosts your mail, which for most providers is a guided process rather than hand-editing DNS, and you have met the requirement that actually applies to you.

Adding DMARC anyway is still worth it, because the reports tell you if somebody is sending mail pretending to be your business. For a business where clients wire deposits, being impersonated is a real risk and not a theoretical one, and DMARC is how you find out it is happening.

The bulk-sender machinery, including the one-click unsubscribe headers defined in RFC 8058, only becomes your problem if you start sending large volumes. If you ever run a real newsletter to a big list, come back to it then.

What about the reply-to trick and forwarding?

Setting a reply-to address does not fix authentication, because the check runs against the domain the message is actually sent from, not the address you would like replies to go to. Forwarding creates its own problems, which is why Google publishes separate guidance for forwarders.

This trips people up because the reply-to field feels like it should be the important one. It is not the field the receiving server is validating. If the message leaves from a free address, that is the domain being checked, whatever you have asked replies to do afterwards.

The related habit worth dropping is auto-forwarding your business mail into a personal inbox and replying from there. Replies then go out from the personal address, which undoes the thing you set up, and clients end up with two different addresses for you and no idea which is real. Set the business address up properly in your mail app and send from it.

What does it actually take to set up?

An afternoon at most, and less if your domain and your mail are with providers that talk to each other. Register or locate your domain, choose a mail host, add the records they give you at your registrar, send a test message, and check it authenticated.

The order matters slightly. Get the domain in your own name first, at a registrar you chose, because everything else attaches to it and moving it later is the annoying part. ICANN's registrant FAQ is the plain-language reference for what registering actually gets you and what your rights as the registrant are.

Then pick a mail host. The two obvious ones are Google's own paid product and Microsoft's business plans, and plenty of web hosts and registrars sell mailboxes too. No price is quoted here because the plans change and the figures on the vendors' pages are the only ones worth budgeting from.

Then the records. Your mail host gives you a list to paste into your domain's DNS settings. This is the step guides find intimidating and it is genuinely mostly copying and pasting. If your registrar and mail host are the same company, it is often a single button.

What am I actually buying?

A place to stand. The mailbox itself is the small part; what you are buying is a domain that can make verifiable statements about your mail, and an identity that does not belong to somebody else. The monthly cost is in the range of a couple of coffees and it does not scale with your season.

The second thing you buy is separability. A business address can be handed to a new person, forwarded to a new host, or kept when you change everything else. A personal address is tangled up with the rest of your life and cannot be handed to anyone, which becomes a real problem the day you take on a second guide.

Weigh it against what a single lost booking costs you. One deposit request that lands in a spam folder in a season pays for years of this, and that is before the presentation effect on people deciding whether to send a stranger money, which is the same trust question sitting behind whether you publish your prices. The rest of what a site and its infrastructure should cost is broken down in the full cost article.

No-Fish No-Fee, MI

What should the addresses be?

Your own name for anything personal, plus a role address for the business. Something like mike@ for you and info@ or bookings@ for the general inbox. Keep the number small, and make sure the one on your website is the one you actually read.

Guides overcomplicate this. Two addresses covers almost every one-boat operation, and a third for a second guide when you have one. What you want to avoid is a general address that nobody checks, which is worse than no address at all because it silently swallows enquiries. The same logic applies to every contact route you publish across the pages a guide site needs: if it is on the site, somebody has to be reading it.

Google's guidance does suggest keeping message categories separate, with different addresses for different kinds of mail, but that advice is aimed at operations sending at volume. At your size, the discipline that matters is simply that whatever address is printed on your site, your truck and your booking page is the same one, and it is monitored.

What happens to the old gmail address?

Keep it and forward it in, but stop sending from it. Years of past clients have it saved, and turning it off loses that. What you change is the direction: mail arrives there and gets pulled into your business inbox, and everything you send goes out from the new address.

Give it a season of overlap. Update your site, your listings, your signature and your booking system on the same day, then let the old address quietly funnel in the stragglers. Most of the switching pain guides expect comes from doing it in pieces over months rather than in one afternoon.

Update the places you forget: your business listings, any directory you appear in, the address on your invoices, and whatever your booking system sends confirmations from. That last one is the one people miss, and it is the mail that matters most.

What do experienced guides do differently?

They register the domain in their own name before anything else, they set up mail at the same time as the website rather than later, and they send a test message to a friend on Gmail and actually check whether it authenticated.

The test-message habit is the one worth copying because it converts a setup you hope worked into one you know worked. Send yourself a message at a Gmail address, open it, and look at the message details. If SPF and DKIM show as passing, you are done. If they do not, you have found it now rather than during a booking.

The timing habit matters because email is the step that gets deferred. Guides build the site, launch it, and leave the email for later, and later arrives around the time the first deposit goes missing. Doing both at once costs almost nothing extra and removes the gap.

They also keep the domain registration separate from everything else, on a registrar in their own name, so that changing web host or mail host is a small job rather than a negotiation. That principle is the same one that runs through the platform comparison: own the piece everything else attaches to.

What are the common mistakes?

Setting up the mailbox and skipping the records. Letting someone else register the domain. Forwarding business mail to a personal account and replying from there. And forgetting the booking system, which sends the most important mail of all.

Skipping the records is the most common because the mailbox works without them. You can send and receive perfectly well while failing every authentication check, and nothing tells you. The only symptom is that some of your mail quietly does not arrive, which looks like nothing at all.

The booking-system omission is the most expensive. If your booking tool sends confirmations on your behalf, its servers need to be in your SPF record, or the single most important message your business sends is the one most likely to be filtered. Check that specifically after you set everything up, and while you are in there, confirm the address shown on your FAQ page matches the one you actually monitor.

The registration mistake is the one that is hardest to undo later, and it is the same failure mode that shows up across the common guide website mistakes: somebody else's name on the thing everything else depends on.

What surprises people?

That there is now a rule rather than an opinion. That the reply-to field does not help. That Google explicitly calls dressing up a gmail address for bulk mail a form of spoofing. And that Google does not track open rates, which quietly retires a metric a lot of vendors report.

The open-rate one is a useful aside for anyone being sold email marketing. Google states plainly that it does not track open rates and cannot verify third-party reported ones, and that low open rates are not necessarily an accurate indicator of deliverability problems. If somebody is reporting your open rate as the headline number, that is worth a question.

The bigger surprise is how small the job is relative to how long people put it off. An afternoon, a few dollars a month, and it removes an entire category of silent failure from a business that runs on confirmations and deposits.

What if my agency set up the email?

Check whose name the domain is in and whose account holds the mailboxes. If the domain is registered to them, that is worth fixing now rather than during a disagreement, and it is a separate question from whether they did the setup competently.

Doing the work for you is fine and normal. Holding the registration is the part to look at. Ask for the registrar login or for the domain to be transferred into an account in your name, and treat a reluctant answer as information. Do it while the relationship is good, because the leverage disappears the moment you mention leaving.

The rest of the material on getting a guide site and its infrastructure right is collected on the guide websites hub.