Cloudbeds SPF, DKIM and DMARC setup, step by step

For Cloudbeds Guest Marketing and the documented Revenue Intelligence Smart Campaigns workflow, select one property and open Marketing → Settings → Domains. Add your root domain, save it, and select Verify to obtain the account’s Email code and DKIM TXT records plus its DMARC instructions. Publish the generated values at your authoritative DNS host, preserve any existing DMARC policy, then return to Cloudbeds and verify the domain. This marketing workflow does not issue a universal root SPF include. Cloudbeds Guest Marketing instructions

These are documented configuration and validation steps, not a claim that your property, DNS, or delivered messages have been tested.

On this page

• Choose the right Cloudbeds email product
• What the marketing authentication records do
• Generate the records for one property
• Publish the Email code and DKIM safely
• Review DMARC before copying the suggested record
• Complete verification and select the sender
• Check DNS and a real marketing message
• Troubleshoot Cloudbeds marketing authentication
• Frequently asked questions

Choose the right Cloudbeds email product

Cloudbeds has more than one email-sending route. This guide covers the Marketing → Settings → Domains procedure documented for Guest Marketing and Revenue Intelligence. Both official pages describe the same single-property domain-verification flow and its relationship to Smart Campaigns. Revenue Intelligence domain setup

It does not configure reservation confirmations, check-in messages, manually composed PMS messages, or PMS email templates. Cloudbeds documents those separately as a SendGrid-backed route with a different SPF recommendation and support-assisted DKIM. Do not add include:sendgrid.net merely because you are authenticating Guest Marketing. Conversely, do not delete that authorization if your property already uses the PMS route legitimately. PMS SPF scope and PMS email FAQ.

Guest Experience, formerly Whistle, is another distinct product. A successful Guest Marketing check does not authenticate every email channel carrying the Cloudbeds name.

Use this procedure when your account exposes the Marketing domain controls for the intended property. Cloudbeds’ domain guides do not specify a universal named subscription tier or permission role for those controls. If they are missing, ask your property administrator or Cloudbeds to confirm access. Do not assume that PMS ownership or access to unrelated General System Settings grants Marketing permissions.

What the marketing authentication records do

The current Cloudbeds modal has three TXT categories:

• Email code: a domain-identification token, shown at the root @ in the documented interface. It is separate from SPF.
• DKIM record: the public verification key for the marketing sender, at the exact selector owner issued by Cloudbeds. The illustrated owner is mail._domainkey, but your current modal determines the name and complete value.
• DMARC record: the policy governing the visible From domain. Review existing policy before adding or changing anything here.

The official screenshots show the Email code beginning brevo-code: with a colon. A prose example uses different punctuation. Avoid reconstructing the token from either example: copy its complete current Content field. Similarly, keep the full tagged DKIM TXT value, not just the characters after p=. Cloudbeds record-generation instructions and screenshots

Where SPF fits

SPF authenticates the SMTP envelope sender, not automatically the visible From address. A marketing message can pass SPF for a service-owned return-path domain without that identity aligning with your property’s From domain. In that case, a passing, aligned branded DKIM signature can supply the DMARC pass. The actual received message determines which identities were used. SPF identity and DMARC alignment.

Cloudbeds’ documented marketing modal supplies no SPF TXT or custom-return-path CNAME. Brevo’s own domain-authentication documentation also distinguishes ordinary authentication from SPF/MX setup for dedicated IPs. Its newer branded-subdomain flow is an upstream Brevo feature, not proof that Cloudbeds exposes it. Do not create a separate Brevo account, configure a dedicated IP, or copy Brevo branding records to complete this Cloudbeds task. Brevo domain-setup distinctions

Leave your existing root SPF policy intact. If a separately verified sending requirement later needs a change, preserve all legitimate senders and the chosen failure qualifier in one v=spf1 policy at the evaluated owner. Check SPF’s ten DNS-lookup-causing-term limit across nested processing, not simply the number of visible includes. An unrelated verification TXT record can coexist with SPF; a second SPF policy cannot. SPF publication and lookup limit.

Generate the records for one property

Before starting, obtain authorized access to the property’s Marketing settings and authoritative DNS. Use a domain the business owns and controls. Record its existing TXT records, DKIM selectors, DMARC policy, and relevant delegations so another mailstream is not disrupted.

1. Open Marketing in Cloudbeds.
2. Select a single property in the Property Picker. Domain settings cannot be configured in All Hotels view.
3. From Overview, use Domain Settings → Review, or go to Settings → Domains.
4. Select Add Row, enter the root domain in Name, then select Save Changes.
5. Select Verify beside that domain. This opens the modal containing the DNS names and values.
6. Keep the modal open while preparing the DNS changes. Record which property and domain produced the values.

Do not substitute a website URL or another hotel’s domain. The root-domain entry and single-property requirement are explicit in Cloudbeds’ current procedure. Do not extrapolate it into a universal bulk setup for a hotel group.

Publish the Email code and DKIM safely

Confirm where the records belong

Edit the active authoritative DNS service, which may differ from your domain registrar or website host. Check for child-zone or _domainkey delegation before editing the parent zone. Preserve the delegation and coordinate with its operator; adding a record in a non-authoritative parent will not override it.

For an illustrative domain example.com, these are owner-mapping examples only:

• A root Email code owner is example.com. A relative editor may use @ or a blank name; follow that DNS host’s convention.
• If your current Cloudbeds modal actually issues mail._domainkey, its full owner is mail._domainkey.example.com. Enter mail._domainkey in an editor that appends example.com.
• In a separately delegated _domainkey.example.com zone, that same DKIM owner would be relative name mail.

An editor expecting full names needs the complete owner. Check the saved public name to catch a doubled suffix such as example.com.example.com.

Add the issued TXT values

Publish the Email code as its own TXT record at the issued owner. Do not append it inside the existing v=spf1 value. If your DNS host groups TXT records into a record set, add a distinct value while keeping the existing values intact.

Publish the DKIM TXT at its exact issued owner, preserving the entire content and punctuation. Never publish a private signing key. If the host splits a long TXT value into multiple quoted character strings within one record, their concatenation must reproduce the issued value. That is different from creating several independent DKIM records at the same selector. DKIM key format and DNS representation

If mail._domainkey or another issued selector is already used, stop and identify the service using it. Do not replace its key or add a competing key to force verification. Ask Cloudbeds and the DNS administrator for a supported way to avoid the collision or coordinate a migration. Leave other active selectors untouched.

The published procedure uses TXT records, which are not HTTP-proxied in Cloudflare. Do not change website proxy settings for them. If your actual Cloudbeds account instead issues CNAMEs, confirm the changed workflow with Cloudbeds and use those exact types and targets. Upstream Brevo’s one-TXT/two-CNAME variants are not permission to substitute records yourself.

For such a confirmed CNAME variant only, use DNS-only records, avoid conflicting TXT/A/MX data at the same owner, and check per-record and zone-wide flattening. All-CNAME flattening can hide an alias even when DNS-only is selected and cannot be overridden per record. Apex and same-zone alias behavior also differ. Have the DNS administrator assess shared-zone effects rather than disabling flattening or protection globally. Cloudflare proxy behavior, flattening rules, and DNS alias constraints.

Keep the default TTL unless your DNS change plan specifies otherwise. No step here requires changing MX, parent nameservers, DNSSEC, or your property mailbox provider.

Review DMARC before copying the suggested record

The Cloudbeds screenshot includes a suggested p=none policy and a Brevo reporting destination. Neither is automatically the correct policy for your property. Publishing rua shares authentication-report information with the named recipient; do not copy a third-party address without the domain owner’s approval.

First check _dmarc for the intended visible From domain and whether a parent policy applies through DMARC discovery. Preserve existing direct or inherited enforcement, alignment modes, and approved reporting destinations. Do not create a second DMARC policy or downgrade p=quarantine or p=reject to satisfy a modal. DMARC policy discovery

If there is no applicable direct or inherited policy, and the owner chooses an initial monitoring policy, the minimal first record for illustrative From domain example.com is:

Type: TXT
Full owner: _dmarc.example.com
Host in an example.com zone: _dmarc
Value: v=DMARC1; p=none

Substitute the actual domain. If a separately approved sending setup uses news.example.com, its full policy owner is _dmarc.news.example.com: relative _dmarc.news in the parent example.com zone, or _dmarc in a delegated news.example.com zone. This mapping is not a claim that Cloudbeds’ documented root-domain entry configures every subdomain, nor a reason to override inherited protection.

The minimal record contains no rua, so it does not request aggregate reports. Arrange an approved reporting mailbox or service and a review owner before adding reporting. A recipient outside the policy domain’s organizational domain must provide the required external-report authorization in DNS. Reports can expose sending IPs, domains, and traffic patterns; define access and retention. Aggregate-report authorization and privacy

The report-generating receiver compares the Organizational Domain of the report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, which is not necessarily the visible From domain. The different-Organizational-Domain case above requires its DNS authorization check; a destination within that same Organizational Domain is excepted, even if the hostname differs. This exception does not remove the owner’s separate data-sharing approval. RFC 9990 section 4.

If the Cloudbeds interface insists on replacing a valid policy or adding an unapproved reporting address, pause that change and ask Cloudbeds how to retain your policy. The documented DMARC Policy Requirement error says to authenticate the domain before creating its sender, not to weaken DMARC.

Complete verification and select the sender

Return to Marketing → Settings → Domains, reopen the modal if needed, and select the Verify button at its bottom. Cloudbeds documents that the domain becomes Verified once its check succeeds. Saving DNS alone does not trigger this final step. Verification and next steps

After the domain is verified, Cloudbeds says newly added sender addresses on that domain are auto-verified without a separate email confirmation code. Use the Senders tab to manage the intended property identity, and confirm that the campaign uses that address in its visible From field. A display name or Reply-To on your domain is not sufficient.

Complete Marketing → Settings → General as well. The property’s branding and marketing information support Smart Campaign generation. Cloudbeds requires both domain verification and General marketing settings to unlock Smart Campaigns. This is not the unrelated PMS General System Settings page.

Cloudbeds allows 24–48 hours for DNS propagation in its troubleshooting advice. Verify the authoritative answers before waiting; a wrong name or truncated key will not become correct with time.

Check DNS and a real marketing message

Public DNS checks

These are read-only command templates. Replace every uppercase placeholder with your actual full owner or authoritative nameserver.

dig NS YOUR_ZONE +short
dig @AUTHORITATIVE_NS EMAIL_CODE_FULL_OWNER TXT +noall +answer
dig @AUTHORITATIVE_NS DKIM_FULL_OWNER TXT +noall +answer
dig @AUTHORITATIVE_NS DMARC_FULL_OWNER TXT +noall +answer
dig @1.1.1.1 EMAIL_CODE_FULL_OWNER TXT +noall +answer
dig @1.1.1.1 DKIM_FULL_OWNER TXT +noall +answer
dig @1.1.1.1 DMARC_FULL_OWNER TXT +noall +answer

Confirm the Email code and complete DKIM value match the current property’s modal. Confirm a single applicable DMARC policy, including any inherited policy, rather than simply counting unrelated TXT records. When an answer is empty, rerun without +noall +answer and inspect the response status. A timeout or SERVFAIL is a DNS problem, not proof that no record exists.

Require the intended branded signature

Arrange a controlled marketing message to an independent mailbox you control, using the actual campaign route and selected sender. A reservation confirmation sent by the PMS or a preview that uses a different delivery route does not validate Guest Marketing.

Inspect the original received message. Record the visible From domain, smtp.mailfrom envelope domain, the intended DKIM signature’s d= and s=, and the trusted receiver’s SPF/DKIM/DMARC results. Keep multiple signatures separate. EmailAuth’s DKIM selector guide explains how to construct the lookup from each signature rather than assuming mail or substituting the visible From domain.

Trust only results known to have been generated by the receiving infrastructure. An attacker can insert an Authentication-Results field, including a familiar-looking authserv-id; field position or matching text alone is not enough. If your receiver cannot distinguish or strip injected results, use an independent trusted mailbox or an administrator-verified trace. Authentication-Results security considerations

Treat the setup as validated for that route only when:

• The visible From remains the intended property-domain address, not a rewritten provider-domain identity.
• The intended branded DKIM signature is present, the trusted receiver reports dkim=pass, and its signing domain aligns with From under the applicable adkim mode.
• The trusted receiver also reports dmarc=pass for that From domain. A DMARC pass supplied by SPF alone does not prove the new DKIM configuration works.
• SPF has been evaluated separately for the actual envelope identity. A provider-domain SPF pass may be unaligned; that differs from fail, softfail, temperror, or permerror, which still require investigation even when DKIM supplies DMARC pass.

Relaxed alignment allows an organizational-domain match; strict alignment requires exact domains. Apply adkim to the DKIM signing domain and aspf to the envelope domain. Do not assume a provider return-path aligns with your property, or change strict alignment to relaxed solely to clear an error. DMARC alignment definitions

Troubleshoot Cloudbeds marketing authentication

• No Domains controls or All Hotels selected: select one property and confirm access to the actual Marketing product. Do not follow the PMS template menu as a substitute.
• Domain cannot be authenticated: compare the current Email code and DKIM value character for character, including token punctuation. Check authoritative DNS, appended suffixes, selector collisions, and delegations, then select Verify again.
• DMARC Policy Requirement when adding a sender: finish domain authentication first, then add the sender. Do not remove or lower the policy.
• Domain Verified but Smart Campaigns locked: finish General marketing/property settings. DNS changes cannot supply missing branding fields.
• Verified but DKIM missing, failing, or unaligned: confirm the campaign’s sender and route, inspect the actual signature selector, and compare its public key. A PMS message or unrelated provider signature is not the marketing signature you configured.
• SPF passes only for the provider: check whether branded DKIM passes and aligns. Do not copy the separate PMS SendGrid include or assume an upstream Brevo branded-subdomain feature is available through Cloudbeds.
• SPF error despite DMARC pass: investigate the exact envelope domain, DNS errors, authorization, and lookup budget. Do not label the entire authentication setup healthy merely because DKIM rescued DMARC.
• All authentication passes but delivery is poor: investigate consent, list quality, complaints, recipient filtering, and reputation. Authentication does not guarantee inbox placement.

Escalate persistent issues with the selected property, domain, record owners, verification error, timestamps, and sanitized authentication evidence. Remove guest details, message content, recipient addresses, and unnecessary identifiers before sharing diagnostics. Retest after a DNS move, key change, new From domain, or product-route change; keep active records until their dependencies are resolved.