SPF, DKIM and DMARC for Cold Email: Records, Alignment and a 10-Minute Check

For cold email, SPF, DKIM and DMARC should pass before the first campaign; watch three things: one SPF record, one DMARC record, and aligned DKIM for every sender. If you skip this, Gmail and Yahoo have less proof that you control the mail stream. This guide gives the records, alignment checks, policy steps, and a 10-minute verification path.

Use authentication with a sending ramp, not instead of one. SPF, DKIM and DMARC prove that your domain is allowed to send. They do not fix bad lists, high complaints, or sudden volume. If you are starting from zero, pair these checks with a conservative email warm-up schedule and the free SPF checker, DKIM checker, and DMARC checker.

What do these records prove?

SPF answers one question: is this sending server allowed to send mail for this domain? It is published as a TXT record on the domain or subdomain used in the envelope sender, also called the return-path or MAIL FROM domain.

DKIM answers a different question: did the message arrive with a valid cryptographic signature from a domain? DKIM uses a selector, such as google, zmail, s1, or a provider-generated token. The public key lives in DNS at selector._domainkey.example.com.

DMARC checks whether SPF or DKIM passed, then whether the passing domain aligns with the visible From domain. It is published at _dmarc.example.com. DMARC also tells receivers what to do with failures: monitor, quarantine, or reject.

For cold email, protect DKIM alignment first. SPF can fail after forwarding because the forwarding server becomes the sender. DKIM usually survives if the message body and signed headers are not changed. DMARC passes when either aligned SPF or aligned DKIM passes.

The common mistake is treating authentication as a checkbox. A record can exist and still fail. The value, selector, host, signing domain, and alignment all matter.

SPF DKIM DMARC cold email checklist

Start with the identity recipients will see. If your visible From address is alex@sales.example.com, then sales.example.com is the domain DMARC evaluates.

For most cold email teams, a dedicated sending subdomain is cleaner than the root domain. Use mail.example.com, hello.example.com, or sales.example.com. Keep outreach separate from payroll, invoices, support, product notifications, and login mail.

Use this table as the safe baseline before you send volume.

Google requires authentication for bulk senders and tells senders to keep spam complaint rates low. Check the current Google email sender guidelines before a campaign because provider requirements change.

Do not use p=reject on day one unless you have mapped every legitimate sender. You can break invoices, support mail, calendar tools, CRM mail, and internal systems if they send as your domain without aligned authentication.

Which provider records do you need?

The exact DNS value depends on the provider, region, and account. Use the provider console as the source of truth. The table below shows the usual record shape and the names to look for.

Amazon SES documents Easy DKIM and custom MAIL FROM in its domain authentication docs. SendGrid explains its CNAME approach in Twilio SendGrid domain authentication. Mailgun lists its DNS records in Mailgun domain verification docs.

Provider dashboards often show a record as verified. That is useful, but it is not the final test. Send a real message to Gmail, open Show original, and inspect SPF, DKIM, and DMARC results. The receiver verdict is what matters.

How do you make alignment pass?

DMARC alignment compares the visible From domain with the domain that passed SPF or DKIM.

The short version:

• SPF aligns when the return-path domain matches the visible From domain, or shares the same organisational domain under relaxed alignment.
• DKIM aligns when the DKIM signing domain d= matches the visible From domain, or shares the same organisational domain under relaxed alignment.
• DMARC passes when either aligned SPF or aligned DKIM passes.

Example: your visible From address is alex@sales.example.com.

If DKIM signs with d=sales.example.com, DKIM aligns. If SPF passes for bounce.sales.example.com, SPF can align under relaxed alignment because both domains belong under example.com. If DKIM signs with a provider-owned domain, DKIM may pass but still fail DMARC alignment.

That is why custom domain authentication matters. You do not only want the provider to sign mail. You want the provider to sign as your domain.

For cold email, use relaxed alignment until you understand every sender. A common starting DMARC record is:

v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r

Later, you can tighten alignment:

v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@example.com; adkim=s; aspf=s

Strict alignment is cleaner, but less forgiving. Test before you use it. If authentication passes and messages still land in spam, work through Why do emails go to spam?. Complaints, bounces, links, content, sending bursts, and list quality can still hurt placement.

How should DMARC policy move?

DMARC has a natural path: observe, partially enforce, then enforce.

Start with p=none. This policy does not ask receivers to quarantine or reject failures. It lets you collect reports and test alignment while normal mail continues to flow.

After Google, Zoho, Lark, SES, SendGrid, Mailgun, your CRM, billing system, and support tools authenticate correctly, move to partial quarantine.

A cautious record looks like this:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com

This asks receivers to apply quarantine handling to a portion of failures. Not every receiver handles pct identically, but it is still useful for staged enforcement.

Then move to:

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

Use p=reject only when you are confident. Reject helps against spoofing, but it is unforgiving when a legitimate tool sends incorrectly.

Use separate DMARC records for subdomains only when needed. DMARC inheritance can be controlled with sp=, but simple is better for most cold email teams. If your sending subdomain has a different risk profile, publish a record directly on that subdomain.

If you send from a new domain, do not rush this. A 3–4 week ramp gives you time to catch DNS mistakes before volume makes them expensive. The new domain warm-up guide covers the sending side of that timeline.

What breaks authentication most?

Most failures come from a small set of DNS and alignment mistakes.

Two SPF records. You can publish many TXT records, but only one SPF TXT record should exist on the same host. Merge includes into one value.

Wrong:

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

and another SPF TXT record:

v=spf1 include:mailgun.org ~all

Better:

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

Do not keep adding includes forever. SPF has a DNS lookup limit. If you use many senders, remove old tools and prefer provider-specific subdomains.

DKIM selector mismatch. The provider may ask for google._domainkey, zmail._domainkey, s1._domainkey, s2._domainkey, k1._domainkey, or generated SES tokens. If you publish the key under the wrong selector, DKIM fails even when the key is valid.

CNAME target copied incorrectly. Some DNS hosts add the domain automatically. Others expect a fully qualified target. Copy the provider value, then inspect the final DNS result. Do not guess.

Signing with the provider domain. A message can show dkim=pass but still fail DMARC if d= is not aligned with your From domain. Check the full header result, not only the word pass.

DMARC on the wrong host. DMARC belongs at _dmarc.example.com or _dmarc.sales.example.com, depending on the domain you protect. Publishing it as a plain TXT record at example.com does not create a DMARC policy.

Using -all too early. SPF -all is a hard fail. It can be fine after testing, but ~all is safer while you map senders. DMARC enforcement already gives you policy control.

Forwarding breaks SPF. SPF checks the sending server. Forwarded mail often comes from a different server, so SPF can fail. DKIM usually survives forwarding if the signed content is not changed.

Tracking domains are unauthenticated. Link and open tracking domains can add reputation risk. If you use tracking, authenticate the tracking domain and keep it close to the sending identity. For early warm-up, plain text with no links is safer.

BobWork Email Warm-up checks SPF, DKIM, and DMARC daily for each domain it sees, including common selectors such as google, zmail, default, selector1, selector2, k1, s1, mail, dkim, lark, feishu, and zoho. It warms through a shared warm-up network, or a private pool per account if you prefer. The free pool handles ongoing mailbox interaction automatically, but DNS records still need to pass first.

Run the 10-minute check

Do the checks in this order. It avoids the trap of fixing DMARC before SPF and DKIM are valid.

Run the DNS side with the free SPF checker, DKIM checker, and DMARC checker. Then confirm with a real inbox header because DNS validity and receiver evaluation are not the same thing.

For Google, open the test email, click the three-dot menu, then choose Show original. Look for SPF, DKIM, and DMARC near the top. You want all three to pass, and you want DKIM d= to match or align with your From domain.

If DMARC fails but SPF and DKIM pass, inspect alignment. If SPF fails but DKIM and DMARC pass, do not panic immediately; forwarding can break SPF. If DKIM fails, fix it before campaigns.

Authentication is not a one-time setup. Providers rotate keys, people add tools, DNS records get overwritten, and old services keep sending after a team forgets about them.

Check authentication after every provider change. If you add SendGrid to a domain that already sends through Google, update SPF correctly or use the CNAME records SendGrid gives you. If you add Mailgun on a subdomain, authenticate that subdomain instead of crowding the root domain.

Keep complaint rates low. Google states that senders should keep spam complaint rates below 0.1% and avoid reaching 0.3% or higher. For cold email, targeting, suppression, unsubscribe handling, and volume control matter as much as DNS.

Warm up before outreach. A typical existing domain needs at least 14 days of steady warming. A new domain usually needs 3–4 weeks. Keep warm-up at roughly 10–15 messages per day during campaigns, and keep real outreach around 30–50 emails per mailbox per day. Add mailboxes before you add volume.

If a mailbox starts landing in spam, pause and diagnose. In BobWork Email Warm-up, ready for outbound means 14+ days warming, a 7-day spam rate at or below 10%, and at least 30 warm-up emails received. A mailbox above 5% spam rate should be paused for a few days while you fix the cause.

Use the engine behaviour page if you want the exact warm-up ramp: 3 emails per day, plus 2 per day, capped at 30 by default, weekends at 30%, with sends spread between 09:00 and 18:00 in the mailbox time zone. Gmail and Google Workspace are supported, as are Zoho Mail, Lark Mail, Yahoo Mail, iCloud Mail, Amazon SES, SendGrid, Mailgun, and other IMAP+SMTP mailboxes. Outlook is not supported yet.

Set the DNS records first, send one test to Gmail, and save the header result. Then add the mailbox to BobWork Email Warm-up to keep reputation signals moving while you prepare the campaign. It is free for up to 10 mailboxes per account, with no credit card and no time limit.

Frequently asked questions