If you send cold outreach at scale, your deliverability is part copywriting and part infrastructure. DKIM, SPF, and DMARC are foundational email authentication standards that help mailbox providers trust your domain and reduce the chance your emails land in spam (or get rejected). This guide teaches what these protocols do, how to think about them strategically, and how to apply them safely, without breaking other tools that also send email from your domain.

Important: DKIM/SPF/DMARC live in your domain’s DNS settings (GoDaddy, Namecheap, Cloudflare, Squarespace, etc.). lemlist doesn’t host these records, but strong authentication directly improves results when running campaigns.

DKIM adds a cryptographic signature to outbound email. Receiving servers can verify the signature to confirm the message wasn’t altered and that it was authorized by the domain.

What this means for outreach: DKIM helps mailbox providers trust that your emails are legitimately associated with your domain, especially important when you’re sending sequences and follow-ups.

SPF is a list of authorized senders for your domain. It tells receiving servers which IPs/services are allowed to send mail “on behalf of” your domain.

What this means for outreach: SPF reduces spoofing risk and can improve acceptance rates. However, SPF is easy to misconfigure because you can only have one SPF record per domain (you often need to merge includes for multiple services).

DMARC ties SPF and DKIM together and publishes a policy for what receivers should do when authentication fails (deliver, quarantine, reject). It can also send reports so you can monitor who is sending mail as your domain.

What this means for outreach: DMARC is your “enforcement + visibility” layer. It helps protect your domain from spoofing and supports consistent trust signals across mailbox providers.

Mailbox providers optimize for user safety and inbox experience. If your domain lacks authentication (or has conflicting records), your emails are more likely to be filtered, throttled, or rejected—even if your copy is strong.

Without DMARC/SPF/DKIM, your domain is also easier to spoof, which can damage your reputation and reduce deliverability over time. For outbound teams, authentication is a non-negotiable baseline: it protects the brand, stabilizes inbox placement, and makes results more predictable.

Principle 1: Deliverability is risk management, not a hack.

Authentication standards exist to reduce fraud and abuse. When you align with them, you’re signaling “legitimate sender,” which improves consistency more than any short-term trick.

Principle 2: Your DNS is a shared system.

Your domain often sends mail from multiple tools (Google/Microsoft, website forms, support desk, CRM). Changes to SPF/DKIM/DMARC must account for the whole stack, not just lemlist.

Principle 3: Start conservative, then enforce.

For many teams, the safest DMARC journey is: p=none (monitor) → p=quarantine (partial enforcement) → p=reject (strong enforcement), once you’re sure all legitimate senders pass.

Principle 4: One SPF record, many includes.

The most common SPF mistake is creating a second SPF TXT record. Instead, you merge all required senders into a single record.

When to use: Before you add/modify SPF, DKIM, or DMARC.

How it works: List every system that sends email using your domain (Google/Microsoft, helpdesk, CRM, marketing, transactional email, web host). Then confirm which ones require SPF includes and/or DKIM selectors.

Why it works: Most authentication outages happen because a “forgotten sender” starts failing after a DNS change. A quick audit prevents deliverability drops and broken business workflows.

Example checklist: Google Workspace / Microsoft 365, lemlist sending inboxes, HubSpot/Salesforce, Zendesk/Intercom, SendGrid/Mailgun/Amazon SES, website form notifications, invoices/billing tool.

When to use: If you already have an SPF record and want to add a new sender (like Google or another platform).

How it works: You keep a single SPF record and add additional include: mechanisms for each sender.

Why it works: Creating multiple SPF records or deleting an existing one can cause legitimate mail to fail authentication and hurt inbox placement.

Real example: If you already have:

And you also need Google as your provider, you’d update to:

When to use: If you’re not 100% sure all senders are correctly authenticated yet.

How it works: Start with a DMARC record that monitors (collects reports), then tighten policy after you confirm DKIM/SPF alignment for legitimate mail sources.

Why it works: DMARC enforcement without readiness can cause legitimate mail to be quarantined/rejected. A phased rollout reduces business risk while you improve security.

Real example (monitoring baseline):

What’s happening: The domain may now have two SPF records, or a previous sender was removed when SPF was replaced.

How to respond: Ensure there is only one SPF TXT record and that it includes every legitimate sending service. If you’re unsure which services need to be included, involve IT—SPF changes can impact invoices, password resets, and support emails.

Practical script to your IT/admin: “Can you confirm we have a single SPF record and that it includes Google/Microsoft plus all tools that send as our domain (CRM, support desk, transactional email)?”

What’s happening: One or more senders is failing SPF/DKIM alignment, so DMARC enforcement is blocking or filtering those messages.

How to respond: Identify the failing sender and fix its SPF include and/or DKIM configuration. If needed, temporarily reduce policy to p=none while you remediate—then re-enforce once everything passes.

What’s happening: Provider changes often require new DKIM keys/selectors and SPF includes. Old records can remain and cause confusion.

How to respond: Re-audit senders, publish the new provider’s DKIM and SPF requirements, and verify DMARC alignment before enforcing strict DMARC policies.

Mistake 1: Creating multiple SPF records.

Why it backfires: Receivers may treat SPF as invalid, causing authentication failures.

Do this instead: Maintain one SPF record and merge all required includes.

Mistake 2: Copy/pasting DNS values without checking your provider.

Why it backfires: SPF/DKIM values depend on your email service (Google, Microsoft, etc.) and sometimes your configuration.

Do this instead: Use your provider’s official documentation for the exact values.

Mistake 3: Turning on strict DMARC (reject) before validating all senders.

Why it backfires: Legitimate mail can get rejected, impacting operations and customer communications.

Do this instead: Phase DMARC enforcement after monitoring and alignment checks.

Exercise 1: Build your “Sender Inventory.”

Create a list of every platform that sends email using your domain. Next to each, note whether it requires SPF, DKIM, or both. This becomes your go-to reference whenever you add a new tool.

Exercise 2: Run a quarterly authentication review.

Once per quarter, confirm your SPF is still a single record, DKIM is enabled for your primary provider, and DMARC policy matches your risk tolerance. This prevents “quiet” deliverability decay.

Exercise 3: Plan a DMARC enforcement roadmap.

Write down when you’ll move from p=none to p=quarantine and eventually p=reject, plus what evidence you need (e.g., confirmation from IT, clean DMARC reports, verified senders list).

Even with great targeting and copy, weak authentication can cap results. When your domain authentication is correctly configured, lemlist campaigns benefit from more stable inbox placement, fewer bounces caused by trust issues, and more reliable performance when scaling sending volume.

If you’re coordinating DNS changes with an admin/IT teammate, share this article so they understand the outreach deliverability impact and the “one SPF record” rule.

Inbox placement stability: Fewer sudden drops in replies when volume increases or when you add new inboxes.

Bounce reasons: A reduction in authentication-related bounces/rejections (your provider or bounce logs may indicate policy/auth failures).

DMARC visibility: DMARC reports (rua) show fewer unknown senders and higher pass/alignment rates over time.

Example 1: The “two SPF records” deliverability dip

A team added a new TXT record for SPF instead of editing the existing one. Some receivers treated SPF as invalid, and reply rates dropped while bounces increased. Fixing it required removing the duplicate and merging includes into a single SPF record. Deliverability stabilized within the DNS propagation window.

Example 2: DMARC quarantine exposed an untracked sender

A company enabled DMARC quarantine to reduce spoofing, then noticed support emails were landing in spam for some recipients. DMARC reports showed the helpdesk tool wasn’t aligned with DKIM/SPF. After updating the tool’s sending configuration and confirming alignment, they kept quarantine enabled without impacting legitimate mail.

DKIM: “Is the message signed and verifiable?”

SPF: “Is this sender allowed to send for this domain?” (One SPF record only.)

DMARC: “If SPF/DKIM fail or don’t align, what should receivers do—and where do reports go?”

Safe rollout order: DKIM + SPF → DMARC p=none (monitor) → DMARC p=quarantine → DMARC p=reject (when ready)

If your domain is frequently spoofed or brand risk is high, moving toward p=reject can significantly reduce impersonation attempts. However, do this only after you’ve confirmed every legitimate sender is aligned; otherwise, you may block important business email.

Because DNS values vary by provider, use the official documentation for your email service:

DKIM (Google Workspace): https://support.google.com/a/answer/180504?hl=en

SPF (Google Workspace): https://support.google.com/a/answer/10685031?hl=en

DMARC (Google Workspace): https://support.google.com/a/answer/2466563?hl=en