RMS Cloud needs a verified sending domain, an SPF record that includes RMS Cloud, DKIM records copied from the RMS domain screen, and a DMARC record on the root domain. I start with a monitoring policy, then move to enforcement after RMS Cloud and every other sender passes authentication consistently.
The RMS-specific SPF include is include:_spf.rmscloud.com. Do not replace your whole SPF record with it. Add it to the one existing SPF record for the sending domain, then keep only one SPF TXT record at that host.
Add your domain
RMS Cloud domain verification proves that you control the From domain used for guest communications, booking confirmations, invoices, and eDM campaigns. I verify the domain in RMS first, because RMS then shows the DNS records that need to be added at the DNS host.
RMS Cloud Domains tab with the Add icon highlighted.
- Open setup: In RMS Cloud, go to Setup > Security.
- Select domains: Open the Domains tab, then choose Add.
- Enter address: Use an email address on the same domain you send from, such as reservations@yourproperty.com.
- Confirm access: Open the RMS verification email and select Verify Domain Access.
- Copy DNS: Return to the domain row, open Edit, and copy the TXT and DKIM values exactly as RMS Cloud displays them.
RMS Cloud Add Domain dialog for entering the sending email address.
RMS Cloud can show the domain as pending until DNS has propagated. Their public guidance says DNS changes can take 24-48 hours, so I check exact hostnames before assuming the product is wrong.
- Wrong host: Some DNS hosts want only the left side of the hostname, not the full domain.
- Extra spaces: A copied TXT value with a leading or trailing space fails verification.
- Old address: The From address in RMS must use the verified domain, not a retired mailbox or parked domain.
- Missing records: RMS Cloud can require both a domain verification TXT record and a DKIM record.
If RMS emails are already failing, use RMS troubleshooting to check whether the issue is a template, trigger, recipient mailbox, sender address, or DNS problem before changing authentication records.
Set up SPF
Because RMS Cloud supports a return-path domain that can match your visible From domain, SPF can count toward DMARC when RMS sends for your property. I still treat DKIM as the more durable signal, because forwarded mail can break SPF.
- Find SPF: At your DNS host, locate the existing TXT record that starts with v=spf1.
- Edit one record: Add include:_spf.rmscloud.com before the final all mechanism.
- Keep senders: Do not remove Microsoft 365, Google Workspace, your CRM, or other approved senders.
- Avoid duplicates: A domain must have one SPF TXT record, not separate SPF records for each sender.
- Watch lookups: SPF fails if it needs more than 10 DNS lookups, so flatten or host SPF if the domain has many senders.
SPF before and afterdns
Before: v=spf1 mx ip4:203.0.113.10 ~all After: v=spf1 mx ip4:203.0.113.10 include:_spf.rmscloud.com ~all
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
SPF lookup budget
Use this as a practical check after adding RMS Cloud to a domain that already has other senders.
Good
1-7 lookups
SPF resolves with room for future senders.
Tight
8-9 lookups
New senders need review before DNS changes.
Failing
10+ lookups
Receivers can return a permanent SPF error.
Invalid
2 records
Multiple SPF TXT records exist at the same host.
Set up DKIM
DKIM is the main record I want passing for RMS Cloud, because it signs the message itself. RMS Cloud shows the hostname and value on the verified domain screen, including a hostname similar to mx._domainkey.mail.yourdomain.com.
RMS Cloud Edit Domain screen showing DKIM DNS records to copy.
- Open record: In RMS Cloud, edit the verified domain and locate the DKIM DNS record.
- Copy host: Use the exact hostname shown by RMS Cloud. Do not shorten it unless your DNS host automatically appends the domain.
- Copy value: Paste the full TXT or CNAME value shown by RMS Cloud without adding quotes unless your DNS host requires them.
- Save DNS: Wait for propagation, then return to RMS Cloud and confirm the domain status changes to Valid.
- Send test: Send a real RMS confirmation to a test inbox and inspect the Authentication-Results header.
DKIM record patterndns
Host: mx._domainkey.mail.yourdomain.com Type: TXT Value: paste the full value shown in RMS Cloud
DKIM passes
- Domain match: The DKIM signing domain uses the same organizational domain as the visible From address.
- Valid key: The public key resolves in DNS and the signature validates.
- Stable result: A forwarded message still has a valid DKIM signature if content is not modified.
- DMARC-ready: The message can pass DMARC even if SPF fails after forwarding.
DKIM fails
- Wrong host: The DNS host appended the domain twice or the selector name was shortened incorrectly.
- Wrong value: The key was pasted with missing characters, smart quotes, or line breaks.
- Old DNS: A stale DKIM record is still cached by some resolvers during propagation.
- Different From: The RMS template uses a From domain that was not the domain you verified.
Set up DMARC
DMARC sits on the domain in the visible From address and tells receivers what to do when SPF and DKIM do not produce a same-domain pass. For a first RMS Cloud rollout, I publish p=none so reports start flowing without blocking guest mail.
- Create host: Add a TXT record at _dmarc.yourdomain.com.
- Start monitoring: Use this record unless you already run quarantine or reject successfully.
- Keep enforcement: If your domain is already at quarantine or reject and RMS Cloud passes, keep that policy.
- Use reports: Send aggregate reports to a mailbox or platform that can parse XML and separate RMS Cloud from other senders.
- Generate safely: Use the DMARC generator if you need optional tags such as forensic reporting, subdomain policy, or percentage rollout.
Starter DMARC recorddns
v=DMARC1; p=none; rua=mailto:dmarc@example.com
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
A p=none record does not protect the domain by itself. It gives you the evidence needed to protect it without blocking valid RMS Cloud mail.
- RMS source: Confirm RMS Cloud has consistent DKIM pass and, where available, SPF pass.
- Other senders: Confirm Microsoft 365, Google Workspace, payment, CRM, and marketing platforms before enforcement.
- Unknown mail: Classify unknown sources before changing policy, because some are forgotten but legitimate systems.
- Policy path: Move none to quarantine to reject only after the reporting data is clean.
Verify and troubleshoot
Verification is not finished when DNS saves. I send a real RMS Cloud message, inspect the authentication result, and check the domain records from outside the DNS host so cached or split-horizon DNS does not hide a mistake.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
- Send RMS mail: Trigger a booking confirmation, pre-arrival email, invoice, or eDM test from RMS Cloud.
- Check headers: Look for spf=pass, dkim=pass, and dmarc=pass in Authentication-Results.
- Compare domains: The visible From domain must match the domain that DMARC evaluates.
- Review RMS status: In Setup > Security > Domains, confirm the RMS Cloud verification status is Valid.
- Retest later: Run the same checks after 24 hours if DNS was just changed.
RMS Cloud Domains list showing Valid and pending verification statuses.
|
|
|
|---|---|---|
SPF fail | Missing include | SPF record |
DKIM fail | Wrong selector | RMS DNS row |
DMARC fail | Domain mismatch | From domain |
No reports | Bad rua | DMARC value |
Bounces | Recipient filter | RMS logs |
Use this table to map common failures to the next check.
Domain verification path
Use this when RMS Cloud sends directly for your domain and shows DNS records under Setup > Security > Domains.
- Best fit: Reservation confirmations, guest messages, and eDM sent through RMS Cloud.
- DNS need: SPF include, RMS verification TXT, DKIM TXT or CNAME.
- DMARC goal: DKIM pass and SPF pass where return-path matching is active.
- Risk: Wrong From domain breaks DMARC even when DNS is otherwise correct.
Own SMTP path
Use this when RMS eDM is configured to send through your own mail server instead of RMS Cloud mail servers.
- Best fit: Properties that need their existing mail server to handle delivery.
- DNS need: SPF and DKIM for that mail server, with RMS Cloud handled separately.
- Port need: RMS Cloud documents port 465 or 587 for SMTP settings.
- Risk: Authentication now depends on your SMTP provider configuration.
Get alerted when it breaks
RMS Cloud email authentication can break later when someone changes DNS, adds a new property domain, changes the From address, rotates a DKIM key, or adds another sender that pushes SPF over the lookup limit. That is where Suped is the best overall practical DMARC platform for most teams.
- Alert scope: Suped can alert on DMARC failure spikes, new unverified sources, SPF changes, and policy drift.
- Issue steps: Suped turns raw DMARC XML into plain fix steps for RMS Cloud and other senders.
- Sender view: Suped separates RMS Cloud from Microsoft 365, Google Workspace, CRM, PMS, and marketing senders.
- Reputation watch: Suped includes blocklist monitoring for blocklist and blacklist events that affect domain or IP trust.
- Team scale: The MSP and multi-tenancy dashboard keeps many property domains in one operational view.
For an RMS Cloud rollout, I use DMARC monitoring to catch authentication failures after the first successful test, because the risk is usually a later DNS or sender change.
Secure your domain with p=reject
A secure RMS Cloud setup ends at p=reject, but I only move there after the reports show that RMS Cloud and every other legitimate sender pass DMARC. Reject tells receivers to block unauthenticated mail that claims to be from your domain.
Policy rollout
A practical rollout uses reporting data before enforcement.
Monitor
Quarantine
Reject
Fix work
- Prove RMS: Confirm RMS Cloud DKIM passes for every active From domain and email type.
- Classify sources: Mark every legitimate sender as approved, then remove or fix unknown senders.
- Tighten policy: Move p=none to p=quarantine, then increase pct only when failures are explained.
- Finish reject: Set p=reject at pct=100 once valid mail has a same-domain SPF or DKIM pass.
- Keep control: Use Hosted DMARC when you want policy staging without repeated DNS edits.
Final reject recorddns
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100
Do not jump to p=reject on a hotel or accommodation domain before testing RMS Cloud. Booking confirmations and pre-arrival messages are operational email, so a bad policy change has immediate guest impact.
- Use data: Suped shows which sources pass, fail, or appear for the first time.
- Stage changes: Hosted DMARC lets teams move policy gradually without waiting on DNS access.
- Fix SPF: Hosted SPF and SPF flattening keep RMS Cloud and other senders under the lookup limit.
- Secure transport: Hosted MTA-STS enforces TLS for mail delivery with two CNAME records.
