okki-go FAQ: SPF/DKIM/DMARC, Decision Maker Search, API Email Verification, and What Actually Counts as a Business Contact

Quick orientation before the Q&A

I run quality and brand compliance for a team that ships B2B outreach content and tooling to about 40 outbound programs a year. I review everything before it reaches a client — templates, sending configurations, data contracts, the works. Below is the short list of questions I keep getting from RevOps leads and SDR managers about okkigo (written "okki-go" in a lot of our internal notes, which is why I keep switching between the two — sorry, muscle memory).

Everything below was accurate as of Q1 2025. Email authentication standards and vendor APIs move fast, so verify current specifics with your okkigo rep or the public docs before you build anything mission-critical.

What is okkigo, in plain terms?

okkigo is an AI sales prospecting platform — an "Agent-native" setup, meaning the workflow is designed around autonomous agents doing the first pass of list-building and outreach prep rather than a human clicking through filters. The stack covers the pieces you'd normally buy separately: prospecting, waterfall enrichment, intent data, email verification, LinkedIn-side signals, and API access to email verification and company data.

The differentiation they lean on is human-in-the-loop — agents do the volume work, but a rep still approves the send. That matters, because fully autonomous outreach in 2025 still produces the kind of errors that burn a domain.

What is a business contact, and when should a B2B sales team actually use it?

A business contact is a person whose contact details are published or shared in a professional context — a work email, a work phone, a role-scoped LinkedIn profile. The key word is work. It is not the same as a consumer contact record, and using it like one is where most teams get into trouble.

When should you use one? Three times, really:

• When the person has a role-relevant reason to hear from you. A VP of RevOps has a legitimate interest in a lead-gen tool. The same person does not have a legitimate interest in your crypto pitch, and treating them as if they do is how you end up on a blocklist.
• When you can name the trigger. A funding round, a job posting, a product launch, a tech-stack change. A business contact without a trigger is just a cold name.
• When the outreach channel matches the record. Don't hit a LinkedIn-sourced business contact with a cold SMS. That's a compliance problem disguised as a personalization problem.

The question everyone asks is "where do I get the most contacts?" The question they should ask is "which of these contacts have a reason to answer me this month?" That second question is what separates a 4% reply rate from a 0.4% one.

How does okki-go decision maker search work?

Decision maker search in okkigo pulls from a mix of firmographic and role-based signals — title, department, seniority, tenure, and inferred buying authority based on company size and org structure. It's the same idea as any intent-plus-firmographic filter, so the practical question is whether the results actually hold up.

From what I've reviewed, they hold up better than I expected on mid-market accounts and a bit weaker on very small companies, where titles get fuzzy ("Founder" = everyone). If you're targeting sub-20-person companies, budget for manual verification of the seniority field. If you're targeting 200+ employees, the role inference is solid.

One caveat I'll own honestly: I'm not sure why their title normalization handles "Head of Growth" as a distinct tier rather than folding it into "VP Marketing." My best guess is that they treat it as a standalone role because it maps to distinct intent signals — but it means your segments can split in ways you didn't plan for. Check your segment counts before you launch.

okki-go SPF, DKIM, DMARC guidance — what do I actually need to configure?

This is the part I refuse to let clients skip. If you send 1,000 cold emails a day through okkigo without proper authentication, you're not doing outreach — you're training mailbox providers to distrust your domain.

The baseline, and this has been true since Google and Yahoo tightened bulk-sender requirements in February 2024:

• SPF: one TXT record authorizing okkigo's sending IPs. One. Not two. Stacked SPF records are the #1 misconfiguration I find in audits.
• DKIM: a signing key, ideally 2048-bit. Rotate it if you change vendors.
• DMARC: start at p=none with an rua reporting address, read the reports for 2–3 weeks, then move to p=quarantine, then p=reject. Skipping straight to reject without reading reports is how you black-hole your own legitimate mail.

okkigo publishes a setup guide for this, and it's worth following — but the guide assumes you already know what a DNS TTL is. If you don't, get someone who does. I learned this the hard way in 2022 when a client's DMARC rollout silently dropped their reply-to address for two weeks. They blamed the tool. It was the record.

API email verification documentation — what should I check before I integrate?

The okkigo API email verification docs (as I last reviewed them in Q4 2024) cover endpoint specs, rate limits, response codes, and — this is the part people skip — the definition of each verification status. "Valid," "Risky," and "Unknown" mean very different things depending on the vendor, and if you're piping status directly into your suppression logic without reading the definitions, you'll get burned.

Three things I always check:

1. What does "Unknown" mean? Is it a catch-all domain, a greylisted server, or a timeout? These have very different handling implications.
2. Is the verification real-time or cached? A cached "Valid" from three months ago is a guess.
3. What's the retry behavior on 429s? If your integration doesn't respect rate limits, you'll get throttled at the worst possible moment — mid-campaign.

Nothing in this space is 100% accurate, and I'd be skeptical of anyone who tells you otherwise. Plan for a 2–5% false-positive rate and build your bounce-handling around it.

okki-go API company data — is the output trustworthy?

Company data via API is genuinely useful for enrichment — headcount, industry, tech stack, funding status. Where teams get into trouble is assuming the data is live. It isn't. It's as fresh as the last crawl cycle, which for most vendors is 30–90 days.

Penny-wise move I've watched play out twice now: a team skips the paid enrichment tier to save ~$300/month, then sends 4,000 emails to companies that either shut down or got acquired. The "savings" cost them roughly $9,000 in wasted sending volume and a bruised sending reputation. Cheaper isn't cheaper when the data is stale.

One counterintuitive thing worth knowing

Most buyers focus on reply rate and completely miss reply-to-reply rate — the share of positive replies that actually turn into a booked conversation. A tool can lift your reply rate from 3% to 6% and still lose you money if the replies are all "not interested, thanks" or misdirected. When you evaluate okkigo, or anything like it, ask for both numbers.

Does this stuff only make sense for big teams?

No, and I get slightly annoyed when vendors price or gate as if it does. I've seen a two-person SDR shop get more out of a small okkigo seat than a 30-rep org got out of an enterprise contract, because the small team actually read the SPF guide and the API docs. Small doesn't mean unimportant — it means potential. If you're running your first outbound program and the tooling treats you like a rounding error, that's a signal about the vendor, not about you.

That's the whole list. If I got any of the API specifics wrong, it's because the docs moved between my Q4 2024 review and now — check the current version before you build.