Bluehost + Google Workspace: SPF, DKIM and DMARC setup that passes

This guide walks through the complete Bluehost Google Workspace SPF, DKIM and DMARC setup. If your Google Workspace mail is landing in spam, or someone is sending invoices as your domain, the cause is almost always the same three records — published wrongly, published twice, or never published at all. This fixes that for a domain whose DNS lives at Bluehost.

Before you touch anything

Run your domain through our free record checker and screenshot the result. You will want to know what was there before, and it tells you which steps below you can skip.

What each record does

Three records, three separate jobs. Publishing one and assuming you are covered is the usual reason mail still lands in spam.

Record	What it says	Without it
SPF	Which servers may send mail for your domain.	Receivers cannot tell your mail from a forgery.
DKIM	A signature proving the message was not altered in transit.	Mail can be tampered with and still look valid.
DMARC	What to do when a message fails, and where to send reports.	Failures are delivered anyway, and you never learn who is spoofing you.

Since 2024 Gmail and Microsoft both expect all three from anyone sending at volume. A missing DMARC record alone is now enough to affect placement. The formats themselves are open standards: SPF (RFC 7208), DKIM (RFC 6376) and DMARC (RFC 7489).

Step 1 — Find the DNS editor and lower the TTL

In Bluehost: Account Manager → Domains → select domain → DNS, or cPanel → Zone Editor

Set TTL to 300 while you work; Bluehost defaults to 14400. TTL is how long resolvers cache a record — at four hours, a typo takes four hours to correct everywhere; at five minutes it is effectively reversible. Put it back once everything passes.

Bluehost-specific warning

cPanel servers usually publish a default SPF record of their own at account creation, often with +a +mx +ip4:…. It is still there even if you never touched DNS — find it before adding yours, or you will end up with two.

Step 2 — Audit what is already there

List every record of type TXT and write down anything starting with v=spf1.

• Zero SPF records — straightforward; you add one in step 3.
• Exactly one — you will edit it, not add another.
• Two or more — already broken, and the most common state we find. Step 3 fixes it by merging.

Note any include from a previous host. Whether you keep it comes down to one question: does that server still send mail for you? A website contact form or WooCommerce order notification counts. If nothing sends from there any more, drop it.

Step 3 — Publish exactly one Bluehost Google Workspace SPF record

Add a new record in Bluehost with these values:

Field	Value
Type	TXT
Host Record	@
TXT Value	v=spf1 include:_spf.google.com ~all
TTL	Low, as set in step 1

Bluehost's Host Record field takes @ for the root, and shows the full resulting name to its right. Enter the value unquoted and on one line.

If you also send from your website or another service

Merge, never duplicate. One record, one v=spf1 at the start, one ~all at the end, every include in between:

v=spf1 include:_spf.google.com include:othersender.example ~all

Keep the total number of DNS-resolving mechanisms — every include:, a:, mx: and redirect= — at ten or fewer. Above ten, SPF returns a permanent error and fails as though absent.

The mistake that breaks the most mail

Adding a second SPF record when you connect a new provider. Two records do not combine — they make SPF fail completely, which is worse than having none. If your checker result showed two, deleting one is the highest-value thing you will do today.

Why ~all rather than -all? Softfail marks unlisted senders as suspicious; hardfail rejects them outright. Start with ~all and tighten once DMARC reports confirm nothing legitimate is being missed. Never use +all — it authorises the entire internet to send as you.

Step 4 — Generate the DKIM key in Google Workspace

This half happens in Google Workspace, not Bluehost. Go to Google Admin console → Apps → Google Workspace → Gmail → Authenticate email.

1. Select your domain from the dropdown, then click Generate new record.
2. Choose 2048-bit. If Google warns that your DNS host may not support long keys, ignore it — it does.
3. Leave the prefix selector as google unless you have a reason to change it.
4. Copy the whole v=DKIM1; k=rsa; p=… value — it is long, take all of it.

Leave that tab open — you come back to it in step 5, and forgetting to is the second most common failure.

If Google Workspace has moved its screens around since this was written, its official DKIM instructions always show the current path.

Add the DKIM record in Bluehost

Field	Value
Type	TXT
Host Record	google._domainkey
TXT Value	The whole v=DKIM1; k=rsa; p=… string from Google Workspace
TTL	Low, as set in step 1

Use the bare host as shown — not the full google._domainkey.yourdomain.com, for the same reason as the SPF record. If the value is rejected as too long, remove any line breaks your clipboard introduced; it must be one continuous string.

Step 5 — Switch signing on (the step everyone forgets)

Publishing the key does nothing on its own. Wait five to ten minutes, return to the same Admin console page and click Start authentication. Until you do, your mail is unsigned no matter how correct the DNS record is.

If Google says it cannot find the record, wait another ten minutes rather than regenerating the key — regenerating invalidates what you just published and restarts the step.

Step 6 — Publish DMARC in monitoring mode

Back in Bluehost, one more record:

Field	Value
Type	TXT
Host Record	_dmarc
TXT Value	v=DMARC1; p=none; rua=mailto:you@yourdomain.com; fo=1
TTL	Low, as set in step 1

Start at p=none. It enforces nothing, but it starts the aggregate reports arriving, and those reports are how you find the sender you forgot about — the invoicing tool, the CRM, the old newsletter platform.

Resist going straight to p=reject. On a domain with a forgotten sender, reject means those messages vanish silently, and the first you hear of it is a client asking why they never got your quote.

Step 7 — Verify, then tighten

Wait fifteen minutes, then check all three. From a terminal:

dig yourdomain.com TXT +short
dig google._domainkey.yourdomain.com TXT +short
dig _dmarc.yourdomain.com TXT +short

Or run the domain through our record checker, which flags duplicates and weak policies for you. For an end-to-end test, send a message to a Gmail address you own, open it and use Show original — you want PASS beside SPF, DKIM and DMARC. Once all three pass, your Bluehost Google Workspace SPF, DKIM and DMARC setup is done — the rest is tightening.

The tightening schedule

• Week 1–2: leave p=none and read the reports. Identify every legitimate sender.
• Week 3: add missing senders to SPF (merged into the one record), then move to p=quarantine.
• Week 5+: if reports stay clean, move to p=reject and change SPF to -all.
• Finally: restore the TTLs.

A note on MX records

Google's current single MX is smtp.google.com at priority 1. Older setups use the five aspmx.l.google.com records; either works, but do not mix them with another provider's MX.

MX records are separate from the Bluehost Google Workspace SPF record: MX decides where mail for your domain is delivered, SPF decides who may send it. Authentication cannot fix a routing problem. If mail is not arriving at all — as opposed to arriving in spam — the MX records are where to look first, not SPF.

When it still does not work

Mail still in spam with all three passing

Authentication is necessary, not sufficient. Check your domain and sending IP against a blocklist, make sure you are not mailing purchased lists, and give a brand-new domain a few weeks of low-volume sending before expecting good placement.

Google Workspace says the DKIM record cannot be found

Nine times out of ten the host field contains the domain twice. Open the record in Bluehost and confirm it reads exactly google._domainkey.

SPF was fine, then broke after adding a service

That service told you to "add this SPF record" and you added a second one. Merge them into one.

DMARC reports arrive as unreadable XML

They are meant to — the format is for machines. Paste one into any free DMARC report analyser, or point rua at a reporting service that renders them for you.

Bluehost Google Workspace SPF, DKIM and DMARC: quick answers

How long do Bluehost DNS changes take to work?

It depends on the TTL. On Bluehost: Set TTL to 300 while you work; Bluehost defaults to 14400. With a low TTL most resolvers see a change within 15 to 60 minutes; at a four-hour default, allow up to four hours, occasionally longer.

I already have an SPF record on Bluehost. Do I add another one for Google Workspace?

No. Edit the record you have and add include:_spf.google.com to it, keeping a single v=spf1 at the start and one ~all at the end. A second SPF record makes SPF fail for every message.

Which DKIM record does Google Workspace use?

Google Workspace uses one TXT record at google._domainkey, generated in Google Admin console → Apps → Google Workspace → Gmail → Authenticate email. Publishing it is only half the job — signing has to be switched on as well, as in step 5.

Which DMARC policy should I start with?

p=none with a rua= address, so reports start arriving without anything being blocked. After two or three weeks of clean reports move to p=quarantine, then to p=reject.

Can someone do this for me?

Yes. We publish the records on Bluehost, configure Google Workspace, verify that all three pass and send you the proof, for $49 flat — get in touch. Using a different host or mail provider? Every combination is in the guides hub.