Freshsales SPF, DKIM and DMARC setup, step by step

Identify which service actually sends your Freshsales or Freshmarketer email before editing DNS. Connected-provider SMTP uses that mailbox service's authentication; Freshsales-native sending uses the domain records generated for the applicable Freshsales account. For the documented Domain Verification flow, open Admin Settings > Domain Verification > Add domain > View DNS record. For an entitled Freshsales campaign workflow or the documented Freshmarketer campaign route, use Admin Settings > Email Sending Domains. Freshmarketer also requires business verification before campaign sending; domain authentication does not replace that prerequisite. Publish the account's full record set, verify it, and test the exact route for branded DKIM and DMARC alignment. Freshsales domain verification, campaign domain setup.

Start with the edition, workflow and SMTP transport

This guide covers Freshsales and the relevant sales/campaign features of Freshsales Suite, plus Freshmarketer marketing campaigns using the shared Email Sending Domains workflow in Branch C. Keep Freshsales Classic, current account controls, connected mailbox SMTP and native Freshsales SMTP distinct. Freshmarketer is included only for that documented campaign route, not as an extension of Freshsales connected-mailbox or Classic instructions. This is not a Freshdesk, Freshchat or Freshservice setup recipe. Freshworks hosts several products' articles under similar support-site headings, so the body and your account's actual feature matter more than the page's site branding.

Use this decision map before collecting records:

Freshsales documents Profile > Connect email > change email server for choosing the outbound SMTP service. Its workflow guide says an account's shared sales address uses Freshsales SMTP, and that Freshsales SMTP is used when custom SMTP has not been configured. Inspect the chosen route; do not switch production transport merely to follow a tutorial. The page contains historical plan names, which are not evidence of today's limits. Workflow transport guidance.

Freshsales also distinguishes sales sequences from marketing journeys; the latter are not a feature of every standalone Freshsales account. A campaign article does not establish entitlement or transport for an individual sales email. Product and workflow distinction.

Prepare an account-specific change

Record the account edition, exact workflow, chosen SMTP provider, intended From address, Reply-To address and domain owner. Obtain access to the applicable Freshsales admin controls and authoritative DNS zone. The company where the domain was registered may not host its DNS.

Export existing DNS records and preserve all legitimate senders, inbound MX, website records and the effective DMARC policy. Note who owns each requested hostname, who can pause a sequence or campaign, and who can restore the last approved setup. Reserve a harmless controlled message and recipient for testing each materially different route.

You can authenticate only a domain you control. Do not attempt to publish your organization's keys beneath a public mailbox provider's domain. Keep private keys and mailbox credentials out of DNS, support screenshots and change tickets.

Domain/address verification and protocol authentication are different checks. Freshworks distinguishes administrator-led domain verification for the organization from individual users connecting their own inboxes. One user's connection does not verify everyone else's address or prove branded DKIM on every route. Freshsales sender verification.

Branch A: a connected mailbox sends the message

Check the connected account and selected SMTP server from the profile's Connect email controls. The current mailbox article documents provider selection and one-way/two-way synchronization; those sync choices concern mailbox integration, not the DNS domain that SPF or DKIM authenticates. Review mailbox-access permissions with IT instead of granting organization-wide access or generating credentials as an authentication troubleshooting shortcut. Current connection guidance.

When mail uses the connected provider's SMTP, Freshsales restricts From to the connected email address. Its guidance distinguishes Team Inbox sending through Freshsales SMTP. The route can therefore change when the selected sender changes. Reply-To can differ, but changing it does not repair DMARC alignment. From and Reply-To behavior.

For an organizational mailbox, configure SPF and branded DKIM with the actual outbound provider, using that provider's current domain records and activation step. Do not add a Freshsales include solely because the message was composed in Freshsales. Use the Google Workspace authentication guide or Microsoft 365 authentication guide when those services own the route; another SMTP service requires its own issued values.

Then send the acceptance sample from Freshsales through that connected route. A successful message sent directly from the mailbox's web interface does not prove Freshsales used the same transport. If the mailbox disconnects, diagnose the connection separately and re-establish it through the current approved provider flow. Do not disable MFA or revive obsolete app-password instructions from a historical article.

Routing approval for both Branch B and Branch C: Before publishing any native/Classic or campaign packet below, compare every exact owner, target and tracking destination with the approved routing plan. Obtain separate approval for tracking/web-routing changes and the intended SPFMX/bounce routing. If there is a conflict or no approval, stop and coordinate a supported complete packet with Freshworks and the DNS owner; do not omit required records or overwrite/activate an unapproved route. This gate also applies to the full-packet instructions and FAQ below.

Branch B: Freshsales-native domain verification and Classic context

Freshsales' Classic DKIM documentation describes a native-platform migration and a 2 June 2024 deadline for selected notified accounts. That date is historical. It does not establish a new deadline, prove your account migrated or require every existing domain to be deleted today.

Where your account exposes the documented Domain Verification workflow:

1. Open Admin Settings > Domain Verification and select Add domain.
2. Enter the domain you own and select Add.
3. In the domain list, choose View DNS record.
4. Copy every issued record's type, owner and value from your account. Distinguish DKIM, mail-service/SPFMX and tracking records.
5. Publish the issued records safely, then return to Freshsales and choose Verify.
6. Confirm every required row changes to Verified, followed by the domain's Verified state. Review the intended default domain rather than changing it blindly.

The Classic source illustrates nine CNAMEs, including four _domainkey owners, one SPFMX-related owner and tracking/link owners. They are not nine DKIM keys, and the example hostnames and values are explicitly representative. Retrieve the current set rather than generating targets from the illustration. The source also says unverified existing domains can prevent adding another; resolve the account state before assuming a plan limit or deleting a functioning domain. Classic/native domain instructions.

For a modern native-SMTP account, the workflow documentation still directs administrators to domain verification when workflow mail will not send. Match the controls and generated set in that account. If the interface instead exposes the campaign path below, confirm its applicability to the message you intend to send. If neither documented path matches, stop the affected change and ask Freshworks to identify the supported domain setup for the exact edition and route. Do not substitute another Freshworks product's records.

Branch C: Freshsales or Freshmarketer campaigns use Email Sending Domains

The Freshworks campaign-domain article explicitly lists Freshsales, Freshmarketer and Freshsales Suite. Its February 2024 body describes Email Sending Domains; the illustrative Configure screenshot retains an older Domain Verification breadcrumb. Use the current account’s supported controls and generated values, not the screenshot’s sample domains. This shared configuration does not make Freshmarketer campaigns the same product or transport as a connected Freshsales sales mailbox. Shared product applicability.

For the applicable campaign account, follow this procedure:

1. Open Admin Settings > Email Sending Domains and select Add domain.
2. Enter Domain name, Primary Sender Name and Primary Sender Email Address, then select Create.
3. On Configure, copy the Host and Value for every generated row.
4. Publish those rows at your authoritative DNS provider and select Verify in Freshworks.
5. Review each row's status. The domain remains Pending until all required records verify. Select the intended primary domain for the campaign only after verification.

Approve routing before publication. Compare each exact issued owner and target, including the SPFMX/bounce route and tracking-link destinations, with the domain owner’s approved routing plan. Copying the packet is not approval to redirect a website, tracking hostname or mail/bounce route. Obtain separate authorization from the responsible owner for tracking or web-routing changes and approval for the intended mail-service routing. If a target conflicts with an existing service, or the routing change is not approved, stop and coordinate a supported configuration with Freshworks and the DNS owner. Do not silently omit required rows to force verification, overwrite an active service, or activate an unapproved route. Resume only when the approved complete packet can meet Freshworks’ all-record verification requirement.

The source's example separates DKIM, SPFMX and tracking CNAMEs and says the values vary by domain. Do not omit the SPFMX or tracking rows simply because the immediate task is DKIM. The provider advises that verification can take up to 48 hours; this is not a reason to wait on a demonstrably wrong record. It also says a verified domain's primary email can be edited but its domain name cannot, and deleting the domain removes it from the application. Plan changes accordingly. Campaign configuration and lifecycle.

Freshmarketer prerequisites and the campaign that will actually send

Freshmarketer’s July 2024 campaign guide separates business verification from adding an email-sending domain. An unverified business sees a banner directing the verification process. Resolve that requirement through the account’s approved process before commissioning campaign sending; publishing DKIM cannot satisfy it. Review any requested business information and permissions with the responsible owner rather than submitting them merely to clear a banner. Do not assume historical trial or plan limits establish the entitlement of today’s account. Freshmarketer campaign prerequisites.

Identify which documented Freshmarketer route is being commissioned:

• One-time campaign: created from the Campaigns module’s Email tab, with an immediate or scheduled send.
• Journey email: sent through a customer journey’s email action when its configured entry/action conditions occur.
• API-triggered transactional campaign: created in Campaigns and triggered by the application’s backend event. This is not a Freshsales connected-mailbox SMTP setup.

The provider’s campaign process separates preview/test sending from configuring the actual campaign’s From, subject and recipients. After the domain and business prerequisites are satisfied, choose the approved From address under the authenticated domain in the intended campaign. Do not assume the primary-domain choice alone proves every existing campaign uses it. Review already configured senders before changing a primary email or domain. Campaign types and sender configuration.

Use an approved controlled contact and recipient for acceptance. A preview test is not proof of a production journey’s entry conditions or an API-triggered stream’s deployed configuration. Arrange a safe test of the intended message route with the application/campaign owner, without enrolling real customers or firing payment/password-reset events unnecessarily. Keep business approval, provider domain verification, actual sender selection and receiver authentication as four separate evidence gates. A passing one-time campaign does not certify an untested journey or backend-triggered message.

Publish DNS correctly without guessing an SPF include

Neither the Classic native-platform table nor the cited campaign table justifies applying an old standalone root SPF recipe to every Freshsales route. Use the complete issued CNAME/SPFMX set and establish the actual envelope domain. Do not substitute Freshdesk's SPF include, an old Freshsales example or a marketing-product recipe for the current account instructions.

If the applicable account instructions explicitly require an SPF TXT edit, merge only that authorized mechanism into the one existing policy at the named envelope owner, before its terminal all. Preserve other approved senders and the existing qualifier. Do not add a second v=spf1 record, append a second full policy or add TXT at an owner already holding a CNAME. SPF does not inherit from a root domain into its subdomains. SPF rules.

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

Check the evaluated lookup chain before saving. SPF limits the combined evaluated include, a, mx, ptr, exists and redirect terms to ten, including nested terms. ip4, ip6 and all do not use that budget; additional MX and void-lookup limits apply. Do not flatten a provider include into a static IP snapshot. The SPF lookup-limit guide explains why a short-looking policy can still fail.

For DNS names, assume the account issues SELECTOR._domainkey.sales.example.com. These examples illustrate mapping, not deployable Freshsales records:

For an issued mail-service owner MAILHOST.sales.example.com, use MAILHOST.sales in the parent zone or MAILHOST in the delegated child. Retain the sending subdomain exactly once. A root-domain SPF instruction would use the root zone's apex; it is not interchangeable with a child-domain instruction.

For a separately delegated _domainkey.sales.example.com namespace, the full key owner SELECTOR._domainkey.sales.example.com maps to relative SELECTOR at that authority. Use the actual issued selector and type/target; preserve the namespace’s NS delegation and other active selectors. Relative DNS names.

CNAME destinations are hostnames, not URLs. Keep authentication aliases DNS-only, not HTTP-proxied, and prevent flattening from replacing the expected CNAME response with address records. Resolve occupied names before changes; ordinary TXT, MX or A data cannot coexist at the same CNAME owner. Leave inbound mail routing, the website and unrelated DKIM selectors alone. DNS CNAME requirements.

If Cloudflare hosts the relevant authentication records, check DNS only, the record-level Flatten option is off, and the zone-wide CNAME flattening for all CNAME records setting is off. A DNS-only record can still be flattened. Coordinate any zone-wide change with owners of other affected services rather than changing a shared setting blindly. If NS records delegate the sending subdomain or _domainkey to another DNS service, publish the record at that authoritative service and preserve the delegation; do not remove NS records just to make a parent-zone entry visible. Cloudflare CNAME verification troubleshooting.

Keep the required literal CNAME answer: turn relevant per-record Flatten off where available and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, apex CNAMEs are flattened by default and same-zone targets are flattened regardless of that setting; flatten-all cannot be overridden per record. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration without breaking other services or removing NS delegation. These are DNS-host behaviors, not controls assumed in the sending provider. Cloudflare flattening controls and limits.

Preserve DMARC and require aligned branded DKIM

DMARC uses the visible From domain. SPF evaluates the SMTP MAIL FROM identity, normally reflected in Return-Path; DKIM identifies the signing domain through d= and the key selector through s=. Reply-To, display name and SMTP server hostname are not substitutes for these identifiers. SPF, DKIM.

DMARC passes when either mechanism passes and its domain aligns with From. Relaxed alignment allows an organizational-domain match. Strict aspf=s or adkim=s requires the corresponding domains to match exactly. For From sales.example.com, DKIM d=sales.example.com aligns in either mode; d=example.com only aligns in relaxed mode. A successful signature for an unrelated Freshworks or mailbox-provider domain is not branded alignment. Current DMARC standard.

Find the effective policy for the actual From domain, including applicable parent-domain policy discovery. Preserve existing enforcement, reporting destinations and intentionally selected alignment modes. If no policy applies and the domain owner approves monitoring, a starter TXT value at _dmarc.FROM_DOMAIN can be v=DMARC1; p=none; rua=mailto:APPROVED_REPORT_ADDRESS. Replace placeholders, confirm the reporting mailbox and obtain external report-destination authorization where required. Do not overwrite an established record or add a duplicate. Aggregate reporting.

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4. For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names.

p=none requests no DMARC enforcement and does not force delivery. RFC 9989 supersedes RFC 7489 and removes pct; avoid new percentage-enforcement plans. Section 7.4 requires valid DKIM for p=reject domains and cautions about indirect mail. Do not tighten the whole organization's policy based on one sales-message sample.

Verify account status and public DNS

For native sending, finish the applicable Verify action and confirm all required rows. For connected SMTP, verify the outgoing provider's domain-signing activation separately. Then use exact issued names in reader-run DNS checks:

dig +short NS AUTHORITATIVE_ZONE
dig @AUTHORITATIVE_NAMESERVER DKIM_OWNER_FQDN CNAME +noall +answer
dig DKIM_OWNER_FQDN CNAME +noall +answer
dig DKIM_TARGET_FQDN TXT +noall +answer
dig MAIL_SERVICE_OWNER_FQDN CNAME +noall +answer
dig ENVELOPE_DOMAIN TXT +noall +answer
dig _dmarc.FROM_DOMAIN TXT +noall +answer

Uppercase values are placeholders. If the actual SMTP provider issues TXT DKIM, query the DKIM owner for TXT instead. Repeat for all required records and follow alias chains. The public owner and target must match the issuing account; authoritative and recursive answers should converge after caches expire. Empty answers, NXDOMAIN and SERVFAIL are not a pass. A resolvable public key still does not show that the intended message was signed with it.

Test each Freshsales or Freshmarketer route and record the receiver's result

After authorized setup, send a harmless message through the exact sales email, workflow, sequence or campaign being commissioned. For Freshmarketer, record the business-verification state and the particular one-time, journey or API-triggered campaign along with its configured From address; do not substitute a Freshsales mailbox test. Use a controlled contact and recipient, not a production-wide trigger. A preview or sync-success message is not a delivered-message test.

Read the receiving mailbox provider's trusted Authentication-Results in the raw message. Confirm its authentication-service identity and trust boundary using the receiver's documentation and delivery trace; do not accept arbitrary upstream headers or trust a field solely because it appears first. RFC 8601.

Establish provenance through receiver-controlled evidence: the mailbox service's documented handling of authentication results, its trusted administrative logs, or confirmation from its mail administrator. A familiar authserv-id, a copied Received line or header position alone can be forged and is insufficient. Ignore results supplied from outside that established trust boundary unless the receiving administrator has explicitly configured a trusted relationship for them. If provenance is unclear, obtain the receiver's own verdict before accepting the test. RFC 8601 section 7.1.

Keep one row per materially different route:

Accept branded setup only when the actual From is correct, the intended sending provider’s branded DKIM signature passes and aligns, and the trusted receiver reports dmarc=pass. Another aligned signature alone cannot establish that the intended route’s signing setup works. Account activation and DNS must also match. Explain or repair unexpected SPF errors rather than hiding them behind a DKIM pass. This stronger setup check proves the intended DKIM work; the protocol itself still permits either aligned mechanism to satisfy DMARC.

Repeat after transport changes, sender-domain changes or migration. A passing connected-mailbox email cannot certify a shared sales-address workflow that uses native SMTP. Keep message evidence private and avoid uploading full customer correspondence to public checkers.

Troubleshooting and recovery

Domain verified, but a workflow does not send: first check mailbox connection, selected sender, workflow execution and ownership conditions. Freshsales' workflow guidance separately checks connected mailbox and domain verification. DNS is not the only possible cause. Workflow troubleshooting.

From address cannot be changed: confirm whether the connected provider's SMTP restriction applies. Do not switch to native SMTP until its domain authentication has been prepared and approved.

Records look correct but remain Pending: compare the full public owner with the requested name, including the sending subdomain. Check the authoritative zone, accidental suffix duplication, cross-account targets, CNAME proxying/flattening and unverified non-DKIM rows. Escalate a product/interface mismatch instead of copying a Freshdesk recipe.

SPF permerror: inspect the actual envelope policy for duplicates, syntax, nested includes/loops, the ten-term budget and void lookups. SPF temperror: investigate transient DNS failure. SPF fail or softfail: confirm the route and connecting IP against the actual envelope policy; forwarding can change that IP. An include cannot change an unrelated envelope identity into an aligned one.

DKIM missing, invalid or unaligned: check the actual s=._domainkey.d= name and account activation. A valid provider-domain signature is not enough for branded setup. An invalid signature can reflect a missing/replaced public key or downstream message modification. Changing Reply-To cannot repair either issue.

A migration or re-verification breaks sending: pause the affected campaign or sequence where operationally safe, compare the saved and current record sets, and restore the approved last-known-good route with the responsible administrator. Keep old DKIM records until queued mail and signing rotation are accounted for. Do not weaken domain-wide DMARC, publish +all or delete unrelated DNS to make verification green.