How to set up DMARC/DKIM/SPF for RMS Cloud
Updated on 25 Oct 2026: We clarified RMS Cloud DNS publishing, DKIM record types, and DMARC enforcement checks.
When RMS Cloud's mail servers send for your domain, use a verified sending domain, an SPF record that includes RMS Cloud, DKIM records copied from the RMS domain screen, and a DMARC record that applies to the visible From domain. A new DMARC deployment starts with monitoring, then moves to enforcement after RMS Cloud and every other legitimate sender passes DMARC 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.
Choose the sending domain
Choose the domain in the RMS Cloud From address before adding DNS records. RMS Cloud recommends a sending subdomain so its records remain separate from services already configured on the main domain. For example, reservations@mail.yourproperty.com uses mail.yourproperty.com as the visible From domain.
- Use the chosen domain in the RMS From address and an accessible mailbox on that domain for the verification email. A Reply-To address does not determine the domain DMARC checks.
- Add SPF to the domain RMS instructs you to update, copy the RMS DKIM hostname exactly, and publish DMARC at _dmarc.mail.yourproperty.com when that subdomain has its own policy.
- If the sending subdomain has no DMARC record, the organizational-domain policy and its sp tag can apply. Review that policy before the first RMS test.
- Verify each domain used by a property, template, or campaign instead of assuming one valid domain covers every From address.
Verify your sending domain in RMS Cloud
RMS Cloud domain verification confirms access to an email address on the sending domain used for guest communications, booking confirmations, invoices, and eDM campaigns. Use an RMS Cloud System Administrator account to add the domain, then copy its required DNS records. A valid domain also removes the 'Sent from RMS on behalf of' text from the sender field.
RMS Cloud Setup > Security > Domains screen with Add highlighted for email domain verification.
- In RMS Cloud, go to Setup > Security.
- Open the Domains tab, then choose Add.
- Enter an accessible email address on the same domain you send from, such as reservations@yourproperty.com, then select Save.
- Open the RMS verification email and select Verify Domain Access. Check spam or junk if it does not arrive.
- Return to the domain row, open Edit, and copy every required record type, hostname, and value exactly as RMS Cloud displays them.
RMS Cloud Add Domain dialog with the sending email address and Save button.
RMS Cloud can show the domain as pending until DNS has propagated. Its public guidance says DNS changes can take 24-48 hours, so check exact hostnames before assuming the RMS status is wrong.
- Some DNS hosts want only the left side of the hostname, not the full domain.
- Remove accidental leading or trailing spaces without changing spaces that belong inside a TXT value.
- The From address in RMS must use the verified domain, not a retired mailbox or parked domain.
- Publish every record shown on the RMS domain screen, including DKIM and any verification records. Use TXT or CNAME exactly as specified.
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.
Publish records at the authoritative DNS host
Add records at the DNS provider responsible for your domain's authoritative nameservers. Check the nameservers configured at your registrar to identify that provider; it is not always your registrar or web host. If the sending subdomain has its own delegated DNS zone, edit that zone instead.
DNS forms often append the zone name automatically. The host labels below assume you are editing the yourdomain.com zone. Copy the actual names and record types shown by RMS Cloud; the DKIM hostname is an example.
|
|
|
|
|---|---|---|---|
SPF for the main domain | TXT | yourdomain.com | @ |
SPF for the sending subdomain | TXT | mail.yourdomain.com | mail |
DKIM TXT example | TXT | mx._domainkey.mail.yourdomain.com | mx._domainkey.mail |
DMARC for the main domain | TXT | _dmarc.yourdomain.com | _dmarc |
DMARC for the sending subdomain | TXT | _dmarc.mail.yourdomain.com | _dmarc.mail |
Example host labels within the yourdomain.com DNS zone.
Use the DNS provider's default TTL or 3600 seconds (one hour). Existing cached answers remain valid until their previous TTL expires; a lower TTL does not clear those caches. A non-authoritative DNS panel will not publish the records receivers query.
Set up SPF
SPF (Sender Policy Framework) authorizes RMS Cloud's sending infrastructure for the domain used in the SMTP Return-Path. It counts toward DMARC only when that authenticated domain has DMARC identifier alignment with the visible From domain. SPF records do not inherit between a main domain and its subdomains. DKIM remains the more durable signal because forwarding can break SPF.
- At the host RMS instructs you to update, locate the TXT record that starts with v=spf1. If none exists, create one after identifying every service that sends for that domain.
- Add include:_spf.rmscloud.com before the final all mechanism. Keep the existing ~all or -all choice while adding RMS Cloud.
- Do not remove Microsoft 365, Google Workspace, your CRM, or other approved senders.
- A domain must have one SPF TXT record, not separate SPF records for each sender.
- SPF returns permerror if evaluation exceeds 10 DNS lookup-causing terms, including nested includes. Review the record before adding more 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
The before-and-after records are examples; 203.0.113.10 is a documentation address. If RMS Cloud is the only sender and no SPF record exists at the required host, use v=spf1 include:_spf.rmscloud.com ~all. Add other approved senders before publishing if the domain has them.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
SPF lookup budget
Count evaluated DNS lookup-causing terms, including nested includes. The Good and Tight bands are planning labels; the protocol limit is 10 terms.
Good
0-7 terms
Room within the lookup budget when nested terms are included in the count.
Tight
8-10 terms
Near the lookup limit; validate the full record before adding another sender.
Failing
11+ terms
Evaluation exceeds the RFC 7208 lookup-term limit and returns permerror.
Invalid
2+ SPF records
Multiple SPF TXT records exist at the same host.
Set up DKIM
DKIM (DomainKeys Identified Mail) lets receivers verify a domain's signature and detect changes to signed message content. RMS Cloud shows the required hostname and value on the domain screen, with a published TXT example similar to mx._domainkey.mail.yourdomain.com. RMS troubleshooting specifies TXT or CNAME records, so use the record type and value shown for your account.
RMS Cloud Edit Domain screen with the DKIM hostname and DNS value to publish.
- In RMS Cloud, edit the domain and locate its DKIM DNS records. Publish each record RMS requires.
- Use the exact hostname shown by RMS Cloud. Do not shorten it unless your DNS host automatically appends the domain.
- For TXT, paste the full public-key value shown by RMS Cloud. For CNAME, paste the supplied target hostname instead. Do not generate a replacement key outside RMS Cloud.
- Wait for propagation, then return to RMS Cloud and confirm the domain status changes to Valid.
- Send a real RMS confirmation to a test inbox and inspect the Authentication-Results header.
Example DKIM TXT record patterndns
Host: mx._domainkey.mail.yourdomain.com Type: TXT Value: paste the full value shown in RMS Cloud
DKIM passes with DMARC identifier alignment
- Under relaxed identifier alignment (the default), the DKIM d= domain and visible From domain share an organizational domain. With adkim=s, they must match exactly.
- The public key resolves in DNS and the signature validates.
- A forwarded message still has a valid DKIM signature if content is not modified.
- The message can pass DMARC even if SPF fails after forwarding.
DKIM or DMARC fails
- The DNS host appended the domain twice or the selector name was shortened incorrectly.
- The TXT public key is incomplete, or a CNAME target was copied incorrectly. DNS providers can split a long TXT value into quoted chunks within one record; preserve the full key.
- A stale DKIM record is still cached by some resolvers during propagation.
- The RMS template uses a From domain that was not the domain you verified.
Set up DMARC
DMARC (Domain-based Message Authentication, Reporting, and Conformance) evaluates the domain in the visible From address and tells participating receivers how the domain owner wants failed mail handled. A message passes when SPF or DKIM passes with identifier alignment to that From domain. For a new DMARC deployment, publish p=none to request aggregate reports without requesting enforcement.
- For yourdomain.com, use _dmarc.yourdomain.com. For a sending subdomain with its own policy, use _dmarc.mail.yourdomain.com. Edit an existing DMARC record at that host rather than publishing a second one.
- Use the starter record unless the applicable domain already runs quarantine or reject successfully.
- If the domain is already at quarantine or reject and RMS Cloud passes DMARC, keep that policy.
- Send aggregate reports to a mailbox or platform that parses XML and separates RMS Cloud from other senders. If the report destination has a different organizational domain from the policy domain, its operator must authorize reporting in DNS.
- Use the DMARC generator if you need optional tags for failure reporting, subdomain policy, or RFC 9989 test mode.
Starter DMARC recorddns
v=DMARC1; p=none; rua=mailto:dmarc@example.com
Replace dmarc@example.com with your actual report destination before publishing. Use the reporting address supplied by Suped when sending reports to our platform. Reports are sent after receiver reporting intervals elapse, rather than immediately after a test message.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
RFC 9989 replaced RFC 7489 and made pct historic. The optional t=y test flag requests none for p=quarantine and quarantine for p=reject at receivers that support it; reporting continues. Older receivers ignore an unknown t tag and apply the published policy. Use t=y only when you are ready for the full published policy to be applied.
- Confirm RMS Cloud has consistent DKIM pass and check whether SPF has identifier alignment.
- Confirm Microsoft 365, Google Workspace, payment, CRM, and marketing platforms before enforcement.
- Classify unknown sources before changing policy because some are forgotten but legitimate systems.
- Move from none to quarantine, then reject, after the reporting data is clean.
Verify and troubleshoot
Verification is not finished when DNS saves. Send a real RMS Cloud message, inspect the authentication result, and check the domain records 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 shows a results button when the test is ready.
?/43tests passed
- Trigger a booking confirmation, pre-arrival email, invoice, or eDM test from RMS Cloud.
- Inspect the receiving server's Authentication-Results for spf=pass, dkim=pass, and dmarc=pass. DMARC requires at least one SPF or DKIM pass with identifier alignment, so an SPF failure after forwarding does not automatically mean DMARC fails.
- Compare the visible From domain with smtp.mailfrom in the SPF result and header.d in the passing DKIM result. Build the DKIM key hostname using the s= selector, then ._domainkey., then the d= domain. With adkim=s or aspf=s, the corresponding domain must match the From domain exactly.
- In Setup > Security > Domains, confirm the RMS Cloud verification status is Valid.
- Send to a business mailbox and an external mailbox. If external delivery works but business delivery fails, check the recipient organization's filtering and quarantine.
- Recheck after cached DNS answers expire; RMS Cloud allows 24-48 hours for status updates. Keep the recipient address, send time, and full bounce response if delivery still fails.
RMS Cloud email domain verification list with Valid and Email Verification Required statuses.
|
|
|
|---|---|---|
SPF fail | Unauthorized source or forwarding | Return-Path domain, sending IP, and its SPF record |
SPF permerror | Duplicate SPF records, invalid syntax, or too many lookup terms | One v=spf1 TXT record and its full include chain |
DKIM fail | Wrong selector or key, or changed signed content | DKIM s= and d= values, RMS DNS records, and the failure reason |
DMARC fail | No SPF or DKIM pass with identifier alignment | From domain, smtp.mailfrom, header.d, and strict matching settings |
No reports | Wrong rua, missing external authorization, or no reports generated yet | Report address, authorization DNS, receiver coverage, and reporting interval |
Bounces | Recipient address, authentication, or recipient policy issue | Full SMTP error and RMS sending logs before changing DNS |
Use this table to map common failures to the next check.
A DMARC pass does not guarantee inbox placement. If authentication passes but messages are missing, inspect recipient filtering and the full SMTP response before changing valid DNS records.
Domain verification path
Use this when RMS Cloud sends directly for your domain and shows DNS records under Setup > Security > Domains.
- Reservation confirmations, guest messages, and eDM sent through RMS Cloud.
- The SPF include and every DKIM or verification record shown in RMS Cloud, with each record published using its specified type.
- DKIM pass with identifier alignment, plus SPF with identifier alignment when RMS uses a matching Return-Path domain.
- Wrong From domain breaks DMARC even when DNS is otherwise correct.
Own SMTP path
Use this when RMS eDM sends through your own mail server instead of RMS Cloud mail servers. Configure it under Setup > Property Options > General Information > Email Settings. This alternative bypasses RMS domain verification for that sending path, but the receiving server still checks authentication.
- Properties that need their existing mail server to handle delivery.
- SPF and DKIM for your SMTP server. Add the RMS Cloud include only if RMS Cloud mail servers also send for that domain.
- RMS Cloud documents port 465 or 587; port 465 requires its SSL option. Use the TLS settings required by your SMTP provider.
- Authentication now depends on your SMTP provider configuration.
Monitor RMS Cloud authentication failures
RMS Cloud email authentication can break later when someone changes DNS, adds a property domain, changes the From address, rotates a DKIM key, or adds a sender that pushes SPF over the lookup limit. Suped, our DMARC reporting and email authentication platform, helps teams detect those changes after setup.
- Set a DMARC failure threshold in Suped so alerts identify the affected source and message volume when failures cross it.
- Suped turns raw DMARC aggregate reports into fix steps for RMS Cloud and other senders.
- Suped separates RMS Cloud traffic from other approved email sources.
- The MSP and multi-tenancy dashboard keeps property domains in one operational view.
For an RMS Cloud rollout, DMARC monitoring can reveal authentication failures after a later DNS or sender change. Reports depend on receiver coverage and reporting intervals; check RMS logs separately for messages that never leave RMS Cloud.
Move to p=reject after verification
For domains that are ready for enforcement, move to p=reject only after reports show that RMS Cloud and every other legitimate sender pass DMARC. Reject asks participating receivers to reject mail that fails DMARC, although receivers retain discretion over final handling.
- Confirm RMS Cloud DKIM passes with identifier alignment for every active From domain and email type.
- Identify every legitimate sender and fix its authentication. Investigate unknown sources; do not authorize a source solely because it appears in a DMARC report.
- After source checks, change p=none to p=quarantine and review reports and delivery. This requests enforcement, so make the change only when legitimate sending paths pass DMARC.
- Review a representative sending cycle, including automated guest messages and less frequent campaigns. Proceed when legitimate mail remains stable and failures are explained.
- Change to p=reject without t=y only after every legitimate source has an SPF or DKIM pass with identifier alignment. Use Hosted DMARC when you want Suped to manage policy changes without repeated DNS edits.
Final reject recorddns
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
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.
RMS Cloud authentication FAQ
The RMS Cloud SPF include is include:_spf.rmscloud.com. Add it to the existing SPF TXT record at the host RMS instructs you to update, and keep the entries for other legitimate senders.
Add the RMS Cloud SPF include because RMS requires it to authorize its sending infrastructure. For DMARC, SPF only contributes when the authenticated Return-Path domain has identifier alignment with the visible From domain. DKIM remains important because forwarding often breaks SPF.
Start with v=DMARC1; p=none; rua=mailto:dmarc@example.com unless the applicable domain already uses quarantine or reject successfully. If enforcement is already active and RMS Cloud passes DMARC, keep the stronger policy.
After you confirm mailbox access and publish the required DNS records, RMS Cloud says the domain status can take 24-48 hours to become Valid. If verification still fails, recheck the authoritative DNS zone, record types, hostnames, and copied values; also check for duplicate SPF records.
Yes. RMS Cloud eDM can be configured with your own SMTP server settings. In that case, SPF and DKIM must authenticate the mail server you use, not only RMS Cloud.
Move to p=reject after RMS Cloud and all other legitimate senders show stable DMARC pass results across a representative sending cycle. RFC 9989 made pct historic. The optional t=y flag requests reduced enforcement only at receivers that support it, so be ready for the published policy to be applied. Suped can parse reports and alert when failures cross your configured threshold.
