Nobody emails you an error when your SPF breaks
Email authentication now fails loudly at the mailbox and silently at the source. That gap is a job posting — and a one-line CI check.
TL;DR Authentication fails silently at the source and loudly at the mailbox. Across 117 companies hiring for this work, 97% publish DMARC but only 74% enforce it, and just 2% publish TLS-RPT. Nothing emails you when a record breaks — which is why the check belongs in CI, and why the checker itself needs testing.
Who is actually hiring for email authentication?
Pull a week of email-operations job listings and the hiring isn't where you'd expect. Not the AI startups — a solar installer, a supplements brand mailing a million-plus subscribers, a CBD wellness label, a heavy-equipment dealer, a public broadcaster's donor team. Different industries, one recurring line in the description: stay on top of whether our email reaches the inbox.
They're all hiring the same thing — a human alarm. Someone to re-check that SPF still resolves, that DMARC didn't get flipped back to p=none during a migration, that the DKIM key the new ESP rotated in is actually published — the exact window where a replatform quietly resets your reputation, that MTA-STS still covers the current MX. None of it is what these companies do for a living. But email drives enough of the revenue that someone has to own whether it lands.
Why does broken authentication go unreported?
The job exists because authentication fails silently. An SPF include stops resolving; a contractor relaxes DMARC to ship a campaign and never tightens it — the drift that follows when DNS gets handed to marketers; a DKIM selector ships at 1024 bits. Nothing bounces on the day it breaks. The mail just starts landing in spam, and you find out weeks later when the numbers sag.
And the stakes are no longer subtle. Since February 2024, Gmail and Yahoo have required SPF, DKIM and DMARC from bulk senders and capped spam complaints at 0.30% — and Gmail now rejects non-compliant mail outright. Yet posture stays half-built: in Valimail's 2026 State of DMARC, fewer than half of domains reach a DMARC policy of quarantine or reject. The bar is pass/fail; the configuration drifts.
Why does this check belong in CI?
Which points somewhere specific: authentication posture is configuration — records with correct and incorrect states that change when your stack changes. We don't pay someone to re-read the firewall rules every Tuesday; we put a check in the pipeline. Deliverability deserves the same.
That's what Amino's deliverability audit Action does: it checks SPF, DKIM, DMARC, MTA-STS and more on every push, writes a scorecard with the exact fix for each finding, and breaks the build before a regression ships. Read-only, no secrets, public DNS only. It doesn't replace the person who owns deliverability — it hands them the alarm they're being asked to be.
Try it in four steps
- Add it to a workflow. One step, pointed at your sending domain — it runs on every push and pull request:
- uses: hireamino/amino-audit-action@v1 with: domains: yourdomain.com - Start in advisory mode. The default never fails the build — you just get the scorecard. Zero-risk to adopt.
- Work the findings. Every gap comes with the exact fix — publish MTA-STS, add TLS-RPT, raise the DKIM key. Clear the list.
- Turn on enforcement. Once you're clean, set
fail-on: highso a future regression fails the build before it ships — and addcomment-on-pr: trueto surface it right in review.
What actually drifts, and how would you know?
Records break in a handful of predictable ways, and none of them produce an error anyone receives. In our scan of 117 companies hiring for this work, the posture gap is not the famous controls but the quiet ones: 92% publish SPF and 97% publish DMARC, yet only 74% enforce it, 2% publish TLS-RPT and 1% publish MTA-STS. The controls that report problems back to you are the ones almost nobody turns on.
| What breaks | Who notices | What you see on the day |
|---|---|---|
| SPF include stops resolving | Receivers | Nothing |
DMARC relaxed to p=none for a campaign | Nobody | Nothing |
| DKIM selector rotated but not published | Receivers | Nothing |
| SPF crosses the 10-lookup limit | Receivers | Nothing — SPF returns permerror for every message |
| A record is deleted outright | Receivers | Nothing, until the numbers sag |
The lookup-limit case is the sharpest illustration, because the failure is total and completely invisible. RFC 7208 §4.6.4 caps SPF evaluation at ten DNS lookups; cross it and SPF returns permerror for every message you send, from every server. Our measurement of the Fortune 50 found none over the limit but two domains sitting at eight and nine of ten — one provider decision away, and the provider gets to make that decision. You can count your own lookups in a few seconds.
Who checks the checker?
A monitor that under-reports is worse than no monitor, because it converts an unexamined risk into a false assurance. We found this in our own code. Our SPF lookup counter stopped following include: chains after three levels — a limit the RFC does not impose, since it caps total lookups rather than nesting depth. Running the Fortune 50 measurement surfaced it: one domain counted four lookups with the cap and five without.
The direction of that error is the whole point. An over-count is noise. An under-count reports a domain as comfortably under the limit while it may already be over it and failing on every message — precisely the alarm the number exists to raise. The regression test now walks a five-deep chain and asserts five. If you build the CI check yourself, write the test that proves it can fail before you trust the green tick.
What about the day you switch providers?
CI catches drift on a domain that is already configured. The other failure window is the cutover, when the records are new and nothing has been verified yet — a provider issues account-specific hosts that no generic checker can predict, and a sandbox domain passes every DNS test while belonging to someone else. That is what a go-live pre-flight is for, and it is a different question from “is my current setup still intact.” Both are worth automating; neither substitutes for the other.
- In CI, on every change: SPF resolves and stays under ten lookups, DMARC policy has not regressed, the DKIM selector you sign with is published.
- Before a cutover: the provider’s specific records exist, and you are not scoring a shared demo domain as ready.
- Continuously, in the background: something that re-reads the records and mails you when one changes, because not every break follows a commit.
Key takeaways
- Authentication fails silently at the source — no bounce, no error, no alert. The mail simply starts landing in spam.
- In our scan of 117 hiring companies, 97% publish DMARC but only 74% enforce it, and just 2% publish TLS-RPT — the controls that report problems back are the ones nobody enables.
- Crossing the SPF 10-lookup limit returns
permerrorfor every message, from every server, with nothing to indicate it happened. - Our own lookup counter under-reported nested chains until a measurement exposed it. An under-count is a false all-clear on the exact alert it exists to raise.
- CI catches drift; a pre-flight catches cutovers. They answer different questions and neither substitutes for the other.
FAQ
Why doesn't anything alert me when SPF breaks?
Because SPF is evaluated by the receiving mail server, not by yours. When an include stops resolving or the record crosses the ten-lookup limit, the receiver returns a failure to itself and applies your DMARC policy. Nothing is sent back to the sender. There is no bounce, no error and no dashboard change until aggregate engagement numbers sag weeks later.
What should an email authentication check in CI actually assert?
Four things, all of which are computable from public DNS: that SPF resolves and stays under RFC 7208's limit of ten DNS lookups, that the DMARC policy has not regressed to p=none, that the DKIM selector you actually sign with is published and at least 2048 bits, and that any MTA-STS policy still covers the current MX hosts. Each is binary, so each can fail a build.
Is a monitoring tool enough on its own?
Only if the tool itself is tested. We found our own SPF lookup counter stopping after three levels of include nesting, which under-counted real records. Under-counting is the dangerous direction because it reads as a false all-clear on the alert the number exists to raise. Whatever you build or buy, confirm it can fail before you trust it passing.
How is a go-live pre-flight different from a CI check?
A CI check verifies that a working configuration has not drifted. A pre-flight verifies that a brand-new configuration is correct before the first production send, which is a harder problem: providers issue account-specific hostnames no generic checker can predict, and a shared sandbox domain passes every DNS test while belonging to the provider rather than to you.
Sources
- Kitterman, S. RFC 7208, Sender Policy Framework (SPF). IETF Standards Track. §4.6.4 caps evaluation at ten DNS lookups and mandates
permerrorbeyond it. - HireAmino. What 117 companies hiring for deliverability actually publish in DNS — the source of the 92%, 97%, 74%, 2% and 1% figures.
- Google. Email sender guidelines — bulk-sender authentication requirements and the 0.30% complaint ceiling, in force since February 2024.