SPF, DKIM and DMARC for cold email: a setup guide
Updated November 2026 · 7 min read
If your cold emails land in spam, missing or broken email authentication is the first thing to check. SPF, DKIM and DMARC are three DNS records that prove your emails really come from your domain. This guide explains what each one does, shows example records, and lists the mistakes that most often break them.
Why authentication matters for cold email
Inbox providers decide where your email goes partly by checking whether your domain vouches for it. Without authentication, a message from your domain looks the same as a forged one, so it is far more likely to be filtered or rejected.
Since February 2024, Gmail and Yahoo require every sender to authenticate. Anyone sending more than about 5,000 messages a day to Gmail must have SPF, DKIM and DMARC in place, with the From domain aligned to SPF or DKIM. Cold email rarely reaches that volume from one domain, but the same records are the baseline for good deliverability at any volume.
SPF: list who may send for your domain
SPF (Sender Policy Framework) is a TXT record on your domain that lists the servers allowed to send email for it. Receiving servers compare the sending server against that list.
Type: TXT
Host: @
Value: v=spf1 include:_spf.google.com ~all- Have exactly one SPF record per domain. Two records starting with v=spf1 make SPF fail.
- Add one include for each service that sends as your domain, such as your mailbox provider and any SMTP relay.
- SPF allows at most 10 DNS lookups. Each include counts, so remove services you no longer use.
- End with ~all (soft fail) or -all (hard fail). A record of just v=spf1 -all says no server may send, so nothing from that domain passes.
DKIM: sign every email
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each email. Your mailbox provider signs with a private key, and you publish the matching public key in DNS so receivers can verify the message wasn't changed and really came from your domain.
You generate the key in your email provider's admin console, then publish it as a TXT record at selector._domainkey on your domain. The selector is a name your provider chooses; Google Workspace uses google by default.
Type: TXT
Host: google._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...- Use a 2048-bit key where your provider offers it.
- After publishing the record, turn signing on in your provider's console. Publishing the key alone doesn't sign anything.
- If you send through more than one service, each needs its own DKIM key and selector.
DMARC: tell receivers what to do when checks fail
DMARC ties SPF and DKIM to the address people see in the From line. It passes when SPF or DKIM passes for a domain that matches (aligns with) the From domain, and it tells receivers what to do with messages that fail: nothing, quarantine them, or reject them.
Type: TXT
Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com- Start with p=none to collect reports without affecting delivery, then move to p=quarantine and p=reject once every legitimate sender passes.
- The rua address receives daily aggregate reports from inbox providers.
- A subdomain without its own DMARC record falls back to the parent domain's policy, so check the root domain too.
Don't forget MX
An MX record says where your domain receives email. A sending domain with no MX record can't receive replies or bounce notices, and it looks less like a real business domain to filters. Point it at your mailbox provider, the same way as your main domain.
Use separate domains for cold email
Common practice is to send cold email from secondary domains that look like your brand (for example trybrand.com alongside brand.com) and keep your main domain for everyday mail. If a cold campaign hurts a domain's reputation, your invoices and support emails are unaffected. Each secondary domain needs its own SPF, DKIM, DMARC and MX records.
Common mistakes
- Two SPF records on the same domain, usually left behind after switching providers.
- A DKIM key published but signing never switched on in the provider's console.
- DMARC published on a subdomain but not the root domain, or the other way round, with a different policy than intended.
- A tracking or sending service added to SPF but sending from a domain that doesn't align with the From address.
- Forgetting the records on new sending domains bought later.
How to check your records
After any change, wait for DNS to update (often minutes, sometimes up to a day), then look the records up again. Send a test to a Gmail address and open Show original: it lists the SPF, DKIM and DMARC result for that message.
Polimatiq checks SPF, DKIM, DMARC and MX for every sending domain you add, using real DNS lookups with your DKIM selector, and re-checks each domain daily so a broken record doesn't go unnoticed.
Frequently asked questions
- Do I need SPF, DKIM and DMARC for cold email?
- Yes. Gmail and Yahoo require authentication from every sender, and SPF, DKIM and DMARC together are the baseline inbox providers expect. Missing records are one of the most common reasons cold emails land in spam.
- Should DMARC be p=none or p=reject?
- Start with p=none so nothing is blocked while you confirm every legitimate sender passes, using the aggregate reports. Then move to p=quarantine and eventually p=reject.
- Can I have two SPF records?
- No. A domain must have a single SPF record. Combine every service into one record with several include entries; two separate v=spf1 records cause SPF to fail.
- How long does DNS take to update?
- Often a few minutes, but it can take up to a day or two depending on your DNS provider and the record's TTL. Check again before you start sending.
Run your cold email from one workspace
Mailboxes, warmup, deliverability checks, sequences, replies, CRM and analytics, with every feature on every plan.