If your cold emails are landing in spam, the first thing to check isn’t your subject line. It’s your DNS. Three records — SPF, DMARC, and MX — are the baseline authentication layer that receiving mail servers use to decide whether to trust your domain before they even read the content.
Get them wrong and you’re flagged as a potential spammer at the infrastructure level. Get them right and you’re working from a foundation that Gmail, Outlook, and Yahoo actually respect.
SPF: Telling Receiving Servers Which IP Addresses Can Send as You
SPF (Sender Policy Framework) is a TXT record in your DNS that lists the IP addresses and services authorised to send email from your domain. When a receiving server gets an email claiming to be from outreach@yourdomain.com, it checks your SPF record to see if the sending server is on the authorised list.
What a correct SPF record looks like:
v=spf1 include:_spf.google.com include:sendgrid.net ~allBreaking this down:
v=spf1— declares this is an SPF recordinclude:_spf.google.com— authorises Google Workspace to send on your behalfinclude:sendgrid.net— authorises SendGrid (or your sending tool’s SMTP relay)~all— soft fail for anything not on the list (use-allfor a hard fail once you’re confident)
Common mistakes:
- Having more than one SPF record. DNS allows only one. Merge all
include:directives into a single record. - Exceeding 10 DNS lookups. Each
include:counts toward the limit. Use tools like MXToolbox to audit your lookup count. - Using
+allwhich authorises any server — effectively disabling SPF protection.
DMARC: Telling Receiving Servers What to Do When SPF or DKIM Fails
DMARC (Domain-based Message Authentication, Reporting & Conformance) sits on top of SPF and DKIM. It tells receiving servers what policy to apply when an email fails authentication checks, and where to send forensic reports.
A production-ready DMARC record:
v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@yourdomain.comp=quarantine— emails failing DMARC go to spam rather than being rejected outrightp=reject— emails failing DMARC are rejected entirely (the strictest setting, use after validating)pct=100— apply the policy to 100% of messages (start atpct=10if you’re cautious)rua=— aggregate report recipient; you’ll receive daily digests of authentication results
Starting out: Use p=none first. This is monitoring mode — it doesn’t affect deliverability but you start receiving reports so you can understand your sending landscape before enforcing a policy.
The progression: p=none → validate your reports for 2–4 weeks → p=quarantine; pct=10 → ramp to pct=100 → eventually p=reject once you’re confident nothing legitimate is being flagged.
Google and Yahoo now require DMARC (p=none at minimum) for bulk senders — so this isn’t optional.
MX Records: The Return Address Your Domain Needs
MX (Mail Exchanger) records define which servers handle inbound mail for your domain. You might think “I’m only sending, not receiving” — but MX records matter for cold email for two reasons:
- Receiving servers check that your domain has valid MX records. A domain with no MX records looks abandoned or throwaway, which is a spam signal.
- Reply tracking requires a valid inbox. When a prospect replies, their mail server routes the reply to wherever your MX points. Without MX records, replies fail silently.
For Google Workspace, your MX records should be:
| Priority | Mail server |
|---|---|
| 1 | ASPMX.L.GOOGLE.COM |
| 5 | ALT1.ASPMX.L.GOOGLE.COM |
| 5 | ALT2.ASPMX.L.GOOGLE.COM |
| 10 | ALT3.ASPMX.L.GOOGLE.COM |
| 10 | ALT4.ASPMX.L.GOOGLE.COM |
If you’re using a dedicated sending subdomain (e.g., outreach.yourdomain.com), set at least one MX record pointing back to your main domain’s mail server so replies have somewhere to land.
DKIM: The Digital Signature That Completes the Picture
DKIM (DomainKeys Identified Mail) isn’t a DNS record you configure manually — it’s generated by your email provider. Google Workspace, for example, generates a DKIM key pair and gives you the public key to add as a TXT record in your DNS.
When you enable DKIM in Google Admin, you’ll see something like:
google._domainkey.yourdomain.com → v=DKIM1; k=rsa; p=MIIBIjANBgkq...The sending server signs each outgoing email with the private key. The receiving server looks up your DNS to get the public key and verifies the signature. If it matches, the email hasn’t been tampered with in transit.
Enabling DKIM in Google Workspace: Admin Console → Apps → Google Workspace → Gmail → Authenticate email → Generate new record → Add to DNS → Start authentication.
The Sending Checklist Before Any Campaign
Before a sending identity goes live on CarcMail, all three of these pass automatically:
- SPF record present and includes your sending service
- DMARC record present with at least
p=none - MX records configured with valid mail servers
- DKIM enabled and verified in your sending provider
- Domain age > 30 days (fresh domains always need a warmup period)
Tools to verify: MXToolbox, Google Admin Toolbox, DMARC Analyser.
Why Getting This Right Matters More Than Copy
The most personalized, perfectly-timed cold email gets zero chance if it’s rejected at the infrastructure layer before a human ever reads it. DNS authentication is unsexy but it’s the highest-leverage deliverability work you can do — and it costs nothing but time to configure correctly.
Configure SPF, DMARC, and MX. Enable DKIM. Verify with a third-party tool. Then worry about subject lines.