DreamHost SPF, DKIM, and DMARC Setup for Email Domains

DreamHost SPF DKIM DMARC setup is straightforward once you know where DNS is actually managed and how DreamHost expects record hostnames to be entered. The difficult part is not copying a value from your email provider—it is avoiding duplicate SPF records, malformed DKIM hosts, and a return-path subdomain that does not align with your visible From address.

This guide covers the DNS side of authenticating a domain purchased through DreamHost. It applies whether you send transactional email, product notifications, password resets, receipts, or campaigns through an email API platform. The exact DKIM selectors and CNAME destinations will come from your sending provider, but the DreamHost workflow and the DNS rules are the same.

Start by confirming DreamHost controls your DNS

Buying a domain from DreamHost does not automatically mean DreamHost is the authoritative DNS provider for that domain. Your DNS records only take effect in the control panel that operates the nameservers currently assigned to the domain.

DreamHost says that records configured in its panel apply when the domain uses DreamHost nameservers. Its standard nameservers are ns1.dreamhost.com, ns2.dreamhost.com, and ns3.dreamhost.com. If the domain instead points to a DNS provider such as Cloudflare, another registrar, or a managed hosting company, add your SPF, DKIM, DMARC, and return-path records there—not in DreamHost. (help.dreamhost.com)

Before editing anything, inspect the DNS Settings page and scroll to the nameserver section. If the authoritative nameservers are not DreamHost's, stop there and log in to the service that owns DNS. Adding correct records in a non-authoritative panel creates a frustrating outcome: the records look right in DreamHost, but mailbox providers never see them.

Registration, web hosting, email hosting, and DNS are separate

These four services are often bundled together, which makes them easy to confuse:

• Registrar: the company through which you bought the domain name.
• DNS host: the service publishing your DNS zone and nameservers.
• Web host: where your website responds to HTTP requests.
• Email provider: the service that sends messages or receives mailbox email.

A domain can be registered at DreamHost, use a website hosted elsewhere, receive mail through Google Workspace or Microsoft 365, and send application email through an email API. None of that is a problem. The important question for this guide is simply: where is the authoritative DNS zone?

If DreamHost is authoritative, you can keep your website and regular mailbox setup exactly as they are while adding email authentication records. SPF, DKIM, DMARC, and a return-path record are email DNS changes; they do not require you to move your site or replace existing MX records.

Find DNS management in the current DreamHost dashboard

DreamHost has changed its panel navigation over time, so older instructions that say Domains → Manage Domains → DNS may not match the current layout. As of writing, DreamHost's current knowledge base describes this route:

1. Sign in to the DreamHost panel.
2. Go to Manage Websites.
3. Locate the domain you want to authenticate.
4. In Grid view, select the vertical three-dots menu under that domain; in List view, select the vertical three-dots menu to the right of the domain.
5. Choose DNS Settings from the popout menu.
6. Review the existing records, then select Add Record to create a custom DNS entry.

DreamHost's documentation also describes a closely related route for some page layouts: open the domain's Manage view, select the DNS tab, then choose Add Record. If you do not see the three-dots DNS Settings option, use the domain's Manage page and look for the DNS tab instead. (help.dreamhost.com)

The record list is the source of truth. Do not rely on a domain dashboard screen that only shows registration settings, renewal dates, privacy, or transfer controls. Those controls govern the registration, while the DNS Settings page is where you can see the actual TXT and CNAME records that receivers will query.

What to inspect before adding new records

Make an inventory before you change anything. This takes a few minutes and prevents most authentication outages.

Look for:

1. An existing root-domain SPF TXT record beginning with v=spf1.
2. Existing DKIM records containing _domainkey.
3. An existing DMARC record at _dmarc.
4. Existing CNAMEs at the return-path or bounce subdomain you plan to use, such as mail, send, bounce, or rp.
5. Other applications that send using your domain: support platforms, billing tools, ecommerce systems, CRMs, form tools, marketing platforms, and workspace mail.

DreamHost may automatically create an SPF record for domains using DreamHost email. Its documented default includes DreamHost infrastructure and MailChannels. If you also send through an external provider, you must combine the necessary authorization into one SPF policy rather than publish a second SPF TXT record. (help.dreamhost.com)

The DreamHost record format: TYPE, HOST, and VALUE

Your sending provider should display the exact records for your domain. Copy those provider-generated values exactly. Do not substitute the illustrative selectors, domains, or public keys below for the values your provider gives you.

The table shows the common DNS shapes you will enter in DreamHost. In these examples, the domain is example.com, the application sending subdomain is notify.example.com, and the provider uses a fictional infrastructure domain of mail-provider.example.

The precise CNAME target, selector, include mechanism, and DKIM public key differ by platform. Some providers issue one DKIM CNAME, while others issue two or three. Some publish a DKIM TXT record directly. Some custom return-path configurations use CNAME only; others also require an MX record and/or SPF TXT record for that subdomain. Treat your provider's domain-verification screen as authoritative for the values.

For an implementation-specific list of values, check your provider's domain-authentication instructions or the email API reference and setup guides. Copy rather than retype long DKIM values; a missing character is enough to make verification fail.

The DreamHost hostname rule that causes the most mistakes

In DreamHost, enter the relative hostname, not the full hostname under your own domain.

For example, if a provider asks you to create this DKIM record:

selector1._domainkey.example.com

enter this in DreamHost's Host field:

selector1._domainkey

Similarly:

DreamHost explicitly notes that you do not need to include the domain name in the host/name field, and that leaving the name blank represents the root domain. (help.dreamhost.com)

This is the DreamHost-specific error to watch for: pasting selector1._domainkey.example.com into the Host field can result in a record under a duplicated name such as selector1._domainkey.example.com.example.com. The same mistake affects return-path CNAMEs. If verification remains pending even though the record appears in the panel, inspect the fully rendered record name and make sure your root domain was not repeated.

Do not make the opposite mistake with the Value field. A CNAME destination is normally a complete provider-controlled hostname, such as bounce.mail-provider.example. Do not shorten a provider destination to bounce unless the provider explicitly instructs you to do so.

Add SPF without creating a duplicate policy

SPF is a TXT record that tells receiving servers which mail systems may use an envelope sender domain. The identity SPF checks is the SMTP envelope sender—often visible in message details as Return-Path, MAIL FROM, or 5321.MailFrom—not necessarily the human-facing address in the From header.

A valid SPF policy begins with v=spf1. A simple provider-managed example looks like this:

v=spf1 include:mail-provider.example -all

That does not mean every domain should use that exact record. If you also use Google Workspace, Microsoft 365, DreamHost mail, another transactional provider, or an ecommerce system, the record must include the mechanisms required for every legitimate sender using that same SPF domain.

One SPF record per hostname

The rule is simple: publish one SPF TXT record for each hostname that needs SPF. Never publish two TXT records that both start with v=spf1 at example.com.

This is wrong:

example.com TXT "v=spf1 include:mail-provider.example -all"
example.com TXT "v=spf1 include:_spf.google.com ~all"

A receiver can interpret multiple SPF records as a permanent error. The correct approach is to merge the authorized mechanisms into one policy, after confirming that both services really send using that same envelope domain:

v=spf1 include:mail-provider.example include:_spf.google.com -all

DreamHost's guidance makes this explicit: only one SPF record can be used, so additional senders must be combined into the existing record. (help.dreamhost.com)

Root-domain SPF versus return-path SPF

Do not assume that the SPF policy must always live at the visible From domain. It belongs at the domain used by the envelope sender.

For example, a message can display:

From: Acme Alerts <alerts@example.com>
Return-Path: <bounce@bounce.example.com>

In that case, SPF is evaluated against bounce.example.com, while DMARC evaluates alignment against the visible example.com From domain. A custom return-path under example.com can therefore help SPF align with the From domain under relaxed DMARC alignment.

Some providers handle that with a CNAME at bounce.example.com that delegates mail routing and SPF behavior to their infrastructure. Others ask you to publish a TXT SPF record at bounce. Follow the provider's record list exactly; do not add an SPF TXT record at a hostname already occupied by a CNAME, because a CNAME cannot coexist with other record types at the same name.

SPF choices that need caution

Avoid these shortcuts:

• Do not use +all. It permits any server to send and defeats the purpose of SPF.
• Do not add an include because you recognize a provider name. Include only services that are authorized and actively send for that SPF identity.
• Do not use a blanket root SPF record as a substitute for an application-specific return-path plan. SPF checks the envelope domain actually used.
• Do not keep stale includes forever. Old providers increase DNS-lookup complexity and expand the set of systems authorized to send.

SPF evaluation has a DNS lookup limit, so a long chain of nested include mechanisms can fail even when the text looks syntactically valid. Keeping a sender inventory is operationally important, not just organizational housekeeping.

Add DKIM records exactly as generated

DKIM uses a cryptographic signature added by the sending mail server. The receiving server reads the d= signing domain and s= selector in the message's DKIM-Signature header, then looks up a DNS record at:

selector._domainkey.signing-domain

The DNS record contains a public key directly or points to a provider-managed key. The sending provider retains the matching private key and uses it to sign mail.

DreamHost notes that its own hosted mail automatically creates and manages DKIM records for domains and subdomains using DreamHost email. That does not authenticate messages sent by an outside email API. External senders need the DKIM records issued by that external provider, even if DreamHost mail already has a dreamhost._domainkey record in the zone. (help.dreamhost.com)

DKIM TXT records

A direct DKIM TXT record often looks like this:

Host: selector1._domainkey
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqh...IDAQAB

Enter the entire public-key value as provided. Do not add quotation marks unless DreamHost or your provider specifically shows them as required. DNS interfaces may visually split long TXT values; that is not necessarily a problem if the published record resolves as a single valid value.

A selector is not a universal label. If the provider gives you vna1._domainkey, use vna1._domainkey. If it gives you s1._domainkey.notify, use that exact relative host. Do not replace it with default._domainkey, and do not assume an existing DKIM selector can be reused by another service.

DKIM CNAME records

Many modern email services use CNAME DKIM records so they can rotate keys without requiring you to update DNS. The DreamHost entry may look like this:

Host: selector1._domainkey
Type: CNAME
Value: selector1.example.dkim.mail-provider.example

The important distinction is owner name versus target:

• The Host is relative to your domain: selector1._domainkey.
• The Value is the provider's complete target hostname.

Do not create a TXT record and CNAME record with the same selector hostname. Choose the record type your provider generated. Also, do not put unrelated records at the same hostname as a DKIM CNAME.

Validate with a real sent message

DNS verification in a provider dashboard confirms that the record can be found. A real test email confirms that the provider is actually signing messages with it.

Send a message to a mailbox you control, open the original or raw message source, and find the authentication results. You want to see a result resembling:

dkim=pass header.d=example.com

A dkim=pass result with header.d=mail-provider.example can still be technically valid, but it may not align with your From domain for DMARC. A DKIM signature with header.d=example.com or a subdomain of it is generally the stronger configuration for a domain sending as example.com.

Add DMARC gradually, then enforce it

DMARC is a TXT record at _dmarc.yourdomain. It tells receiving mail systems what to do when a message claiming to be from your visible From domain fails DMARC authentication.

DMARC does not simply ask whether SPF or DKIM passed. It also checks alignment:

• SPF can satisfy DMARC only when the SPF-authenticated envelope domain aligns with the visible From domain.
• DKIM can satisfy DMARC only when the d= signing domain aligns with the visible From domain.
• In most practical setups, one aligned SPF or DKIM result is enough for DMARC to pass.

DreamHost describes DMARC as a policy layered on SPF and DKIM, with alignment determining whether a valid SPF or DKIM result actually counts for the From domain. (help.dreamhost.com)

A safe starting DMARC record

Start with monitoring, not enforcement:

Host: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100

This asks receivers to take no special action on failures while sending aggregate reports to the specified address. Use a real mailbox that your team can monitor. For a high-volume domain, reports can be numerous and XML-formatted, so a dedicated reporting inbox or a DMARC reporting service is often better than an employee's primary inbox.

After you confirm all legitimate sources pass aligned SPF or DKIM, move gradually:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; pct=25

Then increase the percentage over time, followed by a full enforcement policy:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; pct=100

Do not jump to p=reject merely because a provider dashboard says your new application domain is verified. DMARC applies to messages from every system that uses the visible From domain, including finance tools, support desks, marketing platforms, employees' mailbox providers, and legacy web forms.

There can only be one DMARC record

DMARC has the same consolidation principle as SPF: publish one valid policy at _dmarc.example.com.

If you already have a DMARC record, edit its existing value rather than adding another _dmarc TXT record. Duplicate DMARC policies can cause receivers to treat the policy as invalid. If a security or compliance team owns DMARC, coordinate the change before editing it in DreamHost.

Configure a custom return-path for SPF alignment

A return-path is the envelope sender address used for bounces, delivery notifications, and SPF evaluation. It is often hidden from the recipient's normal message view but visible in raw headers.

Without a custom return-path, an email provider may use an envelope sender under its own domain, such as:

Return-Path: <bounce@provider-mail.example>

That can still pass SPF, because the provider controls provider-mail.example. However, SPF will not align with a visible From address at example.com. DKIM alignment may still make DMARC pass, but an aligned custom return-path adds resilience and gives your domain control over the bounce identity.

A provider may ask you to configure a branded return-path such as bounce.example.com, mail.example.com, or send.example.com. In DreamHost, this commonly means adding a CNAME with a relative host:

Host: bounce
Type: CNAME
Value: bounce.mail-provider.example

Postmark and Resend both describe custom return-path domains as a way to support SPF authentication and DMARC alignment; their generated values differ by account and provider, so use the values displayed in your own domain configuration. (resend.com)

Do not put a CNAME on an occupied hostname

A CNAME is exclusive. If bounce.example.com already has an A, AAAA, TXT, MX, or another CNAME record, you cannot safely add a return-path CNAME there.

Choose a fresh, dedicated subdomain rather than trying to reuse:

• www — usually web-related and already occupied.
• mail — may be used for webmail, autodiscovery, or another service.
• smtp — may already point to infrastructure.
• bounce or rp — often safer if unused, but still check first.

The custom return-path should be dedicated to mail infrastructure. It does not need to host a website, and it should not be used as a general-purpose subdomain for unrelated DNS records.

Verify publication, authentication, and alignment

After saving records, wait for DNS to update. DreamHost says DNS changes can take several hours to fully propagate, although the actual timing varies by resolver cache and record type. (help.dreamhost.com)

Do not verify only by looking at the DreamHost interface. Use three separate checks:

1. DNS publication: Confirm that public DNS returns the expected TXT or CNAME value.
2. Provider verification: Return to your sending provider and use its domain verification action after DNS is visible.
3. Message authentication: Send a real email and inspect the recipient's raw headers.

The raw header check is the most valuable because it tests the entire chain: DNS, provider configuration, actual sending identity, signature, and receiving-server evaluation.

For a healthy message sent as alerts@example.com, look for results similar to:

spf=pass smtp.mailfrom=bounce.example.com
dkim=pass header.d=example.com
dmarc=pass header.from=example.com

The exact header wording varies by mailbox provider. What matters is that DMARC passes and that at least one of SPF or DKIM is both passing and aligned with example.com.

You can also use an email authentication checker to inspect public SPF, DKIM, and DMARC records before you send production traffic. DNS checks are especially useful for catching a duplicated host name, an existing conflicting CNAME, a missing provider target, or a second root SPF record.

DreamHost troubleshooting checklist

The sending provider cannot find my record

First, confirm that DreamHost nameservers are authoritative. If they are not, add the record where DNS is hosted.

Next, compare the full published hostname with the provider's requested hostname. The most common DreamHost issue is entering the complete hostname in the Host field instead of only the part before your domain. If the provider expects selector._domainkey.example.com, the DreamHost Host field should generally be selector._domainkey.

Finally, check whether the record type matches. A provider requesting CNAME will not verify a TXT record with the CNAME target pasted into it, and a provider requesting TXT will not verify a CNAME at the same hostname.

SPF returns a permanent error or fails unexpectedly

Search the DNS zone for every TXT value beginning with v=spf1. If more than one exists at the same hostname, merge the authorized mechanisms into a single SPF policy.

Also inspect which domain is actually in the message's Return-Path. Adding SPF at example.com does not fix SPF for bounce.example.com; each hostname is distinct. DreamHost specifically notes that SPF treats subdomains separately. (help.dreamhost.com)

DKIM verification passes, but DMARC fails

Read the message header, not just the provider's verification badge. Check header.d= in the DKIM result. If it is a provider domain rather than your domain or an aligned subdomain, DKIM may pass without satisfying DMARC alignment.

Then inspect SPF's smtp.mailfrom= domain. If it is also a provider-owned domain, neither authentication path aligns with your visible From domain. Configure the provider's custom return-path option and make sure DKIM signing is configured for your own domain.

I cannot edit an existing SPF record in DreamHost

Some DreamHost-managed email configurations can create provider-controlled DNS behavior, and DreamHost notes that its Google Workspace integration may leave the SPF field uneditable. Do not delete records blindly to work around that restriction. Identify whether DreamHost, Google Workspace, or another managed service owns the record, then use that service's documented integration path or contact support if you need to add another authorized sender. (help.dreamhost.com)

The CNAME record conflicts with another record

Do not force the new CNAME onto the same hostname. Pick another dedicated return-path label in your sending provider, if its configuration supports choosing one. For DKIM, use the exact selector supplied by the provider; if it conflicts, contact the provider rather than inventing a selector.

A durable setup for transactional and campaign sending

The best DNS configuration is not just one that gets a green verification check today. It should continue working when you add a second application, rotate a DKIM key, change email vendors, tighten DMARC, or investigate a deliverability issue months later.

Maintain a simple sender inventory with these fields:

This record makes DMARC rollout much safer. It exposes obsolete senders, shows where SPF lookup pressure may accumulate, and helps a new teammate understand why a seemingly unrelated CNAME must not be removed.

Separating traffic by subdomain can also be useful. For example, send password resets and receipts from notify.example.com, newsletters from news.example.com, and support messages from support.example.com. The right structure depends on your brand and operational needs, but dedicated subdomains can make sender ownership, reputation monitoring, and DNS troubleshooting clearer.

FAQ

What is the exact DreamHost path for adding SPF, DKIM, and DMARC records?

As of writing, go to Manage Websites, find the domain, open its vertical three-dots menu, and select DNS Settings. Depending on the panel view, you may instead open the domain's Manage page, select the DNS tab, and choose Add Record. (help.dreamhost.com)

Should I enter my full domain in DreamHost's Host field?

Usually no. For a record requested at selector._domainkey.example.com, enter selector._domainkey. For _dmarc.example.com, enter _dmarc. Leave the Host field blank for the root domain. DreamHost documents that the domain name does not need to be entered in the host/name field. (help.dreamhost.com)

Can I have more than one SPF record?

No. Publish only one v=spf1 TXT record per hostname. If several services send from the same SPF domain, merge their authorized mechanisms into one record.

Do I need a custom return-path if DKIM already passes?

DKIM alignment can be enough for DMARC to pass, but a custom return-path provides an aligned SPF path as well. That redundancy is useful if DKIM breaks during a configuration change, key rotation, or provider issue.

Can I set DMARC to reject immediately?

You can, but it is risky unless you have verified every legitimate sender using the From domain. Start with p=none, review authentication results and reports, then move gradually to quarantine and reject.