For Pipeline CRM, formerly PipelineDeals, the documented Email Sync route connects your existing Google or cloud-hosted Microsoft mailbox. Configure and verify your business domain’s SPF and DKIM with that mailbox provider, then check a message sent from Pipeline CRM itself. Connecting the inbox is not DNS authentication, and a CRM activity record is not evidence that branded DKIM or DMARC passed.
There is no universal Pipeline CRM SPF include or DKIM selector established by the current Email Sync instructions. Do not copy Mailgun records from a different product called Pipeline, or substitute an arbitrary SMTP server. This guide covers an existing supported mailbox connection and individual CRM email, not a native Pipeline domain-signing service, on-premises Exchange, bulk campaign commissioning or a migration between mailbox providers. Pipeline CRM Email Sync.
No customer mailbox, DNS, permissions or messages were accessed or changed for this guide.
Check the product, mailbox and plan
Pipeline CRM confirms that it was previously named PipelineDeals. A similarly named application is not evidence about this product’s mail infrastructure. Official product identity.
Before troubleshooting authentication, identify the CRM user, the mailbox actually connected, its hosting provider, the intended visible From address and the domain owner. The synced address must be the CRM sign-in address; aliases are not supported. Supported accounts are Gmail and Microsoft-hosted Exchange Online, Microsoft 365/Office 365 or Outlook.com, not self-hosted Exchange.
The current plan table lists individual email on Start and Develop. Start includes up to 250 tracked emails per user; Develop has unlimited tracking. Grow and Enterprise add bulk emails, templates and campaigns. Tracking allowances are not sending quotas or permission to send unsolicited mail. Confirm your actual entitlement before commissioning a different sending workflow. Supported accounts and plan boundaries.
A consumer gmail.com or outlook.com address is not a custom business-domain authentication task: you do not control those domains’ DNS. If the intended brand From is an unsupported alias or a different mailbox, stop and agree a supported sender arrangement with the administrators. Do not silently change the CRM login, select another employee’s mailbox or rewrite the From to make a check turn green.
Approve mailbox access before connecting
Email Sync grants access to email and moves information into CRM records. Obtain explicit mailbox/security-owner approval for the specific account, requested permissions, CRM recipients, stored data and intended use before connecting or expanding an existing connection. Review the actual authorization screen; if it requests unexpected access or tenant-wide consent, stop for a qualified administrator’s decision. This is not a routine DNS repair.
Pipeline’s security documentation distinguishes the providers: Gmail is presented as a live mailbox view without storing raw messages, but CRM activities are stored. For Microsoft, email copies are stored outside the mailbox provider even when no activity is created. Disconnecting stops further sync but does not remove previously logged activities. The documentation gives separate deletion timelines for stored copies and account cancellation; verify the applicable retention requirement before approval rather than assuming disconnect means immediate deletion. Email Sync data handling.
The setup and inbox pages disagree about the first import window, describing 30 and 60 days respectively. Do not treat either as an assured data-minimization boundary. Have Pipeline confirm the current account behavior if that affects your approval. Do not test with a mailbox containing unapproved sensitive correspondence.
Do not disable MFA, shorten or bypass security review, exempt the application from reauthentication, or broadly mark it trusted to cure a disconnection. Preserve organizational access controls. A supported reconnection requires its own authorized account and permission review, not a general exemption.
Establish upstream SPF and DKIM responsibility
The Google or Microsoft mail administrator must establish how this particular mailbox sends mail, including any approved outbound gateway. Pipeline’s sync settings do not issue a new tenant DKIM key. Use the mailbox provider’s current, account-specific domain-authentication procedure and have the administrator confirm that signing is active for the intended custom domain. Do not infer active signing merely from DNS records being present.
For SPF, identify the SMTP MAIL FROM domain reported by the receiving service, which is not necessarily the visible From domain. Validate the one applicable v=spf1 TXT policy at that actual owner. A parent’s SPF does not automatically cover a child domain. Preserve legitimate existing senders and qualifiers; do not add a second SPF policy or overwrite the apex with a guessed Pipeline include. The SPF limit is ten evaluated DNS-dependent terms, including nested lookups, not ten top-level includes. An all mechanism makes redirect ineffective. SPF evaluation and processing limits.
For DKIM, obtain the complete current public DNS packet from the mailbox provider’s administrator, using its exact owner, record type and target or TXT value. Never invent a selector, derive a tenant target from another organization’s example, or expose private signing keys. Publication and signing activation are separate steps. If an existing key or delegation is shared with other traffic, preserve it while the administrator plans any rotation.
This guide deliberately does not provide Google/Microsoft DNS literals or change inbound MX, nameservers, DNSSEC, connectors or routing. If upstream authentication is not configured, complete the appropriate approved mailbox-provider setup first. DNS changes must follow the provider’s actual issuance and the authoritative DNS host’s rules, not the CRM connection dialog.
Preserve DMARC and identify the aligned sender
Keep the existing direct or inherited DMARC policy and authorized reporting destinations. Do not weaken protection, add a child monitoring override, or alter reporting simply to connect a CRM. Creating a first DMARC policy is a separate domain-owner rollout, not a prerequisite instruction to paste into this connection workflow.
DMARC passes with either a passing aligned SPF identity or a passing aligned DKIM signature. For DKIM, compare the verified signature’s d= domain with the visible From domain. For SPF, compare the authenticated MAIL FROM domain. Relaxed alignment uses the Organizational Domain; strict adkim or aspf requires an exact domain match. A child envelope domain may align relaxed but fail strict alignment. Current DMARC rules.
For the branded DKIM setup being validated here, require the intended mailbox-provider signature to pass and align, plus a trusted dmarc=pass. DMARC passing through SPF alone does not prove DKIM is working. A passing signature for an unrelated provider domain, or a rewritten From, does not establish the intended brand identity. See raw DKIM results versus aligned DKIM results.
Use the authorized Pipeline inbox route
After the account and data-sharing approval, the documented connection path is Tools > Email > My Inbox > Sync my email. Choose Google (Gmail) or Microsoft Exchange for the actual supported account, authenticate with that provider and review the connection consent. Do not supply credentials in a support message or select a different account simply because the browser already has it signed in. If the inbox is already connected correctly, do not disconnect it just to repeat this tutorial. Connection procedure.
To test the individual-email route, open Tools > Email > My Inbox and use Compose Email. Select a controlled external recipient who has authorized the test, write a harmless identifiable message and send only after checking the intended address. Pipeline documents the sender as the primary email address in the CRM profile. If that differs from the approved login/connected mailbox, stop and resolve the identity rather than assuming an alias will work. Inbox and sender behavior.
Use no confidential attachments or customer campaign list. Do not add a BCC logging address or create contacts as a side effect of an authentication test. An ordinary message from Outlook or Gmail is useful for comparison, but it does not replace a test from the actual CRM path.
Accept the result only with receiver evidence
Ask the recipient for the original message and the receiving service’s own processing results, or an administrator trace. Use results generated inside that service’s documented trusted boundary and its handling of externally supplied Authentication-Results. A familiar authserv-id, header position or copied result string is not enough to trust a header. Ignore injected external result fields. Authentication-Results trust boundaries.
Record privately:
- The tested CRM user, connected mailbox/provider, workflow and time.
- The actual visible From and SMTP MAIL FROM domains.
- The intended DKIM signature’s
d=domain ands=selector, verification result and alignment mode. - The trusted SPF result, DKIM result and overall DMARC result.
- Whether the received message preserved the intended sender and arrived through the expected route.
Acceptance requires the correct supported account, intended From, passing aligned intended-provider DKIM and dmarc=pass. Evaluate SPF independently: distinguish authorization failure, temporary lookup error and permanent policy/syntax/lookup-budget error, even when DKIM supplies the DMARC pass. A CRM “sent” state, an activity log or an open-tracking event does not satisfy these checks. Authentication also does not guarantee inbox placement.
Test each materially different intended workflow separately before relying on it. This individual-email guide does not certify bulk campaigns, another employee’s mailbox, a new gateway or a provider migration. Recheck after relevant signing, sender or routing changes.
Troubleshoot without weakening controls
The connection fails before sending: check supported provider, exact login address, current authorization and plan with the administrators. DNS changes do not repair an OAuth permission or account mismatch. Do not fall back to unsupported on-premises Exchange or arbitrary SMTP credentials.
Mail works from Gmail or Outlook but not from Pipeline: compare the actual sender, trusted authentication results and diagnostic response from both paths. Separate an unsent CRM message from a remote rejection. Do not assume the error is DMARC just because the domains differ.
DKIM is missing or unaligned: have the upstream administrator check the intended domain’s signing activation and actual outbound route. Do not fix it by rewriting the brand From or accepting a different signature. If a gateway modifies signed content, have its security owner investigate without disabling mandatory protection.
SPF fails but DKIM passes: retain the successful DKIM evidence while resolving the actual envelope policy or lookup error. Never add Pipeline’s website domain to SPF merely because the mail originated in its UI.
A rejection occurs despite authentication passing: inspect the actual response. Recipient policy, limits, consent, reputation and content may matter; a DNS record is not a cure for every bounce. Pipeline’s deliverability guidance says provider limits still apply. Delivery troubleshooting.
The CRM history is absent or incomplete: investigate logging and access separately. Neither missing activity nor a completed import proves anything about DKIM. Avoid repeated reconnections that resync data without an approved reason.
For escalation, provide support with the affected workflow, time, provider, redacted error and non-secret domain/selector evidence through an approved channel. Do not disclose passwords, tokens, private keys or full customer messages. If the supported route cannot be confirmed, pause the affected test or sending workflow safely and resolve it with the mailbox and CRM administrators.