Bluehost SPF, DKIM and DMARC setup, step by step

When Bluehost hosts your DNS, publish the records supplied by your actual email sender in Domains → your domain → DNS. Bluehost Professional Email, cPanel mail and Google Workspace have different authentication settings. There is no single Bluehost SPF include or DKIM key that applies to every service. Start by identifying the mail product, then preserve the existing zone while adding or updating its records. Bluehost email-product DNS reference

This guide covers Bluehost DNS publication for external senders as well as bounded instructions for Bluehost's documented mailbox products. Buying a domain or hosting a website at Bluehost does not establish which system sends its email.

Before you change DNS

Collect the sending service's domain-authentication instructions, permission to edit DNS, the visible From domain, and the intended DKIM signing domain. Include newsletters, contact forms, invoices and support systems in your inventory, not just employee mailboxes. A WordPress site can send through a different SMTP service from its hosting company.

Check the domain's authoritative nameservers. If another provider hosts DNS, publish there even when Bluehost supplies the mailbox. Bluehost explicitly documents this distinction for Professional Email with external DNS. Do not switch nameservers merely to make an authentication editor available. External-DNS prerequisites

Save the current names, types, complete values and TTLs. The Bluehost Portal offers Domains → domain → DNS → Actions → Export DNS zone. Retain this backup and a small change list. Do not replace the entire zone, remove unrelated verification TXT records, change incoming MX records or change mail routing as part of an authentication-only repair. Bluehost DNS controls

Select the right sending product

Use the product shown in your account, not a logo or a regional storefront URL. The reviewed Bluehost documentation distinguishes these services; it does not establish one reusable native-mail SPF value for every account or region. For Workspace-side key generation and activation, use the Google Workspace authentication guide. Bluehost product distinctions

Publish sender-supplied TXT and CNAME records in Bluehost

Open Domains, choose the correct domain, then DNS → Manage Advanced DNS Records. Use + Add Record → Single record for a new owner. To change an existing record, use its three-dot menu and Edit, rather than creating a duplicate. Choose the sender's required type, complete the host/value fields and save. Current Portal procedure

For an apex SPF record, the documented TXT form uses Refers to: @. For a selector or other named host, the DKIM procedure uses Other Host / Host Name. Copy the account's required name, accounting for any domain suffix shown by the form. The saved full owner must match the sender's request exactly. SPF form and DKIM form

These are owner-name examples, not keys or authorizations to publish:

If news.example.com is a separately delegated zone, its DKIM label is s1._domainkey, not s1._domainkey.news. A repeated suffix such as example.com.example.com is an error.

For DKIM, publish the complete public TXT value or exact CNAME target hostname, whichever the sender provides. A CNAME target is not a URL: do not add https://. Publish every required selector. Do not put TXT data beside a CNAME at the same owner, overwrite an active selector belonging to another service, or paste a private key into DNS. Return to the sending service for its verification and signing activation. DNS publication alone cannot turn signing on. DKIM record and selector model

Apply the following only when the actual sender issues a CNAME, not to the native TXT-key routes. The controls belong to the authoritative DNS host, including an external host where applicable; do not assume Cloudflare controls exist in Bluehost. Where the actual authoritative DNS host offers these controls, use DNS-only aliases, not HTTP proxying or redirects, and keep a literal CNAME answer to each required target. Turn the relevant per-record Flatten option off when available, and ensure applicable zone-wide settings do not conceal the issued aliases. For Cloudflare specifically, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are Cloudflare behaviors, not assumed controls in another provider’s panel. If mandatory behavior or shared settings prevent the required CNAME answer, stop and coordinate a supported configuration without breaking dependent records. Do not blindly change the whole zone or remove an NS delegation; publish at the delegated authority when appropriate. Cloudflare CNAME verification, flattening controls.

Configure SPF without breaking existing senders

SPF evaluates the SMTP envelope MAIL FROM domain, normally shown in receiver results as smtp.mailfrom, rather than the visible From address. A provider-owned return path can pass SPF without aligning with your brand. Editing your apex cannot repair an SPF policy evaluated at an unrelated provider domain. A child MAIL FROM domain also does not inherit the parent's SPF record. SPF identity rules

Before saving, locate the existing TXT record beginning v=spf1 at the exact required owner. Keep one SPF policy there. Merge only authorizations needed for actual senders, before the terminal all, retaining the intended qualifier. Do not concatenate two complete policies. Evaluate nested includes and other DNS-lookup-causing terms against SPF's limit of ten; counting visible includes alone is insufficient. Never use +all to make an error disappear. SPF publication and processing

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

Professional Email powered by Titan

Bluehost's current Professional Email reference supplies this Titan-only SPF value:

v=spf1 include:spf.titan.email ~all

Use it as a complete policy only when it covers the owner's entire sending inventory. Otherwise incorporate the authorized Titan mechanism into the existing policy. ~all produces softfail for unmatched senders, not pass. Do not substitute the native cPanel recipe or another reseller's Titan records. Bluehost Professional Email records

Native cPanel mail

Read the current SPF suggestion in cPanel → Email Deliverability → selected domain. Bluehost's newer product reference describes this as generated per server/domain. Its separate SPF article contains different legacy examples, including a ptr recipe. Do not combine those examples or publish their includes merely because the domain is hosted at Bluehost. Use the current account-specific suggestion, reconcile other legitimate senders, and ask Bluehost to resolve a mismatch before changing the policy. Account-specific native-mail guidance and SPF article with differing examples

Enable DKIM for the matching Bluehost mailbox product

Professional Email: generate, publish, verify

You need an active Professional Email plan with the domain added and appropriate administrative access. In the Bluehost Portal, open Email, choose Manage for the correct Professional Email plan if necessary, then Email Reputation → Add DKIM record → Add. Copy the generated DNS Host Name and TXT Record Value. Portal entry point

Alternatively, an email administrator can open Email Reputation in the Email Control Panel. Publish its per-domain TXT record at the authoritative DNS provider. Then return, confirm that the TXT record has been added, and select Verify changes. The documented completion state is VERIFIED, after which outgoing signing is automatic. The selector and public key are generated values, not a universal titan1 example. Professional Email DKIM setup and activation

Native cPanel: copy the suggested record

Open Hosting → My Plans → cPanel → Email → Email Deliverability, then Manage beside the domain. Copy Name and Value under the suggested DKIM TXT record. Bluehost's dedicated DKIM guide explicitly warns against using Install the Suggested Record and directs publication through the Portal instead. Use that manual procedure, or publish at external authoritative DNS when applicable. The guide says status updates after DNS processing; a new delivered message remains the signing test. Native-mail DKIM procedure

Do not regenerate a working key merely because a checker queried the wrong selector. If account instructions contradict the manual procedure, have Bluehost confirm the correct authoritative zone before using an automatic repair.

Add or retain DMARC safely

DMARC passes when either SPF passes with an aligned envelope domain or DKIM passes with an aligned d= domain. Relaxed alignment means the same organizational domain; strict alignment requires the exact domain. For ordinary example.com branding, bounce.example.com can align in relaxed mode but not strict mode. Inspect existing aspf and adkim settings rather than assuming the defaults. Current DMARC standard

Preserve an existing DMARC policy and reporting destinations. Check for an inherited parent policy before adding one for a subdomain. Do not replace quarantine or reject with none simply to follow a setup example. Where no established policy applies and the owner is starting a monitored rollout, this is an illustrative starting value:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the address with an approved, monitored destination. For example.com, publish at _dmarc.example.com using _dmarc in its zone. For news.example.com in the parent zone use _dmarc.news; in a delegated child zone use _dmarc. Keep a single applicable record at each policy owner. p=none requests no DMARC enforcement, not guaranteed acceptance. Advance enforcement only after reviewing legitimate traffic, including infrequent senders. DMARC policy discovery

Use record type TXT. For the child From domain news.example.com, the full policy owner is _dmarc.news.example.com; the existing parent-zone and delegated-child labels above refer to this same owner. This remains conditional on an owner-approved first-policy rollout with no direct or inherited policy to preserve. DMARC publication.

An external reporting service may need destination authorization in its own DNS. Use that service's account-generated reporting address, not an address copied from an article. Reports summarize observed traffic; they are not an inbox-placement test. Use the DMARC report-reading guide to investigate sources. External report authorization

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.

Verify DNS, then verify a delivered message

Replace example.com, bounce.example.com, s1 and ns1.dns-host.example below with your actual domain, MAIL FROM owner, generated selector and authoritative nameserver. These are read-only command examples, not recorded test results.

dig +short NS example.com
dig @ns1.dns-host.example TXT example.com +noall +answer
dig @ns1.dns-host.example TXT s1._domainkey.example.com +noall +answer
dig @ns1.dns-host.example CNAME s1._domainkey.example.com +noall +answer
dig @1.1.1.1 TXT example.com +noall +answer
dig @1.1.1.1 TXT bounce.example.com +noall +answer
dig @1.1.1.1 TXT _dmarc.example.com +noall +answer

Query each authoritative server and repeat selector queries through a public resolver. Expect the exact SPF owner/policy, every required DKIM record and the retained DMARC policy. For CNAME DKIM, follow the returned target with a TXT query and check that it resolves to the sender-managed public key. Multiple quoted chunks within one TXT record can be valid; multiple separate SPF records are not. NXDOMAIN means the queried name does not exist; SERVFAIL or timeouts need DNS investigation. Waiting does not correct a wrong owner.

Once sender-side verification is complete, send a newly authorized test through each production route to a mailbox where you can inspect raw headers. Read the final receiver's trusted Authentication-Results, not arbitrary upstream text. Record:

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

• Visible From domain and actual smtp.mailfrom identity, with the SPF result and sending IP.
• Intended branded DKIM d= domain and expected s= selector, with a matching dkim=pass result.
• dmarc=pass for the visible From domain and the mechanism that supplied alignment.

Do not sign off a DKIM change merely because DMARC passes through SPF or an unrelated provider signature passes. If SPF is fail, softfail, neutral, none, temperror or permerror, investigate the actual envelope-domain policy. For a direct path expected to pass, that result is an unresolved fault even if aligned DKIM rescues DMARC. Test forwarding separately. Trusted authentication results

For a branded DKIM deployment, require the intended sender’s specific signature to report trusted dkim=pass and its d= to align with the intended unchanged From under the effective adkim mode, plus trusted receiver dmarc=pass. A rewritten identity or SPF-only DMARC success does not satisfy that gate. DMARC identifier alignment.

Troubleshooting and rollback

For rollback, restore only the affected record from the saved version, after checking for intervening legitimate edits. Do not restore the whole zone. Preserve old DKIM selectors until the sender's rotation procedure allows retirement and queued mail has cleared. Recheck DNS and unaffected senders after any repair.

Documentation review and testing limits

This guide is based on current public documentation, not access to a customer's account. No DNS records were changed, no messages were sent, and no live delivery, inbox placement or search ranking was tested. Confirm generated values and product behavior in your own account before making an authorized change.