Guide
The exact SPF, DKIM and DMARC configuration cold email needs: one merged SPF, per-provider DKIM keys, p=none DMARC to start, and the verification step almost everyone skips.
Authentication is pass/fail: mailbox providers now reject or junk bulk senders who miss it. The good news is that only three records matter, and each has one correct shape. This is the configuration our DNS blueprint engine writes automatically — documented for anyone.
SPF lists the servers allowed to send for your domain. The fatal mistake is TWO spf TXT records — that is an automatic permerror fail. If a record already exists, merge your provider's include into it. Microsoft 365: include:spf.protection.outlook.com. Google: include:_spf.google.com. Self-hosted: an a: or ip4: for your actual mail host. End with ~all.
DKIM cryptographically signs each message. Every provider issues its own key: Microsoft uses two CNAME selectors, Google generates a 2048-bit key in Admin Console (Apps → Gmail → Authenticate email), and self-hosted senders generate their own — which means owning the private key. Publish the selector record and verify the provider reports 'signing', not just 'record present'.
DMARC tells receivers what to do when SPF/DKIM fail alignment — and sends you reports. Start at v=DMARC1; p=none; rua=mailto:reports@yourdomain so nothing legitimate is lost while you watch. After two clean weeks, move to p=quarantine. Cold senders skipping DMARC entirely now lose Gmail and Yahoo placement: both require it for bulk senders.
Registrar dashboards show what you SAVED; providers see what public resolvers SERVE. After writing records, query public DNS (dig TXT yourdomain.com @1.1.1.1) and only trust a record once resolvers return it. Propagation is minutes to hours — our propagation prover flips a record 'verified' only on that public proof, and the same discipline works manually.
Yes. Gmail and Yahoo's bulk-sender requirements make SPF and DKIM mandatory and DMARC required at any volume that matters. Treat all three as launch blockers — our launch gate literally does.
Most often: two SPF records (merge them), more than 10 DNS lookups in the chain (flatten includes), or the record on the wrong host (apex vs subdomain). Check with a public resolver, not the registrar UI.
Eventually, for your primary domain. For fresh cold-sending domains, p=none → p=quarantine after two clean weeks is the pragmatic path; p=reject adds little for dedicated sending domains but can bite misconfigured forwarding.
The platform writes and verifies these exact records through your registrar — behind one approval.
Free to start — no card required · One approval builds the fleet