Business Email at Your Own Domain

SPF, DKIM and DMARC, in plain language

Three DNS records decide whether your mail arrives. They have unhelpful names and are usually explained badly, so here they are in the order a message meets them.

SPF (Sender Policy Framework) is a list, published in your domain's DNS, of the servers permitted to send mail for your domain. It answers one question: was this message handed over by a machine the domain owner authorized? It checks the envelope sender — the technical return address used during delivery — not the "From" line a human reads. SPF also has a designed-in limitation: it breaks on forwarding, because a relayed message arrives from a server you never authorized. That is expected behavior, not a misconfiguration.

DKIM (DomainKeys Identified Mail) is a cryptographic signature. Your sending server signs each message with a private key, and the matching public key is published in your DNS. The receiver verifies it and learns two things: the domain vouches for this message, and the message has not been altered. Because it signs content rather than connections, DKIM survives forwarding, unless a mailing list rewrites the body.

DMARC ties the other two to the address the reader sees. It requires alignment: the domain that passed SPF or DKIM must match the visible "From" domain. It then tells receiving servers what to do when nothing aligned passes — p=none takes no action but sends reports, p=quarantine means the spam folder, p=reject means refuse outright. The reports are how you see who is sending as your domain.

The specifications are SPF in RFC 7208 and DKIM in RFC 6376; DMARC was republished as RFC 9989 in May 2026, obsoleting the RFC 7489 that most articles still cite.

What breaks, and how you find out

Misconfigured mail authentication does not fail quietly. It fails as "our invoices stopped arriving," usually reported by a customer weeks after the change that caused it. The chain: a message goes out without a valid aligned signature, DMARC evaluates it as a failure, and if your policy is quarantine or reject, your own legitimate mail lands in spam or bounces. You never see the bounce, because it happened at the other end. The failures we find most often:

• More than ten DNS lookups in the SPF record. The specification imposes a hard limit of ten, and exceeding it makes SPF return a permanent error, which then fails DMARC. It happens gradually and innocently: the mail provider, then the newsletter service, then the accounting software, then the customer relationship system, then the electronic fax. The eleventh one breaks all of them at once.
• Two SPF records on one domain. There must be exactly one. Adding a second provider by pasting in a second record rather than merging it into the existing one fails every authentication check for the domain immediately.
• A hard-fail SPF record with a sender missing from it. Locking it down while the shopping cart, the contact form or the bookkeeper's mail merge still sends on your behalf rejects those messages on purpose.
• Going straight to p=reject without a monitoring period. The sends nobody remembered — point-of-sale receipts, appointment reminders, the scheduling tool set up years ago — are silently rejected from day one.
• A DKIM key rotated by the provider without the DNS record updated. Common after a provider change or a host migration, and it disables signing for everything.
• A DMARC record published with no reporting address. All of the enforcement risk, none of the visibility that would have warned you.
• The contact form that sends "from" the visitor. Putting the visitor's address in the "From" header fails SPF and DMARC for their domain and marks your server's reputation down. Send from your own authenticated domain and put the visitor in Reply-To.

What the large receivers actually require

The rules stopped being advisory in February 2024, when Google's Email Sender Guidelines took effect. They are the practical standard because Gmail is where a large share of your customers read their mail.

Every sender to Gmail must have either SPF or DKIM. That is the floor, and a domain with neither is gambling.

Bulk senders — more than 5,000 messages a day to Gmail addresses — must have SPF and DKIM and DMARC, valid forward and reverse DNS for the sending host, encryption in transit, a "From" header aligned with the SPF or DKIM domain, and one-click unsubscribe on marketing mail. Spam complaint rates must stay below 0.30%, and Google recommends under 0.10%.

That threshold is the number to quote when somebody asks whether they really need all this. A four-person contractor in Kemp sending quotes is nowhere near it; a business running a monthly newsletter to a lake-area list can cross it faster than expected. Either way SPF and DKIM are not optional, and the current DMARC specification is RFC 9989.

The honest answer about a gmail.com address

You have been told a free email address costs you customers. We will not repeat that, because we cannot support it.

A gmail.com address painted on a truck does not stop a septic contractor near Payne Springs from getting called. Local buying decisions run on Google Business Profile reviews, on referrals from the neighbor who used you last year, and on whether somebody answers the phone. We are not aware of any credible published study showing a conversion penalty for a free email address for a local trade, and we will not invent one to sell mailboxes.

What a free address does cost is specific, and it is not about impressions:

1. You cannot authenticate mail for a domain you do not own. You cannot publish SPF, DKIM or DMARC records for gmail.com. A domain-based sender can prove it is itself; a free-mailbox sender cannot.
2. You cannot hand it over or take it with you. The address belongs to whoever knows the password, permanently. There is no administrative console, no way to reassign it when an employee leaves, and no way to recover it if a former employee created it.
3. It cannot become sales@, service@ or billing@. One person, one inbox, and sharing access means sharing a password.
4. Some commercial systems reject it outright. Business-to-business portals, insurance systems and vendor onboarding forms not infrequently refuse free-mail domains.
5. It advertises somebody else on every invoice. Minor, real, and the only item here about appearance.

If you are a sole proprietor who lives in the Gmail app and none of those five bite, the honest middle path is to register the domain, forward your business address into the Gmail you already use, and configure "send as" so replies go out from the business address.

Mailboxes, aliases, and what you actually need to buy

The single most common way small businesses overpay for email is by buying a mailbox for every address they want to receive at. They do not need to.

An alias is an additional address that delivers into an existing mailbox. Aliases are free on Google Workspace, on Microsoft 365 and on ordinary cPanel mail, so sales@, service@, info@ and billing@ can all arrive in one paid inbox at no extra cost. A four-person business typically needs four mailboxes and fifteen aliases. Anybody pricing per address rather than per person is selling air.

What you should not set up is a catch-all address accepting anything at your domain. It sounds like insurance and behaves like a spam funnel: every automated guess at admin@, test@ and a thousand others becomes mail somebody has to read. Use explicit aliases and let the rest bounce, which also tells a legitimate sender they got the address wrong.

One more point that costs us a line item to make: your mail does not have to live on the same server as your website, and usually should not. Shared hosting means a shared IP address, and if a neighboring account is compromised and used to send spam, that address acquires a reputation problem and your mail stops delivering through no action of yours. Splitting mail off the web server is normally free and removes the risk entirely.

When you should not move your email to us

If you are already on Google Workspace or Microsoft 365 and it works, keep it. Do not move it to us or to any small host, and be wary of anybody who suggests otherwise. Three structural reasons:

• Deliverability. Mail leaving Google's or Microsoft's infrastructure carries an IP reputation no small host can match. That is the whole game in email, and it is not a competition anybody wins on effort.
• Migration risk is real and the upside is a rounding error. Moving mailboxes means the possibility of lost messages, broken calendar invitations, and reconfiguring every phone, tablet and laptop in the company.
• The mailbox is usually not the product. If your business runs on shared calendars, video meetings or a shared drive, you are not buying email from those companies, and cancelling the email cancels the rest.

If you are a two-person shop sending person-to-person mail from a single provider, you do not need a DMARC project. SPF and DKIM configured correctly by your provider is the whole job. Publish DMARC at p=none with a reporting address and stop there. Enforcement at p=reject earns its risk for domains actually being spoofed — recognizable brands, invoice-heavy operations, anyone who has already had a customer wire money to a fraudster.

You do not need a dedicated sending IP address. For a low-volume sender it is usually worse: an address with almost no mail flowing through it has no reputation and often delivers less reliably than a well-managed shared pool.

And you do not need to move email at the same time as your website. Moving both at once is how businesses lose three days of mail. Copy the mail routing records exactly as they are and change nothing.

How we set up email for a business around Cedar Creek Lake

When email at your own domain is genuinely the right purchase — more than one person receives at a shared address, staff change, or you want mail that leaves with the business rather than with an individual — the work mostly consists of not breaking anything.

We start by writing down what is already sending mail as your domain — not what you think is sending, what actually is. The mail provider, the contact form, the newsletter tool, the accounting package, the point-of-sale receipts. Every one of those has to appear in your SPF record without pushing it past the ten-lookup ceiling.

Then: one SPF record, merged rather than appended. DKIM signing enabled at the provider with the public key published correctly. DMARC at p=none with a reporting address, left there long enough to find the sender everybody forgot, and tightened only after that. Mailboxes for people, aliases for functions. Mail kept off the same IP address as the website.

We are based in Kaufman and work with businesses in Mabank, Gun Barrel City, Seven Points, Kemp, Athens and Canton. If the answer after the inventory is "your setup is fine, change nothing," we will say so.