Okki Go SPF, DKIM, DMARC Guidance + Decision Maker Search: A 7-Step Checklist for B2B Sales Teams
2026-09-23 · Kwesi Adom
-
Who this checklist is for
-
Step 1: Map your sending domain before you touch okkigo
-
Step 2: Set up SPF, DKIM, and DMARC in the right order
-
Step 3: Run okki go decision maker search with a hypothesis, not a dump
-
Step 4: Define what a business contact is before you import
-
Step 5: Read API email verification documentation before you trust the score
-
Step 6: Use API company data to qualify, not to fill every field
-
Step 7: Launch a 50-contact pilot before the full send
-
Common errors and notes
Who this checklist is for
I have been handling outbound data ops and sales tooling for B2B SaaS teams for about 9 years. I have personally made and documented 9 significant mistakes, totaling roughly $12,600 in wasted budget. I now maintain our team checklist so other RevOps folks do not repeat them.
This checklist is for B2B sales teams, RevOps, SDR managers, and outbound agencies setting up or auditing okki-go style prospecting. It is most useful if you send 500-5,000 cold emails per month, manage more than one sending domain, or use enrichment, verification, and intent APIs. It is not for transactional email or one-off personal notes.
Everything I had read said email verification was the main thing. In practice, domain authentication and sending behavior mattered more. Here is the 7-step checklist we use before any new okkigo campaign goes live.
Step 1: Map your sending domain before you touch okkigo
Before you import a single contact, decide which domain will send. Do not send cold outbound from your primary root domain if you can avoid it. Use a subdomain, like go.yourcompany.com or sales.yourcompany.com, so your main domain stays protected.
Check the three DNS records that control email authentication: SPF (the DNS record that lists allowed sending servers), DKIM (the signature that proves the message was not altered), and DMARC (the policy that tells receivers what to do when authentication fails).
Per RFC 7208, SPF is published as a DNS TXT record. Per RFC 6376, DKIM uses a public key published in DNS. Per RFC 7489, DMARC lets domain owners publish a policy and receive reports. Sources: rfc-editor.org/rfc/rfc7208, rfc-editor.org/rfc/rfc6376, rfc-editor.org/rfc/rfc7489.
Checkpoint: run DNS lookups for your SPF record, your DKIM selector, and your DMARC record. If you cannot explain what each record does in one sentence, pause. I once copied an SPF record from a client and left an old include in place. It caused a PermError on some lookups. That mistake cost us two days of deliverability noise and about $300 in wasted send credits.
This worked for us, but we were on Google Workspace. If you are on Microsoft 365 or a mix of providers, your includes and DKIM selectors will be different.
Step 2: Set up SPF, DKIM, and DMARC in the right order
Do SPF first. Add only the include hosts your sending tools actually document. Do not guess. If you use okkigo or another sender, copy the exact include host from their DNS setup page. Keep the record under the 10 DNS lookup limit where possible.
Then DKIM. Publish the selector your vendor gives you. Most modern tools use a CNAME or TXT record. Verify the selector before you send. A valid DKIM signature helps with alignment and can survive some forwarding.
Then DMARC. Start with p=none and a reporting address, like rua=mailto:[email protected]. Watch the reports for 2-4 weeks. Once legitimate mail passes SPF or DKIM alignment, move to p=quarantine. If everything still passes, move to p=reject.
Google and Yahoo bulk sender guidelines, updated in 2024, require authenticated messages and easy unsubscribe for bulk senders. Source: support.google.com/a/answer/81126. Check current requirements because they change.
Checkpoint: send a test message to a Gmail account and view the original. Confirm SPF, DKIM, and DMARC all say PASS. If DMARC says none or fail, do not launch. In September 2022, I moved straight to p=reject without reading reports. We broke a legitimate invoice sender for 36 hours. That was not a cold email issue, but it was a $700 lesson in sequencing.
Step 3: Run okki go decision maker search with a hypothesis, not a dump
Okki go decision maker search is a relevance tool, not a volume lever. Start with one hypothesis about who buys your product and why now. Pull 50-100 contacts, not 10,000. Filter by title, department, seniority, location, company size, and tech stack only when those filters match your hypothesis.
Build three small lists: economic buyer, champion, and blocker. The economic buyer controls budget. The champion feels the pain. The blocker can stop the deal. If a contact does not fit one of those roles, leave them out.
Checkpoint: every list has a one-sentence reason for why this person, why now, and why this offer. If you cannot write that sentence, the list is not ready.
In 2022, I pulled 8,000 director-plus contacts because it looked efficient. About 62% were not in the buying committee. That mistake cost $1,100 in enrichment credits and roughly three weeks of SDR time. When I compared our Q1 broad-title list and our Q2 function-specific list side by side, I finally understood why decision maker search works best as a filter, not a firehose.
Step 4: Define what a business contact is before you import
What is a business contact and when should a B2B sales team use it? A business contact is a person's professional contact information used for work-related communication. That usually means a work email, work phone, LinkedIn profile, role, company, and sometimes a direct dial. It is not a personal email, a personal cell number, or a social profile you scraped from a private group.
Use a business contact when you have a legitimate business reason to reach that person about their role. Examples include a relevant product, a compliance deadline, a hiring signal, or a clear operational pain. Do not use it for consumer spam, personal harassment, or mass blasts with no relevance.
The FTC CAN-SPAM Act requires commercial email to be truthful, include a clear opt-out, and list a valid physical postal address. Source: ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business. For EU contacts, GDPR Article 6(1)(f) can allow legitimate interest, but you still need a balancing test and an easy opt-out. Source: gdpr-info.eu/art-6-gdpr.
Checkpoint: every record has a source, a date, a legitimate-interest note, and a suppression status. If a contact is in the EU and you cannot explain the legal basis, do not import. I once imported a list without source dates. Three weeks later, we could not prove where half the records came from. We deleted them and lost about $850 in list cost and cleanup time.
This is for B2B outbound to business emails. If you are targeting sole proprietors or freelancers in the EU, treat that data more like personal data. Your mileage may vary by country and legal advice.
Step 5: Read API email verification documentation before you trust the score
API email verification documentation is boring until it is not. Before you route a list through any verification API, read what the API actually checks. Look for SMTP handshake behavior, catch-all detection, role account handling, disposable domains, greylisting, and response codes. A green check does not mean the inbox is active forever. People change jobs, domains expire, and catch-all servers lie.
Checkpoint: run a 100-contact sample from each source. Compare the API result with what you can verify manually or with a second method. If the same domain returns a high number of unknown or catch-all results, treat that domain carefully.
In 2024, I assumed a valid result meant inbox. We sent 1,200 contacts to a catch-all domain. The bounce rate was 22%. We burned a subdomain and spent about $450 in wasted send credits plus 10 days of warm-up. Nobody can guarantee every address is deliverable. Any vendor that says otherwise is a red flag.
This was accurate as of Q1 2025. Verification APIs evolve, so verify current documentation before you build a workflow around one score.
Step 6: Use API company data to qualify, not to fill every field
API company data can give you firmographics, technographics, headcount, funding, and intent signals. Use it to qualify accounts, route leads, and personalize the first line. Do not let it overwrite manually verified CRM fields. Enrichment is not the same as truth.
Checkpoint: match company domain to CRM account. Flag mismatches. Log the source and pull date for every field. If two sources disagree, keep the one your sales team has already verified.
I once let an enrichment API overwrite account owner and industry for 300 accounts. It broke routing for two days and made attribution messy. The fix was not hard, but the trust cost was real. The conventional wisdom is more data equals better targeting. My experience with 14 outbound campaigns suggests fewer, fresher, source-tagged fields beat a giant enrichment dump.
Step 7: Launch a 50-contact pilot before the full send
Do not go from setup to 5,000 sends. Start with 50 contacts in three small batches. Watch bounce rate, spam complaints, replies, and meetings booked. Keep a human in the loop for the first replies, especially if you use AI-assisted outreach. Human-in-the-loop outreach is slower at the start, but it catches bad personalization before it damages your domain.
Checkpoint: if bounce rate is above 3%, pause. If spam complaints approach 0.1%, pause and inspect. Google recommends keeping spam complaint rates below 0.10% and says 0.30% or higher can lead to blocking. Source: support.google.com/a/answer/81126. Check current thresholds because they can change.
In Q1 2024, I skipped the pilot because a campaign was urgent. We sent 3,000 emails. The spam complaint rate hit 0.18%. Our domain got throttled. That cost about $1,800 in delayed pipeline and a lot of internal explaining. The pilot would have taken 90 minutes.
Common errors and notes
- Do not reuse your root domain for cold outbound if you can use a subdomain.
- Do not buy lists and send without verification, source dates, and suppression checks.
- Do not ignore DMARC reports. They are the only way to see who is sending as your domain.
- Do not send to personal emails when a business contact is appropriate.
- Do not let AI write to unverified contacts or make compliance claims on your behalf.
- Do not treat a vendor score as a guarantee. Use it as one signal among several.
- Do not skip the 50-contact pilot. It is the cheapest insurance you have.
If you can explain why this person, why now, and why this offer, you probably have a legitimate business contact. If you cannot, hold the send. That one rule has saved our team more budget than any tool setting.