TL;DR

Every cold email domain needs 4 DNS records configured correctly: SPF, DKIM, DMARC, and MX. Missing or misconfigured records are the #1 reason emails land in spam. This checklist walks you through each record with exact syntax, common mistakes, and verification steps. Winnr configures all 4 automatically on every domain.

DNS records are the foundation of email deliverability. They tell receiving mail servers who is authorized to send email from your domain, verify that messages haven't been tampered with, and define what happens when authentication fails. Without properly configured DNS records, even the most compelling cold email in the world will never reach the inbox.

This guide covers all four DNS records you need for cold email -- SPF, DKIM, DMARC, and MX -- with exact syntax, real-world examples, and the most common mistakes that tank deliverability. Whether you're setting up your first cold email domain or auditing an existing one, use this as your definitive checklist.

Why DNS Records Matter for Cold Email

Email service providers (ESPs) like Gmail, Outlook, and Yahoo check authentication records on every single inbound message. These records answer three fundamental questions:

Since February 2024, Gmail and Yahoo require valid SPF, DKIM, and DMARC records for all bulk senders. This isn't optional -- without them, your emails go straight to spam regardless of how good your content is. Microsoft followed suit shortly after, making authentication a universal requirement across all major inbox providers.

Important

Missing DNS records don't just hurt deliverability -- they make your domain a target. Spammers can spoof your domain (send emails pretending to be you) if you don't have SPF and DMARC in place. This can destroy your domain's reputation before you even start sending.

The impact is measurable. Domains with all four records properly configured see inbox placement rates 20-40% higher than domains missing even one record. For cold email, where you have no prior relationship with the recipient, authentication is your only proof of legitimacy.

SPF (Sender Policy Framework)

SPF tells receiving mail servers which IP addresses and mail servers are authorized to send email on behalf of your domain. It's a TXT record added to your domain's DNS.

How SPF Works

When a receiving server gets an email from your domain, it looks up your SPF record and checks whether the sending server's IP address is on the authorized list. If it is, the SPF check passes. If not, it fails -- and the email is more likely to be flagged as spam or rejected entirely.

SPF Record Syntax

A basic SPF record looks like this:

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

Here's what each part means:

SPF Examples for Common Providers

Google Workspace:

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

Microsoft 365:

v=spf1 include:spf.protection.outlook.com ~all

Custom SMTP (with specific IP):

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

Multiple providers:

v=spf1 include:_spf.google.com include:sendgrid.net ~all
Common SPF Mistakes

Multiple SPF records: You can only have ONE SPF record per domain. If you add a second one, both are invalid and all SPF checks will fail. Merge them into a single record instead.

Too many DNS lookups: SPF has a hard limit of 10 DNS lookups. Each include: counts as one (and may trigger nested lookups). Exceeding this limit causes a permanent fail (permerror). Use ip4: or ip6: directives where possible to reduce lookups.

Using +all: Never use +all. This tells receivers that any server is authorized to send email for your domain, completely defeating the purpose of SPF. Use ~all (soft-fail) or -all (hard-fail).

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to every outgoing email that proves the message hasn't been altered in transit. The receiving server verifies the signature against a public key stored in your DNS.

How DKIM Works

When your mail server sends an email, it signs the message headers and body using a private key. The receiving server retrieves your public key from DNS (using the selector and domain in the email's DKIM-Signature header) and verifies the signature. If the signature matches, DKIM passes. If the message was modified in transit, DKIM fails.

DKIM Record Format

DKIM records are TXT records with a specific name format:

selector._domainkey.yourdomain.com

For example, if your selector is google and your domain is example.com, the record name would be:

google._domainkey.example.com

The record value contains your public key:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

Here's what each part means:

Generating DKIM Keys

Most email providers generate DKIM keys for you automatically. If you're using a custom SMTP server, generate a 2048-bit RSA key pair and publish the public key in DNS. Your email server configuration then references the private key for signing.

Key Length Matters

Always use a 2048-bit key minimum. 1024-bit keys are considered weak and some providers will flag them. 4096-bit keys offer stronger security but some DNS providers have TXT record size limits (255 characters per string) that make them harder to publish. 2048-bit is the sweet spot for compatibility and security.

Common DKIM Mistakes

Key too short: Using a 512-bit or 1024-bit key is outdated. Gmail and other major providers recommend 2048-bit minimum. Short keys can be cracked, making your DKIM signature worthless.

Selector mismatch: The selector in your DNS record must exactly match the selector your mail server uses to sign outgoing emails. A typo or mismatch means DKIM always fails, even though the key is valid. Double-check the selector name in both your DNS and your mail server configuration.

Forgetting to rotate keys: DKIM keys should be rotated periodically (every 6-12 months). Old keys increase the risk of compromise. When rotating, publish the new key in DNS first, then update your mail server, then remove the old key after a transition period.

DMARC (Domain-based Message Authentication)

DMARC ties SPF and DKIM together. It tells receiving servers what to do when an email fails authentication and where to send reports about authentication results. Without DMARC, receiving servers make their own decisions about failed emails -- and those decisions are unpredictable.

How DMARC Works

DMARC checks whether the domain in the "From" header aligns with the domain that passed SPF or DKIM. This alignment prevents spammers from passing SPF with their own domain while spoofing yours in the visible "From" address. DMARC then applies the policy you've defined: do nothing, quarantine, or reject.

DMARC Record Syntax

DMARC is published as a TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100

Here's what each part means:

DMARC Policy Options

Policy What Happens When to Use
p=none No action taken on failing emails; reports only Initial monitoring phase -- see what's happening before enforcing
p=quarantine Failing emails sent to spam/junk folder Recommended starting policy for cold email domains
p=reject Failing emails are blocked entirely Maximum protection after confirming all legitimate mail passes

Recommended DMARC Progression

For new cold email domains, we recommend this progression:

  1. Start with p=quarantine -- For dedicated cold email domains where you control all sending, there's no reason to start with p=none. You know exactly which servers send from this domain. Quarantine immediately protects your domain from spoofing while sending any misconfigurations to spam instead of rejecting them outright.
  2. Monitor reports for 2-4 weeks -- Review the aggregate reports sent to your rua address. Look for any legitimate emails failing authentication (this indicates a misconfiguration you need to fix).
  3. Move to p=reject -- Once you've confirmed all legitimate mail passes SPF and DKIM, upgrade to reject. This is the strongest protection and signals to inbox providers that you take authentication seriously.
Don't Stay on p=none Forever

A p=none DMARC policy provides zero protection. It tells receiving servers to take no action on failing emails. While it's fine for a brief monitoring period on domains with complex sending setups, leaving a cold email domain on p=none permanently signals to inbox providers that you don't take authentication seriously. Move to p=quarantine or p=reject as quickly as possible.

MX Records

MX (Mail Exchange) records specify the mail servers responsible for receiving email on behalf of your domain. While MX records don't directly participate in authentication like SPF and DKIM, they're essential for cold email deliverability.

Why MX Records Matter for Cold Email

If your domain can't receive email, spam filters notice. Many inbox providers check whether a sending domain has valid MX records as a basic legitimacy signal. A domain that sends email but can't receive it looks suspicious -- it's a common pattern for throwaway spam domains.

More importantly, you need MX records to receive replies. Cold email only works if prospects can respond. No MX records means no replies, which means no pipeline.

MX Record Format

MX records have a priority and a mail server hostname:

@ MX 10 mail.yourdomain.com

Or for Google Workspace:

@ MX 1 aspmx.l.google.com
@ MX 5 alt1.aspmx.l.google.com
@ MX 5 alt2.aspmx.l.google.com
@ MX 10 alt3.aspmx.l.google.com
@ MX 10 alt4.aspmx.l.google.com

The priority number (lower = higher priority) determines which server to try first. If the primary server is unavailable, email falls through to the next priority level.

Always Set MX Records

Even if you're using a dedicated cold email platform that handles email receiving, make sure your domain's MX records point to a valid mail server. Some platforms configure this automatically; verify it's in place regardless.

How to Verify Your Setup

After configuring your DNS records, verify that everything is working correctly. Don't assume your records are live just because you saved them -- DNS propagation, typos, and provider-specific formatting quirks can all cause issues.

Verification Tools

What a Passing Result Looks Like

Record Passing Status What to Check
SPF Pass Sending IP is included in SPF record; lookup count under 10
DKIM Pass Signature verifies against public key; selector matches
DMARC Pass Policy published; alignment passes (SPF or DKIM domain matches From header)
MX Valid At least one MX record resolves to a reachable mail server

What a Failing Result Looks Like

Common failures and what they mean:

7 Common DNS Mistakes That Kill Deliverability

These are the mistakes we see most frequently on cold email domains. Each one can significantly reduce inbox placement -- and some will prevent delivery entirely.

# Mistake Impact Fix
1 Multiple SPF records on the same domain Both records are invalid; all SPF checks fail permanently Merge into a single SPF record with multiple include: directives
2 Missing DKIM record or wrong selector DKIM always fails; emails look unsigned and unverified Publish the DKIM public key at the correct selector name; verify with MXToolbox
3 DMARC stuck on p=none indefinitely No protection against spoofing; inbox providers see weak authentication posture Progress to p=quarantine within 2-4 weeks, then p=reject
4 No MX records on sending domain Spam filters flag domain as suspicious; replies bounce Add MX records pointing to your email provider's mail servers
5 DNS propagation impatience Start sending before records are live; first emails all fail authentication Wait 24-48 hours after DNS changes; verify with tools before sending
6 Exceeding SPF's 10 DNS lookup limit SPF returns PermError; treated as a hard fail by strict receivers Use ip4:/ip6: directives instead of include: where possible; flatten nested includes
7 DKIM key too short (512 or 1024-bit) Key can be cracked; some providers refuse weak keys entirely Generate and publish a 2048-bit RSA key

How Winnr Handles DNS Automatically

If you're using Winnr for cold email infrastructure, you don't need to configure any of this manually. Winnr automatically sets up all four DNS records -- SPF, DKIM, DMARC, and MX -- on every domain the moment it's added to your account.

Here's what happens when you add a domain to Winnr:

  1. SPF -- Winnr publishes a correctly formatted SPF record authorizing the appropriate sending servers, with no lookup limit issues.
  2. DKIM -- A 2048-bit RSA key pair is generated automatically. The public key is published in DNS with the correct selector. The private key is securely stored for message signing.
  3. DMARC -- Winnr sets a p=quarantine policy by default, with reporting configured to catch any issues early.
  4. MX -- MX records are configured to Winnr's mail servers so your domain can receive replies immediately.

This automatic setup eliminates the most common failure point in cold email: human error in DNS configuration. No typos, no missing records, no lookup limit issues.

Related guides: Learn how to choose the right domains in our domain strategy calculator, understand which TLDs work best for cold email, or read the full cold email best practices guide.

Frequently Asked Questions

How long does DNS propagation take?

Most DNS changes propagate within 1-4 hours, but full global propagation can take up to 48 hours. The actual time depends on your DNS provider, the TTL (Time to Live) value on your existing records, and caching by intermediate resolvers. For new domains with no existing records, propagation is typically faster (under 1 hour). Always verify with a tool like MXToolbox before sending emails -- don't just wait a fixed amount of time and hope.

Can I have multiple DKIM records?

Yes -- unlike SPF, you can have multiple DKIM records on the same domain. Each DKIM record uses a different selector (the prefix before ._domainkey), so they don't conflict. This is common when using multiple email providers: your primary mail server might use the selector google, while a transactional email service uses sendgrid. Each provider signs with its own private key, and receiving servers look up the correct public key based on the selector in the email's DKIM-Signature header.

What DMARC policy should I start with?

For dedicated cold email domains, start with p=quarantine. Since you control exactly which servers send from these domains, there's no need for an extended p=none monitoring period. Quarantine protects your domain from spoofing immediately while routing any misconfigured emails to spam (instead of rejecting them) so you can catch issues. After 2-4 weeks of clean reports, move to p=reject for maximum protection.

Do I need a reverse DNS (PTR) record?

A PTR (reverse DNS) record maps an IP address back to a hostname. While not strictly required for cold email, many spam filters check for a valid PTR record on the sending IP. If you're using a dedicated email infrastructure provider like Winnr, PTR records are already configured on the sending servers. If you're running your own SMTP server, contact your hosting provider to set up a PTR record that matches your server's hostname. A missing PTR record won't necessarily block delivery, but it adds a negative signal that compounds with other issues.