Deliverability

SPF, DKIM, and DMARC for Cold Email

How to set up SPF, DKIM, and DMARC on a dedicated cold email domain: record shapes, alignment, the DNS mistakes that break setups, and how to verify.

by the Sendful team

The major mailbox providers now check three DNS records before deciding what to do with your mail. Get SPF, DKIM, and DMARC right and a new outreach domain starts with a clean slate it can build on. Get them wrong and nothing downstream gets a chance to matter, because warmup, copy, and targeting all happen behind a door that never opened. This guide explains what each protocol actually does, how to set each one up on a dedicated outreach domain, the mistakes that quietly break setups, and how to verify everything before the first send.

What each protocol actually does

SPF is a TXT record on your domain that lists the servers allowed to send mail on its behalf. When your message arrives, the receiving server looks at the IP that delivered it, fetches your SPF record, and checks whether that IP is on the list. One detail trips people up: SPF is evaluated against the return-path domain, the hidden address bounces go to, not the From address your prospect sees. That distinction is why alignment, covered below, exists.

DKIM is a cryptographic signature. Your sending server signs selected headers and the body with a private key, and receivers fetch the matching public key from your DNS to verify two things: the message was not altered in transit, and it was signed by someone who controls the domain’s DNS. The signature names a signing domain, and that domain is what DMARC later checks.

DMARC sits on top of both. It is a policy record that tells receivers what to do when authentication fails, and it adds the alignment requirement: SPF or DKIM must not only pass, the domain that passed must match the visible From domain. Without alignment, anyone passing SPF on their own domain could put yours in the From line. DMARC closes that hole, which is also why it is your main defense against email spoofing. It also sends you aggregate reports showing who is sending as your domain and whether they pass.

Why Google and Yahoo made this mandatory

Since early 2024, Google and Yahoo have published bulk sender requirements rather than suggestions. Google’s guidance applies to senders at roughly 5,000 messages a day to personal Gmail accounts, but the practical bar is lower: unauthenticated mail to either provider is increasingly rejected or junked at any volume. Their published requirements include SPF and DKIM authentication, a DMARC policy on the From domain, one-click unsubscribe, and keeping spam complaints under their stated 0.3 percent threshold.

For cold email this matters twice over. First, B2B prospect lists tend to be heavily concentrated on Google Workspace and Microsoft 365, so the strictest filters are exactly where your mail goes. Second, a real outbound program runs across several domains, and every one of them needs the full setup. There is no domain that gets to skip it.

SPF: one record, and watch the lookup limit

On a dedicated sending domain, the SPF record is short because the domain should only ever send through one provider. For Google Workspace it looks like this, published as a TXT record at the domain root:

v=spf1 include:_spf.google.com ~all

Two mistakes break SPF constantly:

  • Multiple SPF records. A domain may publish exactly one record starting with v=spf1. Two records is a permanent error, which evaluates as a failure. If you ever need to authorize a second sender, merge its include into the single existing record instead of adding a new one.
  • The 10 DNS lookup limit. The SPF specification caps evaluation at ten DNS lookups, and every include, a, mx, and redirect in the record counts, including the lookups nested inside each include. Exceeding ten is another permanent error. Fresh outreach domains rarely hit this on their own. They hit it when someone copies the company’s primary domain record, with every tool the business ever connected, onto the new domain. Do not do that. The outreach domain authorizes its email provider and nothing else.

End the record with ~all (softfail) or -all (fail). Either is reasonable once DKIM and DMARC are in place. +all, which authorizes the entire internet, is the one ending that should never appear.

DKIM: sign with your own domain, not your provider’s

Your email provider generates the DKIM key pair. In Google Workspace you generate the key in the Admin console, publish the public key as a TXT record at selector._domainkey.yourdomain.com, and then turn signing on. Choose a 2048-bit key where the provider supports it.

The usual mistakes:

  • Relying on the provider’s default signature. Many platforms sign mail with their own domain out of the box, so DKIM technically passes but on their domain, not yours. That signature will never align with your From address, so it does nothing for your DMARC. Set up the custom key so the signing domain is your sending domain.
  • A truncated key in DNS. 2048-bit public keys are long, and some DNS dashboards split or silently trim long TXT values. If DKIM fails after setup, compare the published record character by character against what the provider gave you.
  • Publishing the record but never enabling signing. The DNS record alone does nothing. The provider has a switch, and someone has to flip it.

DMARC: start at none, tighten on evidence

The DMARC record lives at _dmarc.yourdomain.com. On a fresh outreach domain, start here:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

p=none satisfies Google and Yahoo’s minimum requirement, changes nothing about delivery, and starts the flow of aggregate reports. While email warmup runs, those reports tell you whether your real mail is passing SPF and DKIM with alignment, and whether anything unexpected is sending as your domain.

Once you have a few weeks of reports showing clean, aligned passes and nothing legitimate failing, tighten to p=quarantine, and later to p=reject. A dedicated outreach domain has exactly one mail stream, so you can usually reach quarantine much faster than a corporate domain with years of accumulated tools could. The stricter policies do two things for you: they tell receivers you run a serious domain, and they make it much harder for third parties to spend your domain reputation by forging your From address.

Do not start a brand new domain at reject before you have report data. If alignment is subtly broken, a reject policy turns a misconfiguration into mail that silently disappears.

Verify before the first send

Authentication failures do not announce themselves. The mail still leaves your outbox; it just dies quietly on arrival. Verify the whole chain before any campaign:

  1. Check the DNS directly. Use dig or any DNS lookup tool to confirm all three records resolve, that there is exactly one SPF record, and that nothing is truncated.
  2. Send a real test to a Gmail address you control. Open the message, choose “Show original”, and confirm three lines: spf=pass, dkim=pass, dmarc=pass. Gmail shows this on every message, and it reflects what filters actually evaluated rather than what your sending tool claims.
  3. Check the signing domain. In the same view, confirm the DKIM d= value is your sending domain, not your provider’s. This is the alignment check most people skip.
  4. Register the domain in Google Postmaster Tools. Data appears only after volume builds, but you want the account watching from day one.

Only after all of that passes does warmup start, and only after warmup do campaigns. Authentication is the floor, not the finish line.

If you would rather not own DNS records

Everything above is learnable, and if you run outbound in-house, learn it. It is also the kind of work where one quiet mistake costs weeks, because a misaligned DKIM signature or a duplicate SPF record does not error out. It just drags your reply rate toward zero while you look for the problem in your copy.

This is part of what Sendful handles as standard. We stand up dedicated sending domains for every client, never send from your primary domain, and run the full authentication, warmup, and monitoring stack, with infrastructure typically warming and live within 2 weeks of kickoff. If you want a second set of eyes on your setup either way, book a call. You will leave with a free custom outbound plan whether or not we end up working together.

Terms used in this guide

Book a call

Rather have all of this handled?

Book a call and leave with a custom outbound plan, your ICP, opening sequences, and a deliverability check, whether or not we work together.