DreamHost automatically supplies SPF and DKIM records for its hosted email. If another company hosts authoritative DNS, copy the current records from DreamHost to that DNS host. Send through DreamHost's mail server to obtain its DKIM signature: publishing a key does not make PHP mail or a different provider sign messages. Verify the actual route before changing policy. DreamHost DKIM documentation.
Identify the DreamHost service you actually use
A domain registered at DreamHost can use DreamHost mail, Google Workspace, another mailbox provider, or several application senders. Registration, website hosting and email transport are separate services. This guide covers regular DreamHost-hosted mail, not self-managed signing on Dedicated Server or DreamCompute and not Google Workspace simply purchased through DreamHost.
For each workflow, write down its visible From address, configured sending server and owner. Include webmail, desktop clients, website contact forms, password resets and newsletters. A working mailbox test does not certify a website form that bypasses the mailbox's SMTP server.
Before proceeding, confirm that the domain has an actual DreamHost email address configured. DreamHost's email DNS guide describes the records that appear after an address is added. Do not assume a web-hosting plan or parked domain already has the mail service provisioned. No universal price, plan inclusion or regional variation is assumed here. Locating DreamHost email DNS records.
Collect a copy of existing DNS, an approved sender inventory, DNS-administrator access, and a controlled recipient mailbox for verification. Decide who can restore the prior SPF policy if another sender stops authenticating. Preserve unrelated TXT verification tokens and existing DKIM selectors.
Find the authoritative DNS host
Run a nameserver lookup for the domain or check its delegation in the registrar account. The administrator of those authoritative servers must publish the records. If the nameservers point elsewhere, changing DreamHost's panel alone will not change the public answers.
In DreamHost, open Manage Websites, use the domain's three-dot menu and select DNS Settings. This works from the documented Grid or List views. Identify the email records for the exact domain or subdomain, then export or copy their complete values. DreamHost record-location instructions.
There is usually no reason to change nameservers merely to repair authentication. A nameserver move affects the whole zone. Likewise, replacing MX records changes where incoming mail arrives. Keep those operations out of an SPF/DKIM repair unless a separate mail migration requires them.
If your DNS is externally hosted, make a small change sheet containing owner, type, value and TTL for each required record. Have the DNS administrator report the resulting fully qualified owner name. This avoids the common ambiguity between “we added the record” and “we added it at the name receivers actually query.”
Verify or publish the DreamHost DKIM TXT record
DreamHost's documented selector is dreamhost. For example.com, the lookup owner is therefore dreamhost._domainkey.example.com, with type TXT. Obtain the full public value from your own DreamHost panel; do not copy the long example key from a tutorial. DreamHost manages signing keys for its hosted mail and documents 2048-bit keys. DreamHost DKIM record and key details.
If DreamHost already serves the authoritative DNS and the correct managed record exists, do not create a duplicate. With external DNS, copy that account's public record to the external zone. There is no private key to paste into DNS and no separate home-generated key needed for the regular hosted route.
Check how the editor handles its Name field. In an example.com zone that appends the domain, use dreamhost._domainkey; in a full-name editor, use dreamhost._domainkey.example.com. Do not create a doubled suffix. For a separate sending subdomain, use the owner and value displayed for that subdomain, not the parent's key by assumption.
For an issued signing domain such as news.example.com, the illustrative full owner is dreamhost._domainkey.news.example.com. In an editor relative to the parent example.com zone use dreamhost._domainkey.news; in a separately delegated news.example.com zone use dreamhost._domainkey; in a delegated _domainkey.news.example.com zone use only dreamhost. Use the current DreamHost-issued value for that exact child domain; the example child name is not an account setting. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.
A long TXT value may appear as adjacent quoted chunks in a DNS response. Those chunks can belong to one record and be concatenated for evaluation. They are not a reason to create multiple independent DKIM key records. Preserve the key characters without inserted spaces or omitted text. Check for an existing CNAME at the same owner before adding TXT, since the two cannot ordinarily coexist.
DKIM selects a key using the signing domain d= and selector s= in the actual message. Query that pair when troubleshooting, rather than repeatedly checking a guessed owner. DKIM selector and key model.
Preserve DreamHost authorization when editing SPF
DreamHost documents this default SPF TXT policy:
v=spf1 mx include:netblocks.dreamhost.com include:relay.mailchannels.net -all
Its custom-record behavior matters: adding a custom SPF record removes the automatic default. Deleting the custom override restores the default. A replacement that lists only another provider can remove DreamHost's authorization; deleting the replacement can remove that other provider's authorization. Neither action is a safe universal rollback. DreamHost SPF overview.
Review the entire replacement against the sender inventory. Keep required DreamHost mechanisms while adding only the authorizations required by other real routes. Do not add an include solely because a vendor's name appears on a billing list: some services use their own envelope domains and rely on aligned DKIM.
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.
At DreamHost, the documented path is Manage Websites → DNS Settings → Add Record → TXT. For an existing custom SPF record, use its pencil icon to edit. At the root, the Host field is commonly blank; do not append the domain again. The official instructions also warn that the SPF field is uneditable when using their Google Workspace configuration. If you encounter that state, identify the actual product rather than trying to force this hosted-mail workflow. Add or edit DreamHost SPF.
Publish one v=spf1 TXT record at each actual envelope domain. SPF checks MAIL FROM, not automatically visible From. A parent SPF policy does not cover every subdomain. Evaluate the ten-DNS-dependent-term limit including nested includes; it is not a count of vendors. Keep the existing final qualifier unless a separately approved policy review changes it. SPF standard.
Fix website mail at the transport layer
When mailbox mail authenticates but contact-form mail does not, compare their paths first. DreamHost says its mail-server route signs messages automatically, while a website sending without SMTP is not DKIM-signed by that route. Configure the application's supported authenticated SMTP transport instead of expecting a DNS TXT record to perform signing.
Use DreamHost's PHP-over-SMTP guidance for implementation details. Keep credentials in the application's approved secret storage, not in a public file, screenshot or support ticket. After configuration, send a fresh message from the actual form, not only a plugin's connection tester.
For a contact form, use an authorized address on your domain as From and put the visitor's address in Reply-To when appropriate. Spoofing the visitor's domain does not become legitimate because your server is authenticated. If the application instead uses a third-party API, follow that service's signing setup and keep DreamHost DNS hosting separate from its sending identity. EmailAuth's WordPress application-mail route guide helps establish that distinction.
Preserve direct and inherited DMARC policies
Read the TXT record at _dmarc.example.com before adding anything. For mail from billing.example.com, also check _dmarc.billing.example.com and the applicable ancestor policy. No local record does not necessarily mean no protection. Preserve the effective policy, reporting destinations and alignment choices; do not add a second policy or reset an inherited enforcement policy to p=none.
DMARC needs either an aligned SPF pass or an aligned DKIM pass. Relaxed alignment allows the same organizational domain; strict alignment requires exact equality. Both protocols passing for unrelated domains is insufficient. RFC 9989 is the current DMARC specification, replacing RFC 7489; its former pct rollout tag is removed. DMARC standard.
If no established policy applies, a monitored p=none introduction can be appropriate after agreeing on report handling. Review all legitimate sending workflows before increasing enforcement. Do not weaken policy to hide an application that is still using the wrong transport.
For a first policy only, with no direct or inherited protection to preserve, add one TXT record at _dmarc.example.com using v=DMARC1; p=none. In DreamHost's relative Host field enter _dmarc, not the domain again. That minimal value requests no reports; append ; rua=mailto:YOUR-APPROVED-REPORT-ADDRESS only after replacing the placeholder with an approved mailbox or reporting-service address. External destinations require the reporting authorization described in RFC 9990. Edit rather than duplicate any existing policy, and requery the TXT record after saving.
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. For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names.
Check public DNS, then inspect a real message
Replace the example names before running these read-only checks:
dig +short NS example.com
dig +short TXT example.com
dig +short TXT dreamhost._domainkey.example.com
dig +short TXT _dmarc.example.com
Expect one SPF policy retaining approved senders, a complete DKIM public key matching the current panel, and the intended DMARC policy. Repeat at the actual sending subdomain where relevant. If recursive answers disagree, query the authoritative nameserver and inspect cache TTLs. DreamHost's SPF instructions allow up to six hours for propagation, but elapsed time alone cannot prove a correct name or value.
Send controlled messages from webmail, each important client route and the real website form. At the external recipient, inspect the trusted receiver's Authentication-Results, not a header supplied by the sender. Record SPF's result and smtp.mailfrom, DKIM's result plus signing domain and selector, and DMARC's result plus visible From domain. Receiver-header interpretation.
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.
For the intended DreamHost route, require a valid custom-domain DKIM signature and check alignment rather than accepting any dkim=pass. Confirm SPF against the actual envelope identity. If a forwarded copy fails while direct delivery passes, investigate the intermediary before altering a working key.
Accept this branded-DKIM setup only when the intended provider signature has trusted dkim=pass, its actual d= aligns with the intended visible From under the effective adkim mode, and the trusted receiver reports dmarc=pass for that From. SPF-only DMARC success does not complete the DKIM deployment. Independently diagnose SPF fail or softfail (authorization mismatch), temperror (transient evaluation failure, often DNS) and permerror (uninterpretable policy, duplicates or lookup limits) at the observed smtp.mailfrom, even when aligned DKIM supplies DMARC. A passing but unaligned provider envelope is a different outcome from an SPF error. DMARC alignment, SPF results.
Troubleshooting and frequently asked questions
Why did DreamHost SPF break after adding another sender?
The custom policy may have replaced the automatic one without retaining DreamHost's required mechanisms. Compare the before-and-after values and repair the single combined policy. Do not blindly delete it, because restoring DreamHost's default may break the new sender.
Why does DKIM exist in the panel but not in public DNS?
The nameservers may point to another host, or the record may have been entered under a doubled domain suffix. Check delegation and the full lookup owner. A panel's stored value is not proof of publication.
Why is my contact form unsigned while webmail passes?
It may be using PHP mail or another transport. Fix the application route and retest the real submission. A correct DKIM key cannot sign a message that never reaches the signing server.
Should I replace DreamHost's key with one from a generator?
No. For hosted mail, the DNS public key must match DreamHost's private signer. Self-managed servers require a different key-management procedure and are outside this guide.
Does a green DNS check guarantee delivery?
No. DNS checks establish publication, not actual signing, alignment or inbox placement. Keep redacted received headers and repeat tests after transport changes. Authentication success does not override reputation, content or recipient policy decisions.
No DreamHost account configuration, DNS changes or delivered-message tests were performed for this article. Complete those checks before treating a production route as verified.