The call comes in around mid-morning. "Our newsletter went out yesterday but only half the team got it. Can you check what's going on?"
You spend two hours digging through Gmail headers, Microsoft 365 message tracing, and the client's MailChimp dashboard before realizing they've been sending mail from notifications@client.com for years without ever setting up SPF, DKIM, or DMARC. Their open rates are 30% lower than industry baseline. They never knew.
This is the most boring email problem in agency work and the easiest to fix once you know what's wrong. Let's walk through it.
The 30-second mental model
Mail providers (Gmail, Outlook, iCloud, Yahoo) decide whether to deliver an email to the inbox, the spam folder, or quietly drop it. They make that decision in milliseconds based on a small bundle of cryptographic and policy signals attached to the sender's domain.
Three records control those signals:
- SPF — "these IP addresses are allowed to send mail as @client.com"
- DKIM — "these messages are signed with a key I publish in DNS, so you can verify they're really from me"
- DMARC — "if SPF or DKIM fails, here's what I want you to do with the message"
All three live as TXT records in your client's DNS. They cost nothing. Adding them takes 15 minutes. Forgetting to add them costs your client a few percent of revenue every month forever.
SPF — the "allowed senders" list
SPF is a list of which mail servers are permitted to send email as your client's domain. It's a single TXT record on the apex of the domain.
A typical agency client's SPF looks like:
v=spf1 include:_spf.google.com include:spf.mailchimp.com -all
Translation: Google Workspace sends our mail, MailChimp sends our marketing campaigns, anyone else is not us — reject the message.
The four ways SPF breaks in agency portfolios
1. The 10-lookup limit. SPF allows at most 10 DNS lookups per evaluation. Every include: counts. We've seen client SPF records like v=spf1 include:_spf.google.com include:spf.mailchimp.com include:mail.zendesk.com include:servers.mcsv.net include:_spf.salesforce.com include:spf.intercom.com -all — that's already 6 includes, and each one chains its own. When you exceed 10, SPF evaluation fails permanently — which means every receiver treats your mail as if no SPF was set. Mass deliverability drop.
2. The migration leftover. The client used to be on Office 365, migrated to Google Workspace last year, but include:spf.protection.outlook.com is still in the SPF record. Now every send is "authenticated" by Microsoft's servers in addition to Google's, and Office's IPs aren't actually sending the mail anymore — quality signal degrades.
3. The soft-fail mistake. Ending SPF with ~all (soft-fail) instead of -all (hard-fail) tells receivers "this might be a spoof, decide for yourself." Some providers (notably Gmail) treat ~all as much weaker than -all. Always use -all once your include list is correct.
4. The third-party tool that requires SPF but agency forgot to add it. Client switches their newsletter from MailChimp to ConvertKit. ConvertKit needs include:_spf.convertkit.com. Nobody updates the SPF. ConvertKit sends start landing in spam two weeks later because they're failing SPF.
DKIM — the cryptographic signature
DKIM signs every outgoing message with a private key. The matching public key lives in DNS at a selector-scoped subdomain (e.g. google._domainkey.client.com). Receivers verify the signature matches the publicly published key.
For agency operators, DKIM is mostly "set up once per sender, never touch again." Each sender (Google Workspace, MailChimp, ConvertKit, your transactional SMTP provider) publishes specific DKIM CNAMEs or TXTs you copy-paste into DNS.
Selectors and why they multiply
Each sender uses its own DKIM "selector" — a unique sub-name on _domainkey. Google uses google._domainkey.client.com. MailChimp uses k1._domainkey.client.com and k2._domainkey.client.com. Resend uses resend._domainkey.client.com. Etc.
This means a typical client domain ends up with 5-15 DKIM records over its lifetime, each from a different vendor. When the vendor rotates their keys (Google rotates roughly every 18 months), the CNAME points at a new published key automatically — but if the vendor removes a selector, the old DNS record sits as dead weight until you clean it up. Periodic audit catches this.
DMARC — the policy
DMARC is where most agencies stop. If SPF and DKIM are the locks, DMARC is the policy that says "what should the receiver do if a message fails both checks?"
Three policy modes:
| Policy | What it tells receivers |
|---|---|
| p=none | "Failures: just report them to me, deliver anyway." Monitoring mode. |
| p=quarantine | "Failures: dump them in spam folder." |
| p=reject | "Failures: refuse the message, don't even bounce." |
Most clients you'll inherit have either no DMARC at all or p=none with no monitoring address set, which is functionally equivalent to no DMARC.
The reasonable agency DMARC progression
For a client domain with email traffic:
Week 1 — Set p=none with reporting:
v=DMARC1; p=none; rua=mailto:dmarc-reports@client.com; ruf=mailto:dmarc-failures@client.com; pct=100; aspf=r; adkim=r
This is observation mode. You're not affecting delivery yet. Aggregate reports (rua) come in daily from major providers (Google, Microsoft, Yahoo, etc.) showing you who's sending mail as @client.com. Use a free tool like dmarcian or Postmark's DMARC analyzer to parse them.
Week 4 — Once aggregate reports show ~95%+ of your mail passes SPF+DKIM:
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@client.com; ...
Quarantine but only on 10% of messages. Watch deliverability. If nothing breaks, increase pct weekly: 10 → 25 → 50 → 100.
Week 12 — Full quarantine, then reject:
Once you've sat at pct=100; p=quarantine for a few weeks with no surprise complaints, flip to p=reject. At this point your client's domain is properly protected from spoofing, and major receivers will favorably bias their reputation score.
How agencies usually catch this broken
The boring failure mode: client never reports the problem because they don't know what "good" deliverability looks like. They just accept that their newsletter has a 22% open rate when industry-standard is 28%. The 6-point gap is mostly spam-folder placement that nobody investigates.
You catch it through:
- A formal email auth audit when you onboard the client (probably 80% of new agency clients will have at least one issue).
- An external probe like Pleenx's email-auth check that watches the three TXT records on a daily cron and alerts when SPF/DKIM/DMARC drifts or breaks. Same probe family as SSL or WHOIS — boring, daily, automated.
- Reading the client's DMARC aggregate reports (the
ruamailbox) and noticing 30% of mail still fails alignment six months after setup.
We're biased toward option 2 because it's what Pleenx does. But option 1 is honestly the highest-impact one — most agency operators have never sat down and read a client's DMARC report, and it'll show you which senders are unauthorized, which subdomains are leaking mail, and where the next problem will come from.
What to ask a new client
Before you write a single TXT record, ask:
- Who do you send transactional email through? (Mailgun, Postmark, SendGrid, Amazon SES, Resend, etc.)
- Who do you send marketing email through? (MailChimp, ConvertKit, Klaviyo, ActiveCampaign, etc.)
- Do you use Google Workspace or Microsoft 365 for staff email?
- Have you ever used a service for newsletters that you stopped paying for but might still be in DNS?
- Do any of your apps send notifications "from @client.com"? (CRM, e-commerce, ticketing.)
Answer those and you have your SPF include list and your DKIM-selector list. Set the DMARC progression. Audit aggregate reports for two weeks. Done.
The TL;DR
- SPF, DKIM, DMARC are all DNS TXT records. They live on your client's domain.
- SPF authorises specific mail servers to send for you. Keep the include list under 10 lookups. End with
-all. - DKIM is set up per sender (Google, MailChimp, ConvertKit, etc.). Vendor gives you the records to publish.
- DMARC tells receivers what to do with failing mail. Start at
p=nonewith reporting, ratchet top=quarantinethenp=rejectover 6-12 weeks. - Monitor it on a cron. A daily external probe catches drift before clients notice their open rates have dropped.
Most agency operators set this up once, forget about it, and clients quietly lose 5-15% of email-driven revenue. The fix is one TXT record on each side and a check that runs daily. Cheapest agency value-add you can offer.