Identify the actual DreamHost sending route
This guide applies to DreamHost-hosted mail, not every application or mail service attached to a domain registered with DreamHost. Registration, authoritative DNS hosting and outbound mail transport are separate facts. Inventory webmail, desktop mail clients, website contact forms and newsletter plugins individually. A domain's ordinary mailbox may use DreamHost SMTP while its website sends locally using PHP mail, which changes the signing behavior.
DreamHost says mail sent through its mail server with webmail, a mail client or an SMTP form is automatically DKIM-signed. Its documentation explicitly excludes website mail that does not use SMTP, including the usual sendmail or PHP mail route. A published key cannot sign a message by itself. Before editing DNS to fix missing signatures, check whether the application actually submits through the authenticated mail server.
Locate and publish the account DKIM record
For DreamHost-hosted mail, DreamHost creates and manages DKIM records for the domain and subdomains using its email service. Open Manage Websites, use the domain's three-dot menu and choose DNS Settings. In grid view the menu appears below the domain; in list view it appears to the right. Inspect the TXT record with _domainkey in its name. The documentation illustrates the dreamhost._domainkey selector and 2048-bit keys, but the value for your domain must come from your own panel.
If the authoritative nameservers are outside DreamHost, copy that account's full record into the actual DNS service. A record visible in DreamHost's panel does not establish public publication when another provider is authoritative. Adapt the owner name to that editor's relative-name or fully-qualified-name convention and inspect the resulting public name. Preserve the public key without inserting spaces into the key data. Do not publish the example key printed in a help article.
A selector used by a different active service must remain intact. Distinct services can publish distinct selectors, but each signature must resolve its own s= selector under its d= domain. Confirm the message's actual signature before assuming it uses the example selector. If the domain sends through another provider, obtain that provider's signing instructions instead of expecting a DreamHost key to authenticate its traffic.
Review default and custom SPF carefully
DreamHost documents this automatic policy for its mail service: v=spf1 mx include:netblocks.dreamhost.com include:relay.mailchannels.net -all. Treat it as a documented default to compare against your current configuration, not a universal replacement for an existing multi-provider policy. Confirm which hosts and envelope domains actually need authorization. SPF is evaluated separately for subdomains, so an apex record does not automatically cover a separate envelope subdomain.
Adding a custom SPF record in DreamHost removes its default record. If DreamHost is still an authorized sender, preserve the appropriate permissions in the combined custom policy after reviewing the active routes and lookup dependencies. The documentation also says deleting a custom SPF record causes the default to return automatically. That behavior matters during recovery: deletion is not necessarily removal of SPF authorization, and the restored default may omit other legitimate services.
At external authoritative DNS, manage the relevant policy there. Keep exactly one applicable SPF TXT policy at the owner. Do not add a second one to retain the default, and do not assume every include shown in a historical example is necessary forever. Recheck the published policy after changes and after any rollback, including the effect of automatically restored records.
Fix website mail at the transport layer
For a contact form or WordPress plugin that uses sendmail or PHP mail, prefer a supported authenticated SMTP configuration if the intended route is DreamHost-hosted mail. Verify the form's real output rather than only the plugin's connection test. Trigger the actual workflow, retain the received message and confirm the signer and visible From identity. An application can connect successfully but still use a different sender address in production.
DreamHost also documents self-managed DKIM installation on a Dedicated Server with an admin user or on DreamCompute, but says it cannot support that manually installed software. This is a separate system-administration project, not a checkbox equivalent to the managed SMTP route. Do not introduce it as an unreviewed workaround for a contact form. If you choose it, require a separate operational plan for keys, signing, updates and recovery.
Verify the sending identity, not just the dashboard
A green setup indicator establishes only the check that the product performed. For acceptance, send a controlled message through the actual workflow to a mailbox whose received headers you can inspect. Preserve the original message rather than a screenshot of a successful DNS lookup. Record the visible From domain, the SMTP envelope domain shown by the receiving system, each DKIM signature's d= signing domain and s= selector, and the receiving system's Authentication-Results. Do not trust an Authentication-Results field simply because a sender inserted one.
SPF authenticates the envelope identity, not automatically the visible From address. DKIM verifies a signature for its signing domain. DMARC requires a passing path that aligns with the visible From domain under the applicable alignment mode. A provider-owned envelope can pass SPF without producing aligned SPF for your brand. Conversely, a valid aligned DKIM signature can provide the passing DMARC path even when SPF does not align. Inspect the actual identities before changing DNS.
Use this illustrative acceptance case, not as a claim about a provider's default: a message has From learning@example.com, envelope bounce@vendor.example.net, and a verified DKIM signature with d=example.com. SPF success for vendor.example.net alone is not aligned to example.com; the valid signature with d=example.com supplies exact DKIM alignment. If the receiver instead reports an invalid signature, the example no longer has that passing aligned path. Record both the authentication result and the domain it applies to.
Diagnose failures in a fixed order
First confirm that the nameservers delegated for the exact domain are the servers you edited. Query the authoritative servers for the expected owner name and record type. Compare their answers with the account's supplied values, checking accidental domain suffix duplication, missing selector labels, truncated keys, and CNAME conflicts. Only after the authoritative answer is correct should you investigate recursive caching or wait for an earlier TTL to expire. There is no single guaranteed worldwide propagation deadline.
Next repeat the message test on the failing route. A web application can use a different transport from a human mailbox, and a successful preview is not proof that production notifications use the same identity. If DNS is right but the signature is missing, investigate the sending transport and product configuration rather than adding unrelated SPF permissions. If authentication passes but mail is placed in spam, retain the headers and investigate reputation, content and recipient handling separately. Authentication does not guarantee inbox placement.
Change control and completion evidence
Keep the previous record sets, the approved new values, the domain owner, the business owner of each affected workflow, and a specific recovery decision before making changes. Never create a second SPF policy at the same owner to add a sender. Review one combined policy and its DNS-lookup dependencies; unrelated TXT records can coexist, but multiple candidate SPF policies are an error. Do not overwrite another sender's selector. Do not weaken the entire domain's DMARC policy to disguise one failing integration.
Acceptance requires authoritative DNS evidence, product validation, and a received-message identity record for every in-scope sending route. Test replies separately where the workflow expects them. These are proposed checks, not completed tests: this guide is based on retained documentation and synthetic reasoning, with no live tenant changes, DNS measurements, or delivered-message results. A human owner must review the evidence and approve any production rollout. Keep existing working routes available until the replacement is demonstrated, and remove obsolete permissions only after confirming no remaining dependency uses them.
Evaluate a transport mismatch before altering policy
For written case DH-01, assume staff webmail from help@example.com has a trusted passing DKIM signature d=example.com, s=dreamhost. The website form uses PHP mail instead and has no observed DKIM signature; its SPF result is unknown. The first route has the stipulated aligned path, while the second remains unresolved rather than automatically failing every mechanism. Ask the website owner to verify the supported SMTP configuration and trigger a harmless form event in an authorized test. A panel key does not supply the missing signature. No actual message, plugin or DNS record was tested or changed.
For recovery, compare the current SPF record with the approved baseline before deleting any custom policy. In this provider’s documented behavior, deletion restores its default; that is not necessarily the same as restoring the complete previous multi-sender policy.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.