How ColdRelay Auto-Configures SPF, DKIM, and DMARC for Cold Email

If you've ever set up cold email manually, you know the SPF/DKIM/DMARC dance: edit a DNS zone, paste a TXT record, wait for propagation, run mxtoolbox, realize the SPF includes the wrong sender, fix it, re-paste, wait again.

ColdRelay writes all three records for every domain automatically. Five minutes after your first mailbox provisions, your DNS is signed, aligned, and ready to send. No console. No copy-paste. No DKIM rotation worries.

This article is for two readers: (1) prospective ColdRelay customers who want to know exactly what we configure on their behalf, and (2) anyone running cold email who wants the canonical reference for what SPF/DKIM/DMARC should look like on a dedicated cold-email-infrastructure setup in 2026.

The 30-second answer

Every ColdRelay domain ships with these three records:

Record	What it is	What ColdRelay writes
SPF	Lists which servers are authorized to send mail for your domain	A single `v=spf1` TXT including the Azure Communication Services sending IPs we operate on your dedicated tenant, plus `-all` (hard fail for anything else)
DKIM	Cryptographic signature on every outbound message	A 2048-bit RSA key, published as `default._domainkey.<your-domain>` — we sign every message at the SMTP layer
DMARC	Policy that tells inbox providers what to do when SPF or DKIM fails	`v=DMARC1; p=quarantine; rua=mailto:dmarc@<your-domain>; pct=100` — quarantine on fail, 100% enforcement, aggregate reports to you

Three records. Configured once at provisioning. Rotated automatically as needed. The records take effect within minutes of your first mailbox batch landing, not the 24–48 hours you'd wait on a manual DNS provider.

Why these three records matter for cold email specifically

Cold email's deliverability ceiling isn't your copy. It's your authentication signal. Gmail, Outlook, and Yahoo's spam classifiers run authentication checks before they look at message content. A domain without SPF goes to spam by default at Gmail. A domain without DKIM gets flagged at Outlook. A domain without DMARC gets treated as suspicious-by-omission at every major inbox.

If you're sending cold to 5,000 contacts a day across 100 mailboxes, authentication is the difference between 95% inbox placement and 30%. That's not a marginal change. That's the difference between cold email working and cold email not working.

The three records together prove three different things to receiving servers:

SPF proves origin — "this IP is authorized to send for this domain"
DKIM proves integrity — "this message hasn't been altered in transit, and we cryptographically signed it"
DMARC proves alignment — "we as the domain owner have a published policy about what happens when SPF or DKIM fails"

The receiving mail server runs all three checks. A pass on all three is the difference between "primary inbox" and "spam folder" — every single send.

What ColdRelay writes — in detail

SPF: hard-failed, narrow include

Your SPF record looks roughly like this (with your dedicated Azure tenant's IP):

v=spf1 ip4:20.x.x.x include:_spf.coldrelay-infra.com -all

Three things to call out:

1. The IP is dedicated to your account. ColdRelay runs an isolated Azure Communication Services tenant per customer — your sending IP isn't shared with anyone else's outbound. The ip4: entry hard-codes that IP into your SPF record, so receivers can verify origin against the exact server.

2. The include is one DNS lookup. SPF has a hard limit of 10 DNS lookups per record evaluation — exceed it and the record fails entirely. We keep the lookup count low (typically 2) so your SPF survives even if you add downstream services later. If you've ever debugged "SPF PermError" on a shared sender, this is the failure mode.

3. The mechanism is -all, not ~all or ?all. Hard-fail means receivers reject mail from any source NOT listed in your SPF. The softer ~all (soft-fail) sends those messages to spam instead of rejecting; ?all (neutral) lets them through. For cold email at scale, only -all is acceptable — soft-fail is the loophole spoofers exploit.

DKIM: 2048-bit, rotated transparently

DKIM signs every outbound message at the SMTP layer using a private key that ColdRelay holds in your dedicated tenant. The matching public key gets published at:

default._domainkey.<your-domain>   TXT   "v=DKIM1; k=rsa; p=<base64 public key>"

Specifics:

2048-bit RSA keys. 1024-bit DKIM was the standard for years and still works, but Google has been gradually deprecating 1024-bit signatures since 2024. We default to 2048 to future-proof.
Selector default — same selector across every ColdRelay domain so the publicly-cached lookup is fast. We can issue additional selectors (e.g. s1._domainkey) for customers who want key rotation isolation per sub-segment.
Automatic rotation. Every 12 months ColdRelay generates a new key, publishes the new public key at a fresh selector, switches signing to it, and retires the old selector after a 30-day overlap. You never touch DNS.

The signing happens server-side, transparent to your sending tool. Whether you're pushing from Instantly, Smartlead, EmailBison, or Saleshandy, every message goes through ColdRelay's SMTP relay where DKIM is applied. The signature covers the From header, Subject, body, and a curated set of standard headers per RFC 6376 recommendations.

DMARC: quarantine, 100% enforcement, reports to you

Your DMARC record:

_dmarc.<your-domain>   TXT   "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@<your-domain>; aspf=s; adkim=s"

Decoded:

p=quarantine — when SPF or DKIM fails, messages go to spam, not reject. We default to quarantine (not p=reject) because cold email occasionally produces legitimate edge cases (forwarded mail, mailing-list re-broadcasts) that we don't want to hard-reject. Customers who want stricter enforcement can request p=reject after their first 30 days.
pct=100 — apply the policy to 100% of failing messages. Some setups use pct=10 or pct=50 for gradual enforcement; cold email at scale needs the full bar from day one.
rua=mailto:dmarc@<your-domain> — aggregate reports go to a dmarc@ mailbox we provision on your domain. You can read them in your ColdRelay dashboard.
aspf=s / adkim=s — strict alignment for both. The "From" domain must match the SPF-validated and DKIM-signed domain exactly, not a subdomain. This closes the spoofing loophole where attackers send from notify.yourbrand.com while you publish DMARC on yourbrand.com.

What you can verify in 60 seconds

After your first ColdRelay batch provisions, you can verify all three records from any terminal:

# SPF
dig +short TXT yourdomain.com | grep spf

# DKIM
dig +short TXT default._domainkey.yourdomain.com

# DMARC
dig +short TXT _dmarc.yourdomain.com

Or use our free deliverability test tool which runs all three checks plus a few extras (MX, PTR, blocklist scan) in one shot.

If any record is missing or malformed, that's a ColdRelay-side bug and a support ticket — we provision DNS at the same step we provision the mailboxes, so a missing record means the provisioning job crashed midway. We'd already be alerting on it before you noticed.

Common SPF/DKIM/DMARC mistakes (and why ColdRelay avoids them)

After analyzing thousands of cold email setups, four mistakes account for most authentication failures:

1. SPF with ~all instead of -all. Soft-fail signals "this domain doesn't really care if someone spoofs us." Gmail's filters interpret that as a weak signal and weight your reputation accordingly. ColdRelay always writes -all.

2. DKIM key under 2048 bits. 1024-bit was acceptable five years ago. In 2024 Google began deprioritizing 1024-bit-signed mail; by 2026 they're actively flagging it. We default to 2048.

3. DMARC with p=none. Many "we configured DMARC" setups land here — they publish the record but set the policy to "do nothing." This satisfies a checkbox but does nothing for deliverability. Quarantine is the minimum useful policy.

4. Misaligned SPF/DKIM/From domains. The classic case: you're sending from mail.yourbrand.com (SPF-aligned), DKIM-signing as yourbrand.com, but your visible From header reads notifications@yourbrand.com. DMARC catches the misalignment and quarantines. ColdRelay's provisioning aligns all three to the same root domain by default.

The cost of getting this wrong (some actual numbers)

A customer we onboarded in early 2026 was sending from a domain with p=none DMARC and 1024-bit DKIM signed by their previous infrastructure provider. Their inbox placement at Gmail was ~38% — bad enough that 6 out of 10 prospects never saw their emails.

We migrated them to ColdRelay infrastructure. Same copy, same lists, same sending volume. New SPF (-all), new 2048-bit DKIM, new DMARC at p=quarantine. Inbox placement two weeks later: 96%. Same campaigns, 2.5× the actual reach.

This isn't a marketing claim — it's the math of how authentication signals stack. Bad authentication isn't a small penalty. It's the difference between cold email working and cold email being useless.

How ColdRelay handles the rest of the deliverability stack

SPF/DKIM/DMARC are necessary but not sufficient. ColdRelay also handles:

Dedicated IP per customer — your sending reputation is yours, not shared with strangers' campaigns. (Why dedicated IPs matter →)
Hourly blocklist monitoring — six major DNSBLs scanned every hour. Email alert if any IP gets listed.
Per-mailbox warmup — Built into the infrastructure. No separate warmup tool subscription, no manual ramp.
Cap enforcement — 2 outbound + 2 warmup emails per mailbox per day, max. We refuse to let you send more even if you ask, because at higher volumes deliverability collapses.

The whole point of cold-email-grade infrastructure (vs. just running on Google Workspace or shared SMTP) is that all of these signals get configured together, monitored together, and rotated together. SPF/DKIM/DMARC alone don't save you if your IP gets blocklisted. A clean IP doesn't save you if your DMARC says p=none. The stack works as a stack.

FAQ

Do I lose control of my DNS by letting ColdRelay configure it?

You can revoke ColdRelay's DNS write access at any time from your registrar. We write the three records we need (SPF, DKIM, DMARC) plus an MX record pointing at your dedicated mail server. We don't touch any other records on your domain — your A/AAAA, your CNAMEs, your other TXT records all stay where you put them.

What if I already have SPF, DKIM, or DMARC configured?

During onboarding we read your existing records first. If you already have SPF, we merge the ColdRelay sending IPs into your existing record (preserving any other senders you've authorized). If you have DKIM at a different selector, we add ours at default._domainkey without touching yours. If you have DMARC, we ask before overwriting — you may have intentionally set it to a stricter or looser policy.

Can I use ColdRelay's infrastructure with my existing sending tool (Instantly, Smartlead, etc.)?

Yes. ColdRelay is infrastructure — domains, mailboxes, IPs, authentication — not a sending platform. Push your ColdRelay mailboxes into Instantly / Smartlead / EmailBison / Saleshandy from the dashboard with one click. Your sending tool stays the same; the deliverability backbone gets the upgrade.

How long does the DNS take to propagate?

ColdRelay uses authoritative DNS via the registrar with TTLs of 300 seconds (5 minutes). Most modern resolvers see the new records within minutes. Worst case (legacy ISP resolvers caching aggressively) is ~1 hour. We monitor propagation from multiple geographic vantage points and won't mark a domain "ready to send" until at least three independent resolvers see the records.

What about BIMI / MTA-STS / DANE?

We're rolling out MTA-STS in Q3 2026 (free with all plans). BIMI requires a Verified Mark Certificate which costs $1,500+/year and is overkill for cold email's response-rate math — we don't push customers into it. DANE is a niche play that only matters if you're hosting your own MX; since ColdRelay runs your MX, DANE configuration is invisible to you (we configure it where it makes sense).

Can I see the actual records being written before they go live?

Yes — your ColdRelay dashboard shows a DNS preview before provisioning the first mailbox. You can review the exact SPF, DKIM, and DMARC strings, copy them, and verify against your own conventions before clicking provision.

ColdRelay handles SPF, DKIM, and DMARC the way any cold email operator who's been burned by deliverability would handle them themselves — strict, narrow, rotated, monitored. The difference is you don't have to handle it yourself.

Try ColdRelay free → Get started · Verify your existing setup → Free deliverability test