Launch in--d--h--m--s

deliverability4 min read

How Agencies Prove SPF, DKIM, and DMARC Per Client Before First Send

IT said DNS is done is not proof. A per-client authentication packet verifies SPF, DKIM, and DMARC on the real outbound path before cold volume leaves the workspace.

Abstract geometric illustration suggesting layered email authentication and DNS trust

How agencies prove SPF, DKIM, and DMARC per client before first send

"IT said DNS is done" is not proof. Agencies that launch cold volume on a half-authenticated sending domain learn that the hard way: softfails that look like inbox placement, DMARC fails that Gmail treats as spam, and a client who thinks the copy is the problem.

GTM runs outbound inside client-isolated workspaces with connected email domains and a compliance gate that blocks send without a verdict and unsubscribe URL. Authentication proof sits one layer earlier. You verify the mailbox path before any campaign row can leave the workspace.

Why proof beats screenshots of DNS panels

Google's sender guidelines require SPF or DKIM for all senders to personal Gmail, and SPF plus DKIM plus DMARC for bulk senders (5,000+ messages per day). For DMARC to pass, the From header domain must align with the SPF authenticated domain or the DKIM signing domain. Lookup tools that only show "record present" miss alignment failures that only show up in real Authentication-Results headers.

Agency ops needs a per-client, per-domain packet that answers three questions:

  1. Which records are live in DNS right now?
  2. Do real test sends through the outbound tool pass SPF, DKIM, and DMARC?
  3. Who owns the next change if a selector rotates or an include gets added?

The per-domain proof checklist

Run this for every sending domain in the client workspace. Keep cold mail off the client's primary corporate domain when you can.

SPF

  • Exactly one TXT record starting with v=spf1. Multiple SPF records fail.
  • Every authorized sender included (Workspace or Microsoft 365, outbound tool, any ESP).
  • Under the 10 DNS-lookup limit. Over the limit, SPF can fail even when the IP is "allowed."
  • Softfail (~all) is fine while you inventory senders. Move to hardfail (-all) once the inventory is complete.
  • Proof: external SPF validator screenshot plus a test message whose headers show spf=pass.

DKIM

  • Selector published and resolving.
  • Key length at least 1024 bits. Google recommends 2048 where the provider supports it.
  • Signature actually applied by the outbound path you will use in production, not only by a manual webmail send.
  • Proof: Gmail "Show original" (or equivalent) showing dkim=pass with a d= domain that can align to From.

DMARC

  • TXT at _dmarc.<sending-domain> present.
  • rua (and ideally ruf) pointing at an inbox the agency or client actually monitors.
  • Policy chosen on purpose: p=none for learning, then tighten toward quarantine or reject once reports look clean.
  • Alignment confirmed on a real send, not assumed from SPF+DKIM individually passing.
  • Proof: header line with dmarc=pass plus the first aggregate report archived in the client packet.

How to verify without guessing

  1. Publish or confirm DNS, wait for propagation (often hours, sometimes longer).
  2. Send a test from the exact identity and tool path the campaign will use.
  3. Collect headers from at least two major receivers when you can (Gmail and Microsoft are the usual pair).
  4. Paste pass/fail into the client packet with timestamps.
  5. Block first cold send until all three checks pass for that domain.

Do not treat a green MXToolbox-style health page as the finish line. Treat a passing Authentication-Results header from a production-path test as the finish line.

What to store in the client workspace

  • Domain inventory and which campaigns may use each domain
  • Live record values and last-verified timestamps
  • Test message Message-IDs and header excerpts
  • Owner for DNS changes on the client side
  • Pause rule: if auth regresses mid-campaign, stop that domain's sends before you rewrite copy

Common agency failure modes

  • Two SPF records after someone "added" an include instead of merging
  • DKIM enabled in the ESP but never published for the client's sending domain
  • DMARC at p=none forever with no one reading rua
  • Passing SPF on a subdomain that does not align with the visible From
  • Launching warm-up before auth proof, then blaming warm-up when placement fails

Where this sits in GTM

Client-isolated workspaces keep one client's domains, send windows, and suppression away from another's. Authentication proof is the gate before those send windows matter. If a domain cannot prove SPF, DKIM, and DMARC on a real path, it should not get cold volume, no matter how clean the ICP list looks.

Agencies that treat auth as a one-time IT ticket keep relearning the same outage. Agencies that treat auth as a dated proof packet launch cleaner and pause faster when something breaks.


Sources: Google Email sender guidelines, Salespipe cold email deliverability checklist, InboxStack SPF/DKIM/DMARC 2026 guide, GTM product knowledge.

Written by GTM. More posts

Tell GTM who you sell to. It finds those people, writes to them, and books calls on your calendar.

$297 a month, plus usage. Cancel anytime.