Do not connect a production domain or upload a real prospect list just because a cold-email vendor has an attractive demo. The vendor will sit inside identity, data, messaging and sales workflows. Procurement should therefore test what the system does with a bad record, an opt-out, a DNS change and a human reply before it is allowed to touch scale.

The 25 questions below are designed as an acceptance checklist.

Data and provenance: questions 1–6

1. What contact-data sources does the product use? Ask which fields are public, licensed, customer-supplied or inferred.

2. Can source and freshness information be exported with each record? A score visible only inside the UI is hard to audit.

3. What does “verified email” mean in this product? Syntax, domain acceptance, SMTP behavior, historical delivery and direct confirmation are different signals.

4. How are corrections handled? If a salesperson discovers that a person changed companies, can the original record be corrected without losing history?

5. Can the product distinguish account-level fit from person-level fit? A good company with the wrong contact is still a bad send.

6. How are duplicates detected across imports and workspaces? Duplicate records can bypass frequency and suppression controls.

Intended use, policy and jurisdiction: questions 7–10

7. Which sending use cases does the vendor explicitly support under its terms? Do not assume a technical capability is permitted.

8. Can the workflow route or restrict records by jurisdiction when the customer requires different rules?

9. How does the system store the business reason, source or other evidence the customer wants associated with a contact?

10. What fields and message elements support the customer's required identity and opt-out process?

The FTC CAN-SPAM guide is an important U.S. reference for commercial email and states that B2B email is not categorically exempt. Other jurisdictions differ. The vendor should provide controls; the customer should obtain appropriate advice for its own markets.

Domain and authentication: questions 11–15

11. Which DNS records will the vendor ask us to add or change? Require exact examples.

12. Who owns SPF scope and prevents duplicate or overly broad authorization?

13. How is DKIM configured and rotated? Record selectors and ownership.

14. How does the vendor interact with an existing DMARC policy? A tool should not weaken policy casually just to make setup easier.

15. Is there a rollback plan? If sending configuration breaks normal business email, the organization needs a fast recovery path.

M3AAWG documentation is useful for understanding why authentication matters and why it should not be described as a guarantee that mail is legitimate or wanted.

Sending controls: questions 16–18

16. Where do messages actually originate? Customer mailbox, vendor infrastructure, relay or another provider?

17. Which provider limits and policies are enforced in product? Google, Yahoo and Microsoft each publish guidance or limits relevant to senders.

18. What automatic stop conditions exist? Ask about authentication failure, bounce spikes, provider blocks, complaint signals and unusual volume.

A vendor promising “unlimited” sending without a provider-policy explanation should create more questions, not excitement.

Suppression and unsubscribe: questions 19–21

19. Is suppression global across campaigns that share the same business purpose, or isolated to one sequence?

20. Can a suppressed address be reimported accidentally? Test it live.

21. Are suppression events exportable with time, source and reason? The organization should not lose the record if it changes platforms.

Do not accept screenshots. Use a test address, opt out, reimport it through a second list and attempt to enroll it again.

Reply handling and audit: questions 22–25

22. Does automation stop when a human reply arrives? Test positive, negative and out-of-office cases separately.

23. Can a reply be assigned to a named salesperson with the original message history intact?

24. Can the organization export a complete event log? Important events include sends, bounces, replies, opt-outs, suppression, rule changes and user actions.

25. What is the exit plan for domains, data and logs? The customer should know how to disconnect infrastructure and retrieve records without losing suppression history.

Run a five-part sandbox acceptance test

Use only controlled test records at first.

Test A — bad data: upload one invalid address, one duplicate and one record missing required metadata. Observe whether the product warns, blocks or silently queues them.

Test B — authentication: connect a test subdomain and document every DNS change. Remove or break one expected setting in the sandbox and confirm that monitoring detects the issue rather than continuing blindly.

Test C — opt-out: send to a test mailbox, opt out, reimport and attempt re-enrollment. Verify suppression across all relevant campaign paths.

Test D — human reply: reply positively and confirm that automation stops, ownership transfers and the original conversation reaches the CRM or sales queue.

Test E — export: export contacts, provenance fields, suppression, event logs and campaign configuration. Verify that the organization can interpret the files without vendor assistance.

How to score the vendor

Mark each question demonstrated, documented but not demonstrated, or unclear. A polished demo should not count as evidence for controls the buyer did not test.

Give extra weight to domain rollback, suppression, event export and reply handoff because failures in those areas can affect more than one campaign. A missing cosmetic feature can wait; inability to preserve an opt-out should not.

Also evaluate support escalation. If the company receives a provider warning or discovers an authentication change, how quickly can it reach someone who understands the sending architecture? Ask for the incident path before the incident.

The final procurement boundary

A cold-email vendor is not the organization's lawyer, data-governance function or sales manager. The tool can provide controls, records and automation; the customer remains responsible for deciding where and how it should send, for current legal and provider requirements, and for the quality of its targeting and offer.

That boundary should make procurement stricter, not more fearful. When the system can prove where data came from, show how a domain is configured, enforce suppression, stop on reply and export an audit trail, the business gains control. When the vendor's answer to every difficult question is “our AI handles it,” the buyer has no reliable operating model.

Connect real domains and real lists only after the sandbox tests pass. Scale should be the final step, not the first proof that the system works.

Add an internal owner beside every vendor promise

For each demonstrated feature, name who inside the company owns it after launch. Data provenance needs a data or sales-ops owner. DNS and authentication need a technical owner. Suppression needs an operational owner. Reply routing needs a sales owner. Cross-border rules need an appropriate legal/compliance owner. If every control is “owned by the vendor,” the business will struggle the first time two tools or policies conflict.

Also record which controls are preventive and which are detective. Blocking a suppressed contact is preventive. Alerting on a bounce spike is detective. Both are useful, but they solve different problems and should not be described as interchangeable.

A clear owner map also makes vendor escalation faster because the company knows whether an incident is a data, infrastructure, policy or sales-routing problem before opening the support case.

Sources

Related Reading