Cold Email Deliverability: SPF, DKIM, DMARC and Sender Practice
A current cold email deliverability guide covering SPF, DKIM, DMARC, DNS, list quality, sending behaviour and monitoring without inbox guarantees.
Co-founder of Ampliflow. Builds AI automation, websites, SEO/AEO, and growth systems for UK SMEs.

- 01Start with permission and relevance
- 02The three authentication records
- 03Current Gmail sender requirements
- 04Domain warming is not a fixed calendar
- 05List quality is infrastructure
Cold email deliverability is not a trick for bypassing spam filters. It is the combined result of identity, infrastructure, recipient expectation, message quality and sending history.
SPF, DKIM and DMARC are necessary foundations. They cannot make an unwanted campaign welcome, and nobody can guarantee the primary inbox. The practical goal is to authenticate mail, send only defensible messages, monitor negative signals and stop before reputation damage compounds.
Start with permission and relevance
Before DNS, decide whether the campaign should exist. In the UK, direct marketing by email can engage PECR and UK GDPR. The rules differ between corporate subscribers and individuals, including sole traders and some partnerships.
The ICO's B2B marketing guidance explains those distinctions. You still need a lawful basis when processing personal data, transparent information and a reliable way to object.
Authentication is not permission. A technically perfect message can still be unlawful, irrelevant or unwelcome.
The three authentication records
- 01SPF — permitted sending systems
- 02DKIM — cryptographic message signature
- 03DMARC — alignment, policy and reporting
SPF: which systems may send
SPF is a DNS TXT record that identifies servers permitted to send for a domain. Each domain should have one coherent SPF record. Multiple SPF records can cause evaluation errors.
An example shape is:
textv=spf1 include:mail-provider.example -allDo not copy that value. Use the exact include mechanisms your real providers document. Keep within SPF's DNS-lookup limits and remove services no longer authorised to send.
DKIM: whether the message was signed
DKIM adds a cryptographic signature to outgoing mail. The receiving server retrieves the public key from DNS and checks whether signed parts of the message changed in transit.
Create DKIM keys in the sending platform, publish the provided record and verify a real message. Rotate keys according to the provider's supported process.
DMARC: what aligns and what happens next
DMARC checks whether the visible From domain aligns with authenticated SPF or DKIM and publishes a policy for failed messages. It can also send aggregate reports.
A cautious monitoring record might look like:
textv=DMARC1; p=none; rua=mailto:dmarc@example.comDo not move directly to p=reject without finding every legitimate sender. Use reports to inventory services, correct alignment and then strengthen policy deliberately. p=none provides visibility; it does not protect against all spoofing.
Current Gmail sender requirements
Google's email sender guidelines apply to mail sent to personal Gmail accounts. Google currently expects all senders to use SPF or DKIM, valid forward and reverse DNS, TLS and standards-compliant message formatting, while keeping spam rates low.
Senders above Google's bulk threshold face additional requirements, including both SPF and DKIM, DMARC, alignment and one-click unsubscribe for relevant marketing messages. Google documents a spam-rate target below 0.3%; aiming close to the limit is not a safe operating strategy.
Microsoft and other providers maintain their own requirements. Check live provider documentation before changing infrastructure.
Domain warming is not a fixed calendar
There is no universal schedule that turns a new domain into a trusted sender. Reputation develops from real delivery and recipient behaviour. Artificial “warming” exchanges can create misleading signals and do not cure poor targeting.
For a legitimate new sending stream:
- authenticate the domain before the first campaign;
- begin with the most relevant, expected recipients;
- keep volume stable enough to diagnose;
- watch bounces, complaints, deferrals and blocks;
- pause increases when signals worsen;
- investigate list source and message fit before resuming.
Do not publish a rigid daily ramp as though mailbox providers endorse it. Volume should follow evidence from the real sender.
Sending domains and inbox rotation
Using more inboxes does not turn poor practice into good practice. Rotation can spread volume across mailboxes, but it also creates more credentials, DNS records and reputations to monitor.
Protect the main corporate domain from experimental campaigns, but avoid deceptive lookalike domains. A recipient should be able to understand who is contacting them. Maintain a clear inventory, renewal owner and shutdown process for every sending domain.
List quality is infrastructure
The best deliverability improvement often happens before sending:
- use a documented, defensible source;
- target a specific role and reason;
- validate syntax and domain existence;
- remove known complainers and prior opt-outs;
- suppress hard bounces immediately;
- avoid purchased bulk lists of unclear origin;
- keep evidence of why each audience was selected.
Address verification can reduce obvious bounces. It cannot prove that a person wants the message or that the campaign is lawful.
Message design that helps recipients decide
Write recognisable, plain messages:
- identify the sender and business;
- explain the relevant reason for contact;
- avoid fabricated familiarity or urgency;
- make claims specific and supportable;
- use one proportionate next step;
- provide a working opt-out;
- keep tracking no more intrusive than necessary.
Spam filters use many signals. Removing a few “trigger words” is not a strategy. A deceptive message remains deceptive in simpler vocabulary.
Monitoring and stop conditions
Monitor by domain, provider and campaign:
- delivery, deferral and hard-bounce codes;
- spam complaints;
- DMARC aggregate reports;
- authentication alignment;
- opt-outs and negative replies;
- blocklist appearances in context;
- provider postmaster data where available.
Agree stop conditions before launch. Examples include an authentication failure, a sudden hard-bounce increase, a complaint spike or evidence that the list source is wrong. The exact threshold should reflect the provider, baseline and campaign; it should not be invented after the warning signs appear.
A pre-send checklist
- [ ] Campaign purpose and audience are documented.
- [ ] Legal basis and PECR position have been reviewed.
- [ ] SPF, DKIM and DMARC pass and align as intended.
- [ ] Forward and reverse DNS are valid where required.
- [ ] The sender identity is clear.
- [ ] Suppression and unsubscribe work end to end.
- [ ] Hard bounces stop future sends.
- [ ] Monitoring and named stop owners are active.
- [ ] A low-volume test reached the intended providers.
- [ ] The team can pause every sequence quickly.
Frequently asked questions
Can SPF, DKIM and DMARC guarantee inbox placement?
No. They authenticate identity and support policy. Recipient response, reputation, content, list quality and provider systems still affect placement.
Should I use a separate domain for cold outreach?
Separating experimental sending can limit risk to the main domain, but the sending identity must remain clear and responsibly operated. Avoid deceptive domains.
How many emails can a new inbox send each day?
There is no credible universal number. Follow the provider's account limits and increase only from observed, healthy behaviour. Relevance and complaints matter more than a copied ramp schedule.
Does DMARC p=none improve deliverability?
It gives visibility into authentication and alignment. It is a monitoring policy, not a deliverability guarantee or full anti-spoofing policy.
Related reading
If the campaign is ready but the sender controls are not, Get unstuck.