Skip to main content

I Gate AI-Assisted Outreach on SPF, DKIM and DMARC

Why AI-assisted outreach from my WordPress CRM stays parked until SPF, DKIM and DMARC pass on a real message, plus the dig and header checks I have an AI agent run.

The day before, I built an admin-only WordPress CRM with Cursor for a small business side project’s B2B outreach. It could import research, park drafts, and require a typed SEND confirmation. It was still useless until mail actually left the sending domain cleanly.

So the next ship wasn’t more pipeline UI. It was a hard gate: no outbound email from the CRM, AI-drafted or not, until SPF, DKIM, and DMARC pass on a real message. I had the AI agent do the checking and kept the send button for myself.

What I actually shipped

  • A real hosted mailbox on the sending domain (any provider that signs DKIM works)
  • WordPress SMTP that authenticates as that mailbox with an app password, not the server’s default mail()
  • SPF, DKIM, and a starter DMARC policy (p=none) published at the DNS provider
  • A real test message that passed SPF, DKIM, and DMARC
  • Visible From kept on the authenticated domain, and Reply-To pointed at the inbox people actually watch
  • The first outreach batch sent only after all of the above passed

This isn’t a deliverability product pitch. It’s the boring gate that turns a CRM from a draft folder into outbound.

Advertisement

Where the AI agent fits

An AI agent is very good at the parts of this people skip: running the same DNS lookups after every change, reading raw headers, and refusing to call something done. The agent’s job was:

  1. Check the records. Run the lookups after every DNS change and compare the answers with what the provider says should be there.
  2. Read the proof. Parse the Authentication-Results header on a real received test message instead of trusting a dashboard tick.
  3. Hold the line. Keep outreach drafts parked in the CRM until all three checks pass, then hand the send decision back to a human.

The checks it ran, with placeholder names:

# SPF: one record, includes your mail provider
dig +short TXT example.com | grep spf1

# DKIM: the selector comes from your mail provider
dig +short TXT selector1._domainkey.example.com

# DMARC: start with monitoring only
dig +short TXT _dmarc.example.com
# expect something like: "v=DMARC1; p=none; rua=mailto:[email protected]"

Then the real test: send from the outbound mailbox to an inbox you control, open the raw message, and look for all three passes in one header:

Authentication-Results: mx.example.net;
  dkim=pass header.d=example.com;
  spf=pass smtp.mailfrom=example.com;
  dmarc=pass (p=NONE) header.from=example.com

If any of the three says anything other than pass, outbound isn’t live.

Identity: From vs Reply-To

One sharp edge carried over from the CRM build: SMTP identity is not the same thing as what looks right in the editor.

  • Visible From stays on the authenticated sending domain, the mailbox that actually signs the message.
  • Reply-To points at the customer-facing address, so replies land where someone is watching.

Get that pair wrong and you end up with “SMTP worked in a test” but “production From fails DMARC.” I kept them aligned on purpose.

What broke earlier

  • Missing MX and SPF: Mail to the domain couldn’t land, and outbound had nothing trustworthy to advertise. The CRM was ready; the domain wasn’t.
  • Auth mailbox vs visible From: Authenticating as one mailbox while showing another From is a fast path to spam folders and failed alignment.
  • Sending before auth: It’s tempting once drafts look polished, and more so when an AI drafted them in seconds. We waited. Polished HTML without SPF, DKIM, and DMARC is still a spam risk.

What I left out on purpose

  • No attachments on first contact. Brochures and samples go out on request.
  • No invented inbox-placement rates or “100% deliverability” claims
  • No “AI writes it and blasts hundreds of prospects” loop. Drafts stay parked until an admin confirms.
  • No large send before the test message passed

Ship checklist (if you copy the pattern)

  1. Bring up a real mailbox on the sending domain before you call outbound “live.”
  2. Publish SPF, DKIM, and a starter DMARC policy at the DNS provider for the sending domain.
  3. Have your agent (or a script) re-run the dig checks after every DNS change.
  4. Send a real test message and confirm SPF, DKIM, and DMARC all show pass in Authentication-Results.
  5. Keep the visible From on the authenticated domain, and use Reply-To for a different customer-facing inbox.
  6. Only then send the first batch from the CRM, with every draft still needing an admin to confirm.

FAQ

Why DMARC p=none?

I wanted monitoring without rejecting mail while the records settle. Tighten it to quarantine or reject once alignment stays clean in the reports.

Does the AI agent send the emails?

No. It checks DNS and headers, and it can help draft. Sending requires an administrator to type a confirmation in the CRM.

Is this a mustafa.net mail product?

No. It’s a ship log for a WordPress outbound setup on a side project. The CRM build is here, and the guardrails I give agents are in 7 Rules for Letting an AI Agent Maintain Your Homelab.

Written by MustafaEngineer running a 24/7 homelab since 2022. Every guide here is built and tested on my own hardware. No paid placements.

Keep reading