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: Always set DMARC to at least quarantine — never “none.”

Many teams set DMARC to p=none just to “have DMARC” without understanding how DMARC enforcement works. In practice, many anti-spam systems treat p=none the same as having no DMARC at all—because you’re effectively telling receivers “do nothing.”

A safer baseline is to set DMARC to p=quarantine, so receivers get a clear instruction when authentication/alignment fails.

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: When you’re setting up DMARC for outreach deliverability and basic domain protection.

How it works: Publish a DMARC record with p=quarantine so receiving servers have instructions to hold and re-evaluate mail that fails authentication/alignment.

Why it works: Many anti-spam systems treat p=none similarly to having no DMARC policy—because “do nothing” is essentially the same as not publishing a policy.

Quarantine vs. reject — what they do:

Quarantine = tells the receiving server: keep the message and re-analyze it later (it may still be accepted after additional checks).

Reject = tells the receiving server: send it back to the sender, and the sender decides what to do with it.

In both cases, the email does not reach the lead’s inbox, so on paper there is no difference in score impact.

Real example (recommended baseline):

When to use reject: Use p=reject only when you have a postmaster (or a postmaster tool/workflow) actively handling incoming DMARC reports.

When you publish DMARC, you can define where aggregate reports should be sent (for example: rua=mailto:[email protected]).

If you choose p=reject, expect more “actionable” reporting pressure: you need to monitor reports to catch legitimate senders that are failing alignment, otherwise you can unintentionally block real business mail.

DMARC reports are very complex: they typically arrive as XML files inside archive attachments, and they’re difficult to use on their own without a postmaster tool.

If you don’t want to manage/postmaster your DMARC reports, don’t use reject—you can quickly get overwhelmed with report emails.

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 you need a short-term safety valve while you remediate, reduce strictness from p=reject to p=quarantine—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: Using DMARC “none” as a long-term setup.

Why it backfires: Many systems treat p=none like having no DMARC policy at all—because it effectively tells receivers to do nothing when authentication/alignment fails.

Do this instead: Always set DMARC to at least p=quarantine. Use p=reject only when you have a postmaster (or tooling/workflow) in place to handle DMARC reporting.

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.

Decide whether your steady-state DMARC policy will be p=quarantine or p=reject. If you plan to use p=reject, document who will manage DMARC reporting (postmaster/tooling) and what “healthy” looks like (clean DMARC reports, verified senders list, IT confirmation).

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?”

Core recommendation: Always set DMARC to at least p=quarantine—never p=none.

Safe rollout order: DKIM + SPF → DMARC p=quarantine → DMARC p=reject (only if you have postmaster/report-handling in place)

Moving toward p=reject can significantly reduce impersonation attempts, but it’s appropriate only when you have someone (or a tool/workflow) actively handling DMARC reporting.

DMARC reports can be frequent and complex (often XML inside archive files). If you don’t want to manage/postmaster those reports, stick with p=quarantine instead of moving to reject.

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