For Sirvoy's native guest emails, request the account-specific DKIM records from Sirvoy Support, publish the exact supplied DNS packet, then contact Support again to enable the key. Publishing records alone does not complete this workflow. Sirvoy also checks the custom sender's DMARC configuration and can automatically change the visible sender after verification. Coordinate that change before treating the branded route as ready. Official custom-domain instructions
This guide covers an existing Sirvoy account and an approved custom contact-address domain used for native emails to guests. It does not configure a website domain, an external SMTP service, SMS, or a booking channel's own email. The current public instructions do not establish a universal Sirvoy SPF include, a plan-specific entitlement, a dedicated test-send button or a propagation guarantee.
On this page: Confirm which service sends the message · Prepare the DNS and sender change · Request the actual Sirvoy DKIM packet · Publish the issued records at the correct authority · Handle SPF without inventing a Sirvoy include · Preserve DMARC protection and approved reporting · Have Support enable the key · Validate a real native message without triggering guest workflows · Troubleshooting · Frequently asked questions
Confirm which service sends the message
In Sirvoy, the relevant address is under Settings → Sirvoy account → Contact details. With a public mailbox address such as Gmail or Yahoo, or when the necessary domain checks are missing, Sirvoy may use noreply@sirvoy.com. Delivery from that fallback address is not successful authentication of your business's From domain.
Sirvoy's template documentation distinguishes its own messages from channel messages. Booking.com and Expedia send their own booking confirmations and cancellations; other automated Sirvoy templates can follow a different route. Do not use a channel-generated message to certify Sirvoy's native signing. Message-template routes
Record the intended visible From address, the domain owner, authoritative DNS host and the exact native message type being assessed. Confirm that the person requesting the sender change is authorized to use that domain. A domain being listed in an account does not itself grant permission to send as it.
Prepare the DNS and sender change
Before publication, preserve the current DNS owners, record types, values and TTLs. Include existing SPF policies, DKIM selectors, direct and inherited DMARC protection, MX records, website records and any relevant delegation. Keep a bounded restoration plan; restoring an entire old zone could erase unrelated work.
Agree on the intended From address and timing with the owner. Sirvoy's Contact details page automatically detects DMARC, and a verified custom domain can become the visible sender. This is not necessarily a harmless background check. Coordinate DNS publication, Support enablement and the sender transition rather than weakening an existing policy just to produce a verified result.
Do not change nameservers, migrate incoming mail or replace working MX records to make an authentication example fit. If an issued packet affects an envelope or other routing name, compare the exact owner and destination with the approved routing plan first. Obtain approval for that change separately from copying a public verification record.
Request the actual Sirvoy DKIM packet
Sirvoy's documented support destination is support@sirvoy.com. An authorized administrator should request the DKIM setup using the Sirvoy Account ID and domain name. This guide does not send that request or expose any customer account information. Support issuance and enablement
Ask Support to identify the complete record type, fully qualified owner and target for every required row, the intended signing domain and any envelope-domain role. Confirm the exact sender domain supported by that account, especially if a subdomain rather than the contact address's parent domain is proposed.
The official example contains three CNAMEs: an account-assigned subdomain pointing to a SendGrid target and two _domainkey aliases. Its uXXXXXXX and similar values are placeholders, not deployable configuration. Even familiar selector names in an example are not a reason to substitute them for the account's packet.
| Record information | Safe handling |
|---|---|
| Type | Preserve the issued type; a CNAME target is not a TXT value |
| Full owner | Establish the actual authoritative zone and editor's relative-name convention |
| Target | Copy the complete account-specific target without guessing a region or tenant |
| Purpose | Confirm DKIM versus envelope/routing purpose; do not call every row a signing key |
| Activation | Record that Support must enable the DKIM key after publication |
Do not request, upload or publish a private signing key. The required customer DNS data consists of the supplied public records, not secret signing material.
Publish the issued records at the correct authority
Use the DNS service currently authoritative for each issued owner. Registration at a provider does not prove that its DNS editor serves the zone. Inspect delegations before entering records, including any delegated child domain or _domainkey zone.
For illustration only, SELECTOR._domainkey.news.example.com is entered as SELECTOR._domainkey.news in an editor serving example.com that appends the zone name. In a separately delegated news.example.com zone, it is SELECTOR._domainkey. If _domainkey.news.example.com is itself delegated, the relative owner is SELECTOR. These are placement examples, not Sirvoy's issued selectors or a claim that any subdomain is automatically eligible.
A CNAME owner cannot coexist with conflicting data at that same name. If another sender already uses the owner, stop and request a supported alternative rather than deleting its working record. Keep all other active selectors intact.
Authentication CNAMEs must remain discoverable as literal aliases to the supplied targets. Do not HTTP-proxy them or flatten away the alias. Where the DNS host has per-record flattening, disable it only for the relevant record when supported. Cloudflare's whole-zone flatten-all setting cannot be overridden per record; apex and same-zone behavior also have special limits. If the required alias cannot be preserved without changing shared behavior, coordinate a supported layout rather than making a blind zone-wide change. Cloudflare flattening controls
After saving, query the authoritative server and a recursive resolver. Compare the complete returned owner and target with Support's packet. A saved DNS-editor row is not proof of public publication; a doubled suffix or wrong authority will not be fixed simply by waiting.
Handle SPF without inventing a Sirvoy include
The current Sirvoy custom-domain instructions do not specify a standalone universal SPF TXT include to paste at your domain root. Do not infer one merely because the example CNAME targets use SendGrid infrastructure. Use the actual Support-issued packet and investigate SPF on the domain evaluated for the real native message.
SPF checks the SMTP MAIL FROM identity, not automatically the visible From address. Inspect the trusted receiver's smtp.mailfrom and the actual envelope path. A CNAME associated with an envelope domain has a different purpose from an apex SPF TXT policy or a DKIM selector.
If Support supplies a required SPF TXT change, review it at its actual owner. Maintain one SPF policy there, preserve legitimate existing authorizations and the approved terminal behavior, and evaluate the nested lookup path against SPF's ten lookup-causing-term limit. Do not paste a second v=spf1 record, concatenate whole policies or use +all to suppress failures. Any all mechanism causes redirect to be ignored, so a redirect-based policy requires a deliberate merge rather than an appended canned example. SPF evaluation and redirects
Preserve DMARC protection and approved reporting
Inspect the policy at the intended visible From domain and any applicable inherited policy before making changes. A missing child-domain TXT record does not mean that the child has no protection. Preserve existing quarantine or reject, alignment modes and approved report destinations unless the owner approves a specific change. Current DMARC requirements
Sirvoy's example is not a safe universal policy template. Do not copy its example external reporting address or obsolete pct tag. Aggregate reports describe authentication activity; rua is not where quarantined message bodies are forwarded. A first monitoring-only policy is a separate owner-approved rollout only when no applicable policy already exists, not a way to bypass existing enforcement.
For report authorization, compare the Organizational Domain of the reporting URI destination host with the Organizational Domain of the domain where the policy was found, including an inherited policy. Different Organizational Domains require external authorization; the same-Organizational-Domain exception is based on that policy-found domain too. Protocol authorization does not replace the owner's approval to share report data. Aggregate reporting
For this branded-DKIM setup, do not adopt the weaker idea that signing matters only when DMARC enforcement is enabled. Require the intended Sirvoy signature to pass and align even when the policy is p=none.
Have Support enable the key
After publication, contact Sirvoy Support again to enable the DKIM key. This is an explicit second step in the official workflow. Supply the intended account/domain and the public DNS results through the approved support exchange; there is no need to attach guest lists, bookings or message contents.
Recheck the Contact details address and domain verification after Support completes its action. The public instructions do not establish a separately named signing switch, a particular success badge or a fixed delay. If DNS resolves but native messages remain unsigned, ask Support to confirm activation for the exact account and domain. Do not keep regenerating DNS values without establishing why the current packet failed.
Validate a real native message without triggering guest workflows
Prefer an authorized, already-received native Sirvoy message after activation, or a separately approved isolated test arrangement using synthetic data and a controlled recipient. The documented template workflow does not establish a standalone harmless test-send control.
Do not create, cancel, check in or check out a booking solely to test DNS; do not alter actual guests, email invoices, enable global automated email or toggle SMS. Sirvoy's public booking-engine confirmations can be mandatory when an email address is supplied, so creating a booking is not a neutral inspection step. If no approved safe message is available, record message-level acceptance pending. Default sending behavior
Use receiver-controlled diagnostics, or have the receiving administrator identify which authentication fields originated inside the trusted receiving boundary and how externally supplied Authentication-Results are removed or distinguished. Header position or a familiar authserv-id alone is not proof. Retain sanitized identities and results, not guest names, booking references or payment information. Authentication-results trust
| Acceptance check | Required evidence |
|---|---|
| Actual route and From | Native Sirvoy message with the approved custom From, not a channel email or unnoticed noreply@sirvoy.com fallback |
| Intended signature | Receiver reports DKIM pass for the expected Sirvoy signing domain and active selector |
| DKIM alignment | That same passing signature aligns with the approved From under effective adkim |
| DMARC | Trusted receiver reports DMARC pass for that From |
| SPF | Actual MAIL FROM and SPF result assessed independently, with errors resolved rather than hidden by DKIM |
Relaxed DKIM alignment means the signing d= domain and From share an Organizational Domain; strict alignment requires an exact match. SPF alignment compares MAIL FROM with From under the separate aspf mode. A child envelope domain does not automatically meet strict alignment with its parent From.
A DMARC pass supplied only by SPF does not validate this DKIM deployment. Similarly, an unrelated provider-domain DKIM pass is insufficient. See raw DKIM results versus aligned policy results.
Troubleshooting
Sirvoy still sends from noreply@sirvoy.com
Confirm the intended contact address, its custom-domain eligibility, applicable DMARC and Support's DKIM enablement. Compare fresh native-message evidence rather than assuming an older cached message reflects the new state. Do not weaken policy or change sender addresses without approval.
DNS is correct but there is no intended signature
Check that Support completed the post-publication activation for the correct account. Confirm the message is native Sirvoy, not Booking.com or Expedia. A public key can exist without the sender using it.
DKIM passes but DMARC fails
Inspect the actual passing d= and visible From under the effective alignment mode. An unrelated signature does not authenticate the business domain. Preserve strict settings if the owner requires them; request a supported aligned configuration rather than silently relaxing them.
SPF fails while DKIM supplies DMARC pass
Investigate SPF separately. fail or softfail calls for checking authorization for the actual sending route; temperror indicates a transient evaluation problem such as DNS availability; permerror calls for checking duplicate policies, invalid syntax and lookup limits. A passing but unaligned provider envelope is a different outcome from an SPF error.
Automation sent an unexpected email
Authentication and message scheduling are separate controls. Review the approved configuration with the account owner; do not delete bookings or suppress legitimate communications to hide the event. Sirvoy templates can contain sensitive guest and payment placeholders. Keep troubleshooting samples sanitized.