SPF, DKIM, and DMARC for Cold Email

SPF, DKIM, and DMARC are DNS records that tell receiving mail servers whether an email sent from your domain is legitimate. Together they form the authentication layer that inbox providers use to evaluate whether your mail should be delivered, filtered, or rejected outright.

Without all three configured correctly on every sending domain, you're asking inbox providers to trust mail from a domain that hasn't proven it deserves to be trusted. At best, your emails land in spam. At worst, they don't land at all.

These records belong on your sending domains — the domains your cold email actually comes from. Your primary business domain has its own DNS configuration that's separate from your outbound infrastructure.

SPF is a DNS record that specifies which mail servers are authorized to send email on behalf of your domain. When an email arrives at a receiving server, that server checks the sending domain's SPF record to confirm the mail came from an authorized source.

If the sending server isn't listed in the SPF record, the check fails. A failed SPF check doesn't automatically mean your email gets rejected — that depends on your DMARC policy — but it's a negative signal that inbox providers factor into their filtering decisions.

The practical thing to understand about SPF is that it's tied to the infrastructure doing the sending. When you add a domain to a sending platform like Instantly or Smartlead, that platform will specify what your SPF record needs to include to authorize their servers. Follow their setup instructions and the record is correct. The common mistake is either skipping it entirely or having multiple conflicting SPF records on the same domain, which causes failures even when the sending server is legitimate.

One important technical constraint: SPF has a 10 DNS lookup limit. If your record references too many include statements that chain into additional lookups, it exceeds this limit and starts failing. This is a more common problem than most people realize, especially when a domain has been used across multiple platforms over time.

DKIM works differently from SPF. Instead of verifying where an email came from, it verifies that the email wasn't tampered with in transit.

When you send an email, your sending server attaches a cryptographic signature to the message. That signature is generated using a private key that only your sending infrastructure holds. The corresponding public key is published as a DNS record on your sending domain. When the email arrives at its destination, the receiving server looks up your public key and uses it to verify the signature. If the signature checks out, the message is confirmed to be intact and unaltered.

For cold email, DKIM matters because it's one of the stronger trust signals inbox providers use. A valid DKIM signature tells Gmail, Outlook, and other providers that your mail is coming from a consistent, authenticated source — not a spoofed or hijacked domain.

Like SPF, your sending platform will provide the DKIM record you need to add to your domain's DNS when you set up a new sending domain. It typically looks like a TXT record with a long string of characters. Add it exactly as specified and verify it's resolving correctly before you start sending.

DMARC is the policy layer that sits on top of SPF and DKIM. It tells receiving mail servers what to do when an email fails one or both of those checks — and it gives you visibility into what's happening with your domain's mail.

A DMARC record has three possible policy settings:

p=none — monitor only. Emails that fail SPF or DKIM checks are delivered as normal, but reports are generated so you can see what's happening. This is the starting point for most sending domains — it gives you visibility without risking legitimate mail being blocked while you're still getting your authentication dialed in.

p=quarantine — emails that fail authentication go to the spam folder rather than the inbox. This is a stricter stance that makes sense once you're confident your SPF and DKIM are correctly configured and you're not seeing legitimate mail failing checks.

p=reject — emails that fail authentication are rejected outright and don't get delivered at all. This is the most protective policy for your domain's reputation, but it's unforgiving if your authentication isn't perfectly configured. Any legitimate mail that fails a check for any reason simply doesn't get delivered.

DMARC also introduces the concept of alignment — the domain in your From address needs to align with the domain that passes SPF or DKIM. This is what closes the gap that SPF and DKIM alone leave open, where a bad actor could use authenticated infrastructure to send mail that appears to come from your domain.

For reporting, DMARC allows you to specify an email address to receive aggregate reports from receiving mail servers. These reports show you which sources are sending mail claiming to be from your domain, and whether those sends are passing or failing authentication. It's useful visibility, especially when you're managing a large number of sending domains.

Each record addresses a different part of the authentication problem. SPF verifies the sending server. DKIM verifies the message integrity. DMARC sets the policy for failures and ties the two together with alignment enforcement.

Missing any one of them leaves a gap. SPF without DKIM means your messages aren't cryptographically verified. DKIM without SPF means your authorized senders aren't explicitly declared. Either without DMARC means there's no policy governing what happens when checks fail, and no reporting to tell you when something is wrong.

Inbox providers — particularly Google and Microsoft — have gotten progressively stricter about authentication requirements. As of 2024, Google and Yahoo both require SPF, DKIM, and DMARC to be present for bulk senders. This isn't a best practice anymore. It's a baseline requirement.

If you're setting up sending domains yourself, every domain needs all three records configured before you start warming up or sending. Your sending platform will provide the specific record values — follow their setup documentation exactly, then verify each record is resolving correctly using a DNS lookup tool before you do anything else.

The only domain where you need to configure these records independently — outside of any sending platform's setup flow — is your primary business domain. That domain isn't used for cold email, but it should still have SPF, DKIM, and DMARC configured to protect it from spoofing and to maintain its own sending reputation for transactional and business mail.

If your cold email infrastructure is fully managed, DNS configuration including SPF, DKIM, and DMARC is handled for you on every sending domain as part of setup.

If you want to verify that your authentication records are correctly configured and resolving as expected, InfraSuite's free Domain Health Check tool checks your SPF, DKIM, and DMARC setup and flags anything that needs attention. Worth running on every new sending domain before you start warming up.

The only thing left to you is your primary domain.

SPF, DKIM, and DMARC are not optional. They're the authentication foundation that every sending domain needs before a single email goes out. Get them right once per domain and they run silently in the background for the life of that domain. Get them wrong and you're fighting deliverability problems that have nothing to do with your copy, your list, or your offer.