I DNS-Audited 30 Cold-Email Vendors. Six Run p=none, Which Google Allows. One Publishes Three SPF Records, Which RFC 7208 Does Not.

TL;DR: I ran SPF and DMARC lookups against the corporate domains of 30 outreach, AI-SDR and email-warmup vendors on 2026-08-16, then read their own deliverability documentation. All 30 publish both records. Six run p=none, and Google's bulk sender requirements say plainly that "Your DMARC enforcement policy can be set to none," so those six are compliant, not delinquent. The unambiguous error is smaller and louder: smartlead.ai publishes three conflicting SPF records at once, which RFC 7208 makes a permerror, meaning its SPF evaluates to nothing at all, while Smartlead's own help center tells customers that more than one SPF record makes SPF checks fail. Six of the 30 publish no usable DMARC reporting address, so they are not monitoring either.

What is this actually measuring, and what is it not?

A vendor's corporate domain is not the domain its customers send from. Mail you send through Smartlead or Apollo leaves mailboxes you own, on domains you bought, with DNS you published. Nothing here says "this tool will land you in spam." It says something narrower: the vendor sells authentication expertise, and its own zone is the one implementation of it you can check for free.

DMARC is not a deliverability score. RFC 9989, the DMARCbis revision, section 2.2: "DMARC is designed to prevent the unauthorized use of the Author Domain of an email message, a technique known as 'spoofing'." Half the cold-email content online sells p=reject as an inbox-placement lever. It is not one.

Method: nslookup -type=TXT <domain> for SPF, nslookup -type=TXT _dmarc.<domain> for DMARC, every lookup between 05:14 and 05:22 UTC on 2026-08-16. Anything surprising was re-queried against 1.1.1.1, 8.8.8.8 and 9.9.9.9 and agreed on all three. I sent no email.

What did 30 DNS lookups show?

Domain	SPF	DMARC	rua
smartlead.ai	3 records, ~all	p=none sp=none	no
instantly.ai	~all	p=reject sp=reject	yes
lemlist.com	~all	p=quarantine	yes
apollo.io	~all	p=quarantine sp=quarantine	yes
clay.com	~all	p=none	yes
outreach.io	-all	p=reject	yes
salesloft.com	no all	p=reject	yes
reply.io	-all	p=reject sp=none	yes
woodpecker.co	~all	p=quarantine pct=50	yes
mailshake.com	~all	p=none sp=none	yes
quickmail.com	-all	p=quarantine	no
saleshandy.com	~all	p=none	yes
snov.io	~all	p=reject	yes
lavender.ai	-all	p=reject sp=reject	yes
regie.ai	-all	p=quarantine pct=5	no
11x.ai	-all	p=reject sp=reject	yes
artisan.co	-all	p=quarantine pct=25	yes
aisdr.com	~all	p=quarantine	yes
warmy.io	~all	p=reject	yes
mailreach.co	-all	p=quarantine	yes
folderly.com	~all	p=reject sp=quarantine	yes
gmass.co	~all	p=none sp=none	off-domain
klenty.com	~all	p=quarantine	yes
amplemarket.com	~all	p=quarantine sp=none	yes
hunter.io	-all	p=reject sp=reject	yes
salesforge.ai	~all	p=quarantine	no
persana.ai	~all	p=quarantine	yes
unifygtm.com	-all	p=reject	malformed
warmbox.ai	?all	p=quarantine sp=quarantine	no
warmupinbox.com	-all	p=none	unauthorized

One SPF record each, except where noted.

Six sit at p=none, thirteen at p=quarantine, eleven at p=reject. Eleven use -all, seventeen ~all, one ?all, and salesloft.com publishes no all mechanism at all, which RFC 7208 section 4.7 treats as an implicit ?all neutral. Nobody exceeded the ten-lookup ceiling; the worst was seven.

Three publish pct= below 100: regie.ai at 5, artisan.co at 25, woodpecker.co at 50. That is not negligence. Microsoft's rollout guide tells administrators to step through exactly those increments, and RFC 9989 removes the pct tag entirely (Appendix A.6, "Removal of the 'pct' Tag"). Mid-rollout or parked, and from outside DNS I cannot tell which.

Three publish a weaker subdomain policy than their org policy: reply.io and amplemarket.com both pair an enforcing policy with sp=none, and folderly.com pairs p=reject with sp=quarantine. sp=none exempts every subdomain, and bulk sending is exactly what standard advice moves onto a subdomain.

The reporting gap is the quiet one. Five publish no rua tag. unifygtm.com publishes this:

v=DMARC1; p=reject; pct=100; adkim=s; aspf=s; fo=1; [rua=mailto:dmarc-reports@unifygtm.com](mailto:rua=mailto:dmarc-reports@unifygtm.com)

Somebody pasted markdown into a DNS TXT record. The tag a parser sees is [rua, not a DMARC tag, so it is ignored and a p=reject domain receives nothing. Two more point rua at an external domain that never published the required authorization record. As Microsoft's DMARC documentation states: "Without this record, receivers don't deliver DMARC reports to the external address." gmass.co sends reports to a personal Gmail account (gmass.co._report._dmarc.gmail.com returns NXDOMAIN); warmupinbox.com has the same gap.

Whose own advice does their own DNS break?

I read the deliverability documentation of all six p=none vendors. Three publish an instruction their own record contradicts.

Smartlead is the clearest. Its help center article on authentication troubleshooting says, verbatim, "Having more than one SPF record causes SPF checks to fail. Always use a single SPF record containing all authorized sending servers." What smartlead.ai returns:

"v=spf1 include:one.zoho.com ~all"
"v=spf1 include:zcsend.net ~all"
"v=spf1 include:zoho.com.au include:spf.efwd.registrar-servers.com include:_spf.google.com ~all"

Three records, confirmed on three resolvers. RFC 7208 section 4.5: "If the resultant record set includes more than one record, check_host() produces the 'permerror' result." Its DMARC is p=none; sp=none with no rua, while Smartlead's own DMARC guide tells readers to hold p=none for one to two weeks and then tighten. You cannot be in the monitoring phase with no reporting address.

Mailshake's deliverability checklist says "A DMARC policy of p=reject is fast becoming the industry standard for trustworthy senders." mailshake.com publishes p=none; sp=none. GMass tells readers to "enter a general address at your domain" for reports; gmass.co uses a personal Gmail that cannot receive them.

The other three pass, and that matters. Saleshandy's guide says "You can only have one SPF record per domain," and it publishes one. Clay's deliverability post explains what DMARC is and never prescribes a policy, so p=none contradicts nothing it published. Warmup Inbox's guide uses p=none as its own worked example.

Was p=reject ever actually required?

No, and this turned out to be the more interesting finding. Google requires bulk senders above 5,000 messages a day to publish DMARC, then says the enforcement policy "can be set to none." Microsoft recommends p=reject as a goal with a staged rollout, but recommending is not requiring, and it is anti-spoofing hardening, not inbox placement. The floor either provider actually enforces sits far lower: Microsoft routes mail through its high-risk delivery pool when "the source email domain has no A record and no MX record defined in public DNS." None of these 30 are near that.

The gap is not between the vendors and the mailbox providers: all 30 clear the published bar. It is between what the category invoices for and what the standards say, and between what three vendors tell you to do and what they did.

What would change my mind?

A better audit reads DKIM selectors and DMARC aggregate reports, and public DNS gives me neither: selectors are not enumerable, reports are private. p=none can be a deliberate holding pattern while a long tail of SaaS senders gets untangled, a legitimate state that looks identical from outside. Thirteen of the thirty were clean on every axis I checked, a better hit rate than I expected. Every one of these records is one DNS edit from changing, so if you are reading this later, run the two commands yourself rather than trusting my table.

This is the same shape as every time this site checks a vendor claim against a vendor artifact, whether that is the credit math behind Clay's pricing or eight outreach tools graded against their own homepages. The advice is mostly good. It is just easier to publish a checklist than to run one, and DNS is the rare place where you can tell the difference for free. The same gap runs through the compliance story these vendors are quietest about, where Article 50 of the EU AI Act turns out not to reach a one-to-one sales email at all.