A practical authentication checklist for outreach teams: inventory senders, test the real sending route, verify alignment and give clients a clear launch record.
A new mailbox can send a message before the team has checked whether the domain authenticates correctly. That makes “the test arrived” an incomplete launch decision. For an agency managing several clients, the useful question is: can we show which service sent the message, how it authenticated, and who owns any remaining fix?
This guide gives outreach operators a practical preflight. It focuses on evidence from the actual sending route, with a small handoff document your client and technical owner can both understand.
What the three checks actually tell you
| Check | What it establishes | What to record |
|---|---|---|
| SPF | Whether the sending server is authorized for the envelope-sender domain | SPF result and the domain checked |
| DKIM | Whether a message signature verifies against a domain’s public key | DKIM result, signing domain, selector |
| DMARC | Whether a passing SPF or DKIM identity aligns with the visible From domain | DMARC result and visible From domain |
An SPF pass alone does not prove that the address the recipient sees is authenticated. DMARC connects the visible identity to an authenticated one. At least one aligned authentication path must pass; both do not have to pass for DMARC itself to pass. Cloudflare explains the relationship between SPF, DKIM and DMARC.
Keep authentication separate from campaign results. A valid signature is not proof that a recipient wants the message, that it reached the inbox, or that it will produce a reply.
1. Inventory every service that sends for the domain
Before changing DNS, create a sender inventory. Include everyday mail, outreach software, invoices, support tools, forms and product notifications. Ask the client who manages each service rather than assuming the outreach platform is the only sender.
Use one row per sending route. A mailbox connected to an outreach tool through its existing mail provider may use a different route from a platform that sends through its own infrastructure. Record what actually happens, not just the tool’s name.
| Sending route | Visible From domain | Technical owner | Evidence still needed |
|---|---|---|---|
| Staff mailbox | example.com | Workspace administrator | Received-message authentication |
| Outreach integration | example.com | Campaign operator | Test through the integration |
| Billing service | billing.example.com | Finance systems owner | Provider setup and received test |
These rows are illustrative, not an AllProfiles configuration or a recommendation to use those exact domains. The point is to discover dependencies before a change interrupts an unrelated workflow.
2. Compare provider instructions with existing DNS
Ask the sending provider for the records generated for this specific domain. Do not paste another company’s SPF value or DKIM selector from a tutorial.
SPF is published in DNS and describes authorized senders. Its evaluation has a DNS-lookup limit, so adding provider includes indefinitely is not a safe way to repair it. Review the complete existing record with the domain administrator instead of treating each new tool as an isolated addition. Cloudflare’s SPF reference explains the record format and lookup constraints.
For DKIM, follow the provider’s activation flow as well as its DNS instructions. Store the selector and the provider’s verified status in the handoff. Keep private signing keys and administrator credentials out of the campaign spreadsheet.
Cloudflare documents how signatures use a private key and a DNS-published public key, and recommends a monitored rollout before stronger DMARC enforcement. Read its authentication documentation.
3. Test the real route, not a substitute
Send a controlled test to mailboxes your team owns, using the exact sender and integration planned for the campaign. A successful message from the provider’s webmail interface does not test a separate API sender.
Save the received message’s original headers or a redacted screenshot of the receiver’s authentication results. Capture:
- Date, sender address and sending application.
- Visible From domain and envelope-sender domain.
- SPF result, DKIM result and signing domain.
- DMARC result and any receiver explanation.
- The person responsible for investigating a failure.
Read results added by the receiving service, rather than trusting arbitrary authentication text included by a sender. Keep the full technical evidence in a restricted location; the client summary normally needs the outcome and owner, not every routing detail.
Run another test after a relevant configuration change. Mark the old evidence as superseded so someone does not approve launch using yesterday’s result.
4. Investigate alignment before rewriting everything
Illustrative example: a message visibly comes from maya@example.com. A third-party sender passes SPF for its own provider domain, while DKIM passes with a signature for example.com. The SPF identity may be unaligned, yet the aligned DKIM pass can satisfy DMARC. Conversely, two authentication passes for unrelated provider domains do not establish alignment with example.com.
Your investigation should therefore distinguish “authentication failed” from “authentication passed for the wrong identity.” Give the provider the relevant domains and the receiver’s result. Avoid replacing several records simultaneously: it makes the next test harder to interpret and can disturb other senders.
5. Review the receiving provider’s requirements
Google’s rules for personal Gmail recipients distinguish all senders from bulk senders. Its authentication baseline is SPF or DKIM for all senders, and SPF, DKIM and DMARC for bulk senders. Bulk marketing and subscription messages also need one-click unsubscribe and a visible unsubscribe link. These are only part of the requirements; consult the complete Gmail sender guidelines for your sending pattern.
Treat this as a separate launch review. A green DNS checker does not confirm that an unsubscribe flow works or that the campaign satisfies all receiving-provider requirements. Test the actual opt-out path with an internal address and confirm the campaign tool suppresses further sends to it.
6. Give the client a small, explicit launch record
Our suggested handoff uses four statuses: ready, blocked, awaiting evidence and not applicable. “Awaiting evidence” is valuable: it stops an untested route being mistaken for a successful one.
| Item | Completion evidence | Owner |
|---|---|---|
| Sending routes inventoried | Client-approved sender list | Campaign lead |
| Domain setup reviewed | Provider verification and DNS review | Domain administrator |
| Actual route tested | Received authentication results | Technical operator |
| Replies and opt-outs checked | Controlled internal test | Campaign operator |
| Unresolved issues assigned | Named owner and next action | Campaign lead |
Approve a specific route, not the entire company forever. Adding a provider, changing a From domain or moving mailboxes creates a reason to repeat the relevant checks.
After launch, include configuration incidents separately from commercial results in your client outreach report. When email supports a wider LinkedIn campaign, agree how conversations move between channels using a reply-handling workflow. That keeps a delivery problem from being hidden inside a vague “low response” number.
A useful preflight ends with evidence your team can revisit: what was tested, what passed, what remains unresolved and who can fix it. That record is more actionable than a screenshot showing three DNS records exist.
