Syncro SPF, DKIM and DMARC setup, step by step

For Syncro's native Internal Email route, use Verified Email Domains to obtain the three CNAME records from your own account, publish them exactly, and select Verify DNS Records. Green record checks and a Verified domain confirm Syncro's DNS validation. They do not, by themselves, prove that a particular outbound message used your intended aligned DKIM signature. Syncro's verified-domain instructions

This guide covers an existing, active, approved custom-branded Syncro mailbox using Internal Email, with its intended address and outbound categories already configured. It does not create inbound forwarding, switch an SMTP connection, assign billing or support defaults, or activate a new mailbox. Those changes affect more than authentication and need their own approved implementation.

1. Confirm which system actually sends your mail

In the existing mailbox configuration, check the delivery method without changing it. Syncro documents Internal Email as the default when a separate SMTP connection is not selected. If the mailbox uses your own SMTP service, this native domain-verification procedure is not a substitute for that service's SPF and DKIM setup. The official verified-domain page explicitly says configuring Verified Email Domains changes nothing for SMTP. Mailbox delivery methods and scope

Confirm the mailbox is already Active, its approved email address uses the domain being authenticated, and the intended message category already uses that mailbox. Mailbox Active and domain Verified are different states. An active mailbox can still need domain authentication; a verified domain does not prove that every outbound category selects the intended mailbox.

Do not select a different category as a convenient test. Syncro's current mailbox instructions say Billing and Support can each be assigned to only one mailbox, while Marketing can use more than one. Selecting a category changes the default mailbox for messages triggered from that area. Preserve these assignments, organization communication overrides, templates, ticket rules and autoresponders.

If the mailbox is inactive or the required sender is not approved, stop this procedure. Do not follow the mailbox article's inbound-forwarding test as an outbound DKIM test: incoming messages can create leads or tickets and trigger responses.

2. Record the current DNS and account configuration

Before editing DNS, save the intended domain and From address, existing mailbox delivery method, domain-verification status, current SPF and DKIM records, applicable DMARC policy, and relevant DNS owners and TTLs. Identify who can approve and restore a bounded change.

Confirm which DNS service is authoritative for each issued owner. The registrar, website host and mailbox provider may be different services. Preserve MX, NS delegations, DNSSEC, website records, existing selectors and unrelated verification tokens. Do not migrate nameservers to make a screenshot easier to follow.

Because this is an existing sending route, coordinate the change with the service owner: verification may affect subsequent live native mail. Treat publication and verification as an approved authentication change, not a harmless preview. Do not regenerate or replace an already-working domain configuration merely because a message landed in spam.

3. Obtain the account's three CNAME records

For an approved domain that is not already configured:

1. Open Admin → Emails/SMS - Verified Domains.
2. Select +New Verified Email Domain.
3. Enter the exact domain you control and intend to authenticate.
4. Select Create Verified Email Domain.
5. Refresh the page after the record-creation message.
6. Capture every row's Record Type, Host and Value from your own account.

The current official screenshots show three CNAME rows: two owners in the _domainkey namespace and one other generated owner. They show different example domains and different account values on the unverified and verified screens. Do not combine those examples or reuse their selectors, account identifiers or targets. Native record issuance and verification

Use the complete issued set. The two _domainkey aliases point to provider-managed signing data; they are not places to paste a locally generated private key. Preserve the other issued alias too, but do not infer the precise MAIL FROM identity of every message from its appearance in the dashboard. Confirm the actual envelope during message verification.

If the current account presents a different record count, type or workflow, obtain current account-specific guidance before applying a three-row assumption. Do not convert issued CNAMEs into TXT records or create a parallel SendGrid account to obtain replacement values.

4. Publish at the correct authoritative owners

Create the records with the exact issued types and targets. A CNAME value is a target hostname, not a URL: do not add https://, a path, or the sending domain to the end of it. The DNS host may require a full owner or a relative owner; inspect the resulting full name before saving.

These are placement examples only, not Syncro-issued values:

For a non-DKIM owner such as ISSUED-LABEL.example.com, a relative-name editor serving example.com takes ISSUED-LABEL. Substitute the actual issued name, not these placeholders. Child-domain examples explain DNS placement; they do not authorize a different sending domain.

Check each owner for existing dependencies. A CNAME cannot coexist at the same owner with TXT, A, AAAA, MX or a competing CNAME. Do not overwrite another sender's selector, remove an NS delegation, or replace a website or inbound-mail record. Resolve a collision through Syncro and the DNS owner before continuing.

Keep authentication aliases visible as CNAMEs

Use ordinary DNS resolution, not an HTTP proxy, for these authentication records. When using Cloudflare, use DNS only rather than proxying. If a relevant per-record Flatten control is available, leave it off for an issued alias that must remain a literal CNAME answer. Also check applicable zone-wide settings: a per-record choice alone may not prevent flattening.

Cloudflare documents special behavior for apex aliases and same-zone CNAME targets. If mandatory apex or same-zone processing prevents the required literal CNAME answer, stop and coordinate a supported configuration rather than inventing a disable switch or changing shared global settings. Do not move the issued alias to a different owner to evade the limitation. Cloudflare's current flattening controls

Query the authoritative server and a recursive resolver for each full issued name. Compare the exact CNAME target with the account. A record saved in a non-authoritative editor, a doubled domain suffix or a flattened answer will not be corrected simply by waiting longer.

5. Verify in Syncro and keep activation states separate

Return to the domain's record page and select Verify DNS Records. Syncro processes the validation request. The documented successful state is a green checkmark for each row in Verified Record, with the domain shown as Verified. If checks have not appeared, allow for DNS caching and refresh the page after confirming the public records. Verification controls and success state

Do not invent a separate “Enable DKIM” switch: the reviewed native procedure ends with this verification. Conversely, do not interpret it as proof of delivered-message signing. Record the following separately:

Do not change forwarding, category defaults or SMTP credentials to obtain the fourth or fifth result. If a prerequisite is missing, record it as a separate implementation hold.

6. Understand SPF without adding a speculative apex policy

SPF evaluates the actual SMTP MAIL FROM domain, or HELO in relevant cases, not automatically the visible From. The native verified-domain workflow uses account-issued aliases; this guide does not require a guessed universal Syncro SPF include or an additional TXT record at an issued CNAME owner.

The official page also contains a separate single-IP SPF fallback, then warns that the underlying sending service can use other changing IPs. That is not a complete authorization inventory for this account's route. Do not copy that fallback blindly or authorize an IP simply because it appears in an arbitrary received header. Use the native issued records and investigate the actual evaluated identity with Syncro if SPF fails. Provider workflow and fallback caveat

Preserve the existing SPF policies used by other legitimate senders. If a separate, provider-supported change is needed at a TXT policy you control, maintain one v=spf1 record per evaluated owner, merge authorized mechanisms instead of concatenating policies, and preserve the approved terminal qualifier. Review SPF's ten lookup-causing-term budget including nested mechanisms. Any all mechanism makes redirect ineffective, so a redirect-based policy needs deliberate handling. Do not add +all or delete a legitimate sender to fit a limit. SPF requirements

A provider-managed envelope may pass SPF without aligning under your domain's effective aspf setting. That is different from SPF fail, temperror or permerror. Strict alignment requires exact domain equality; a child envelope is not automatically strictly aligned with its parent From.

7. Preserve DMARC and approved reporting

Syncro describes Verified Domains in terms of DMARC/DKIM, but its three issued CNAMEs should not be mistaken for a _dmarc policy. Inspect the visible From domain's direct and applicable inherited DMARC policy. Preserve existing p, applicable child policy, adkim, aspf and authorized report destinations. A missing child record does not mean there is no inherited protection. Current DMARC specification

If no applicable policy exists, plan an owner-approved monitoring rollout separately. Do not weaken an existing enforcement policy, duplicate _dmarc, add obsolete percentage tags or impose reject merely because Syncro shows green checks. Authentication changes must be checked across legitimate senders before policy escalation.

Aggregate-report rua destinations receive authentication reports, not forwarded quarantined messages. Compare the Organizational Domain of the report URI destination host with that of the domain where the policy was found, including an inherited policy. When they differ, the report-generating receiver checks DNS authorization; a destination within that same Organizational Domain is excepted. Protocol authorization does not replace approval to disclose report data. RFC 9990 section 4

8. Verify a real message without triggering customer workflows

Have an authorized operator use an existing approved native workflow with a controlled valid recipient, harmless content and the intended mailbox. Confirm all recipients and side effects first. Do not create a real invoice, customer ticket, marketing send or inbound-forwarding event merely to get a sample. The reviewed sources do not establish a special outbound authentication-test button. If no safe authorized path is available, leave message acceptance pending.

Use receiver-controlled diagnostics or have the receiving administrator identify results generated inside the receiver's trusted processing boundary and explain how externally supplied Authentication-Results are removed or distinguished. A familiar authserv-id string or header position alone is not proof. Authentication-Results trust boundaries

Acceptance requires all of the following:

• The actual message used the intended Syncro Internal Email mailbox and approved visible From, without an unnoticed provider-address rewrite.
• The intended native DKIM signature passes, with its actual d= and s= corresponding to the expected account configuration.
• That same signature aligns with From under effective adkim: Organizational Domain comparison for relaxed alignment, exact domain equality for strict alignment.
• The trusted receiver reports DMARC pass for that From. SPF-only DMARC pass or an unrelated passing gateway signature is not evidence that this DKIM setup works.
• The actual MAIL FROM and SPF result are recorded and any SPF errors investigated independently.

Retain sanitized identities, selector, results and timestamp rather than confidential message contents. See raw DKIM results versus aligned DKIM policy results.

Troubleshooting

One or more rows remain unverified: Compare full owners and targets, DNS authority, conflicting records, proxying and flattening. Check all three issued rows. Refresh after public DNS is correct; do not keep creating new domains or copying values from another tenant.

Verified but the intended signature is absent: Check the actual mailbox delivery method, approved From and category/organization selection. A customer SMTP route is outside this procedure. Ask Syncro to investigate the verified native route rather than inventing another signing toggle or weakening DMARC.

DKIM passes but DMARC fails: Check alignment of the intended d= with the actual From and effective policy. A cryptographically valid but unaligned signature is not itself a DKIM cryptographic failure.

SPF fails despite DMARC pass: Fail or softfail calls for checking the actual route's authorization; temperror indicates transient evaluation trouble such as DNS availability; permerror calls for investigating syntax, duplicate policies or lookup limits. Aligned DKIM can produce DMARC pass without fixing these SPF problems.

Another service breaks after the DNS edit: Compare the saved record-level changes and coordinate a bounded restoration after checking intervening edits. Do not restore an entire old zone, delete all selectors or switch global outbound categories as a rollback shortcut.