Mailigen SPF, DKIM and DMARC setup, step by step

To authenticate email sent through Campaigns by Pipedrive, generate the domain’s DNS records in Campaigns → Settings → Domain authentication. Publish the three account-issued CNAMEs: two for DKIM and one for SPF/return-path handling. Review the domain’s existing DMARC policy, refresh the domain status, and separately verify the sender email. Do not invent a Pipedrive SPF include or replace your root SPF record. Pipedrive’s current domain-authentication procedure documents this route.

This guide explains the documented setup and validation process. It does not report a test in your Pipedrive account, your DNS, or a recipient mailbox.

On this page

• Check that this is the right Pipedrive sending route
• Prepare the account and DNS
• Generate and publish the three CNAME records
• Handle DMARC without weakening an existing policy
• Refresh authentication and verify the sender
• Validate public DNS and a delivered campaign
• Troubleshoot Pipedrive authentication
• Frequently asked questions

Check that this is the right Pipedrive sending route

This procedure is for the Campaigns marketing add-on, whose Standard and Premium tiers both include sender domain authentication. It is not the configuration for a Gmail, Microsoft 365, Exchange, or other mailbox connected to the Sales Inbox. Group emails and automations sent through a synced mailbox must be assessed against that mailbox’s actual sending infrastructure. Campaigns tier comparison and email sync documentation distinguish the products.

If you arrived here from an older Mailigen setup guide, use the current Campaigns records. Pipedrive identified Campaigns as Mailigen’s successor in its June 2022 announcement. That history does not make old Mailigen TXT records, selectors, or control-panel steps interchangeable with today’s Campaigns setup. Do not delete old records until you have confirmed that no active sender still depends on them.

The identities to keep separate are:

• Visible From: the sender email selected for the campaign. This is the domain DMARC evaluates.
• SPF identity: the SMTP envelope sender, normally shown as smtp.mailfrom in the receiver’s results. The return-path CNAME supports this sending path, not every service using your brand.
• DKIM identity: the d= signing domain and s= selector on each signature. The two DKIM CNAMEs delegate public-key lookup to Pipedrive-managed targets.
• Reply-To: the address for responses. Changing it does not repair SPF or DKIM alignment.

The sender FAQ defines the campaign sender fields. The protocol distinctions come from SPF, DKIM, and DMARC identifier alignment.

Prepare the account and DNS

Before making changes, confirm these prerequisites:

• You have access to Campaigns and the Manage sender and domain information permission. Send campaigns is a separate permission. Ask an account administrator to check access if the controls are missing, rather than assuming that every CRM user can manage authentication. Pipedrive permissions
• You own or are authorized to manage the intended sending domain and can edit its authoritative DNS. The registrar is not necessarily the DNS host.
• You have an existing company-domain sender mailbox that can receive Pipedrive’s verification email. Disposable and free-provider sender addresses are not accepted for Campaigns. Sender requirements
• You have recorded the current SPF, DKIM selectors, DMARC policy, and any delegations at the proposed names. Keep a DNS export or change record for rollback.

Pipedrive permits up to 20 domains per company account. Before removing an entry to make room, identify which campaigns and senders use it. Account-settings access is required to purchase the add-on, but purchasing it is separate from this authentication procedure. Domain limit and billing access.

Generate and publish the three CNAME records

1. Request the records in Campaigns

1. Open Campaigns → Settings → Domain authentication.
2. Select + Domain.
3. Enter the domain you intend to use, without www, http://, or https://.
4. Select Get DNS records.
5. Expand the domain’s Domain records section and record every displayed type, name, and value.

The current procedure issues three CNAME records and displays a DMARC TXT instruction. Copy the current account’s records, not the example values in a screenshot or another company’s guide. The official procedure is the authority for the generation and status controls.

2. Map each name to the authoritative DNS zone

The two DKIM owners contain _domainkey. The third CNAME serves the return-path/SPF function. All three targets are account-generated hostnames. Do not turn the third row into an apex SPF TXT record or change its target to a guessed include domain.

A relative DNS editor appends its zone name. For illustration only, if Pipedrive issued selector-from-account._domainkey for example.com, the final owner would be selector-from-account._domainkey.example.com. An editor expecting the full name needs that complete owner instead. Avoid accidentally publishing example.com.example.com.

If the generated owner is under a delegated child zone or _domainkey namespace, publish it at the nameservers authoritative for that child. A record in the parent zone will not override the delegation. Confirm the final public owner rather than trusting how the DNS form displays it.

For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.

At each CNAME owner, check for an existing CNAME, TXT, A, or other ordinary record. A CNAME cannot coexist with conflicting ordinary data at the same name. Do not overwrite another sender’s selector or a return-path already in use. Resolve ownership with the DNS administrator and Pipedrive before proceeding. DNS alias rules

3. Publish exactly the issued CNAMEs

Use each row’s name and target. Keep the target as a hostname, without a URL scheme or added zone suffix. The DNS host’s normal TTL is suitable unless your change plan specifies another value. Pipedrive supplies a DNS-provider reference list, but the current authoritative DNS service is where the changes belong.

For Cloudflare, these authentication CNAMEs should be DNS only, not proxied. Check both per-record flattening and the zone-wide “flatten all CNAMEs” setting: DNS-only alone does not guarantee that a CNAME answer is returned. Cloudflare documents that all-CNAME flattening cannot be overridden per record. Do not move the issued records to the apex; apex and same-zone aliases have separate flattening behavior. If correcting it affects a shared zone, have the DNS administrator assess the wider impact instead of disabling website protections globally. Proxy guidance and flattening behavior.

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.

Do not change MX, parent nameservers, DNSSEC, or mailbox providers to match this procedure.

Why there is no root SPF record to paste here

Pipedrive’s current Campaigns instructions use a CNAME for the SPF/return-path component. Leave the root SPF policy and its legitimate senders intact. Adding a guessed include at example.com cannot fix a message whose SPF evaluation uses a different envelope domain.

If a separate, verified sending requirement calls for changing an SPF TXT policy, keep one v=spf1 policy per owner, preserve authorized senders and the existing failure policy, and evaluate the complete nested lookup path. SPF allows at most ten DNS-lookup-causing terms during evaluation, including nested include and redirect processing, not ten visible includes per line. Do not flatten provider ranges into static IPs without an ongoing maintenance plan. SPF record selection and limits

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.

Handle DMARC without weakening an existing policy

Pipedrive displays a DMARC TXT row alongside the three CNAMEs. Its example permits your own applicable policy. First query the policy for the intended visible From domain and check whether an ancestor policy applies through DMARC policy discovery. A missing direct record does not necessarily mean the domain has no protection. Preserve existing policy, alignment settings, and reporting destinations. DMARC policy discovery

Do not publish a second DMARC policy or replace p=quarantine or p=reject with p=none to make a setup screen green. If Pipedrive does not recognize a valid existing policy, resolve the discrepancy with support before changing enforcement.

Only if no direct or inherited DMARC policy applies, and the domain owner chooses an initial monitoring policy, this is a minimal first record for the illustrative From domain example.com:

Type: TXT
Full owner: _dmarc.example.com
Host in an example.com zone: _dmarc
Value: v=DMARC1; p=none

Replace example.com with the actual From domain. For news.example.com, the full owner is _dmarc.news.example.com: use _dmarc.news in the example.com zone, or _dmarc in a separately delegated news.example.com zone. Do not create that child record merely to bypass an inherited policy.

This minimal value requests no DMARC-based quarantine or rejection and has no reporting destination. It does not collect reports by itself. Add rua only for a mailbox or service the owner has approved and will review. If the recipient is outside the policy domain’s organizational domain, confirm the required external reporting authorization at the recipient’s DNS. Aggregate reports contain sending IPs, domain identities, and traffic information; agree access and retention before sharing them. Aggregate-report authorization and privacy

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.

Refresh authentication and verify the sender

After publication, return to the domain record section and select Refresh status. Pipedrive documents a transition from Pending to Authenticated and allows up to 48 hours for DNS changes. Check authoritative answers promptly; waiting cannot repair a misspelled name or wrong target. Status workflow

Domain authentication and sender-email verification are separate gates:

1. Add or manage the sender in Campaigns → Settings or from Create campaign.
2. Receive the system-generated email at that sender address and follow its verification link.
3. In the campaign’s sender-email dropdown, choose the verified address on the authenticated domain.
4. Confirm the visible From address, not just the display name or Reply-To.

All sender emails are shared with users who have full permission to send marketing campaigns. Review that access before adding a sensitive brand identity. Sender verification and sharing

Validate public DNS and a delivered campaign

Check DNS before a test send

The commands below are read-only templates. Replace every uppercase placeholder with the full name or nameserver from your configuration; do not publish the placeholder text.

dig NS YOUR_ZONE +short
dig @AUTHORITATIVE_NS DKIM1_FULL_OWNER CNAME +noall +answer
dig @AUTHORITATIVE_NS DKIM2_FULL_OWNER CNAME +noall +answer
dig @AUTHORITATIVE_NS RETURN_PATH_FULL_OWNER CNAME +noall +answer
dig @AUTHORITATIVE_NS DMARC_FULL_OWNER TXT +noall +answer
dig @1.1.1.1 DKIM1_FULL_OWNER CNAME +noall +answer
dig @1.1.1.1 DKIM2_FULL_OWNER CNAME +noall +answer
dig @1.1.1.1 RETURN_PATH_FULL_OWNER CNAME +noall +answer
dig @1.1.1.1 DKIM1_FULL_OWNER TXT +noall +answer
dig @1.1.1.1 DKIM2_FULL_OWNER TXT +noall +answer
dig @1.1.1.1 RETURN_PATH_FULL_OWNER TXT +noall +answer
dig @1.1.1.1 DMARC_FULL_OWNER TXT +noall +answer

Confirm each CNAME target matches the issued value and that DKIM lookup follows the alias chain to usable public-key TXT data. Inspect the provider-managed SPF answer through the return-path chain. Do not replace that delegation with a copied key or SPF value. If short output is empty, rerun without +noall +answer and inspect the response status: a timeout or SERVFAIL is not proof a record is absent.

Require evidence from the Campaigns path

Arrange a controlled campaign through the same route and sender configuration you intend to use, to a mailbox you control at an independent receiving service. A normal Sales Inbox message or a preview that does not use the same sending route is not an equivalent test.

Open the original received message and collect the visible From domain, envelope identity, all relevant DKIM-Signature d=/s= pairs, and the receiver’s SPF, DKIM, and DMARC results. Use only authentication results established as coming from the trusted receiving infrastructure. An Authentication-Results line or familiar authserv-id alone can be forged. If your receiver cannot distinguish or remove untrusted injected results, use an independent trusted mailbox or administrator-verified message trace. Authentication-Results trust boundary

Establish the actual receiving service’s known processing boundary and its documented handling of externally supplied Authentication-Results: removal, ignoring, or reliable distinction from results generated inside that boundary. If this cannot be established, ask the receiving administrator and use the existing trusted-trace or independent-mailbox fallback rather than accepting a header by position or familiar name. Operational receiving boundary.

Acceptance requires all of the following:

• The visible From remains the intended branded address, not a rewritten provider-domain identity.
• The intended branded Campaigns DKIM signature is present, passes, and aligns with the actual visible From domain. An unrelated provider signature passing is insufficient.
• The trusted receiver reports dmarc=pass for that From domain. Identify which aligned authentication path supplied it.
• SPF is examined separately for the actual smtp.mailfrom domain. Investigate fail, softfail, temperror, or permerror even if aligned DKIM lets DMARC pass.
• Public DNS, Pipedrive’s Authenticated status, and sender-email verification all correspond to the tested configuration.

Under relaxed alignment, domains may share an organizational domain. Strict adkim=s requires an exact DKIM-domain match; strict aspf=s requires an exact envelope-domain match. A return-path subdomain can align with a root-domain From under relaxed SPF alignment but not strict alignment. Do not loosen policy automatically if one path does not align. DMARC alignment rules

Two published DKIM CNAMEs do not mean both signatures must appear in every message. Check the actual selector used. EmailAuth’s guide to finding a DKIM selector from a real message explains how to keep each d=/s= pair and its verification result together.

Diagnose the actual smtp.mailfrom result independently: fail or softfail calls for checking the connecting sender against the approved authorization; temperror is a transient evaluation failure, often DNS; permerror requires checking malformed or duplicate policies and the evaluated lookup budget. An aligned DKIM pass does not repair these SPF faults. Do not change an unrelated apex policy to fix a provider-controlled envelope domain. SPF result definitions.

Troubleshoot Pipedrive authentication

• Domain remains Pending: compare all three exact CNAME owners and targets, authoritative DNS, suffix handling, delegation, proxying, and flattening. Then refresh. Escalate with the domain, timestamps, record names, and error text if correct public answers remain unrecognized.
• Authenticated domain, unusable sender: complete the sender’s email-link verification, confirm it is a company-domain address, and check Campaigns permissions. Domain authentication does not verify every mailbox automatically.
• SPF passes but DMARC fails: compare smtp.mailfrom with the visible From and inspect branded DKIM. Adding an apex include does not change the envelope identity.
• DMARC passes but branded DKIM fails or is absent: do not declare the DKIM setup complete. Verify the selected sender, actual Campaigns route, selector, and key chain. A separate aligned SPF pass can conceal the missing DKIM path.
• DKIM key exists but verification fails: compare the signature’s actual d= and s= with DNS, check key changes, and examine whether a relay modified signed content. Preserve evidence and retest the same route after repair.
• Records conflict with another service: stop before replacing them. Request a supported alternative or coordinated migration; leave unrelated senders and selectors intact.
• Authentication passes but mail reaches spam: examine consent, complaints, recipient rules, reputation, and content. Authentication does not guarantee inbox placement or prove that a message is safe.

Retain a sanitized record of the DNS change, domain status, sender, tested route, and trusted results. Retest after changing the From domain, DNS host, account authentication, or sending path. Keep old selectors until their dependencies and in-flight mail have been considered; remove obsolete delegations through a deliberate offboarding process.