When email drives revenue, someone has to own whether it lands

Table of contents

• Why are DTC brands suddenly hiring for whether email lands?
• Why is landing harder than sending?
• What does “from scratch” actually mean here?
• What evidence does an owner actually need?
• Why do most “someone is spoofing you” alerts turn out to be wrong?
• What should a new owner do in week one?

Why are DTC brands suddenly hiring for whether email lands?

In the past week, two direct-to-consumer brands — different categories, same story — each posted a role to own email and SMS lifecycle. Read past the marketing-manager title and what they're really assigning is an outcome: make the email that drives our revenue actually arrive. The common line gives it away — build the lifecycle program from scratch.

DTC runs on repeat purchase — replenishment, subscriptions, winback. The lifecycle email is the revenue engine, not a campaign calendar. So the outcome these brands need delivered isn't "more sends" — it's that the message reliably lands in the inbox, because that's what keeps the reorders coming.

Why is landing harder than sending?

And landing is the hard part. Composing the flows is solved — the sending platform does that. Whether the message reaches the inbox is a different discipline entirely. A replenishment reminder or an abandoned-cart flow that drops into Promotions or spam isn't a missed open; it's a missed reorder — revenue, directly. Consumer inboxes are the brutal end of deliverability — and a replatform resets the little trust you have, which is why a new platform inherits none of your good name: Gmail and Yahoo's bulk-sender rules raised the floor in 2024, spam-complaint thresholds are unforgiving, and one bad stretch drags the whole sending domain down with it.

What does “from scratch” actually mean here?

"From scratch" is the giveaway. It means the outcome has never actually been owned: no sender-reputation baseline, no list-hygiene discipline — and the bounce rate that follows is a list problem, not a sending one, no hardened authentication (SPF/DKIM/DMARC), no inbox-placement monitoring across email and SMS. One person is now expected to deliver all of it — and stand up the early-warning system while the sends keep going out every day.

Two brands, one week, same outcome, same "from scratch." This is becoming a recognizable moment: the point where "does the email arrive?" stops being nobody's job and becomes someone's explicit mandate. Most companies get there reactively — after a deliverability dip has already quietly eaten a month of reorders.

For now, the outcome gets assigned the only way companies know how — to a person. As every brand sends more, and sends it faster, the question that person owns only gets louder.

We have since measured that pattern rather than inferred it. Across 117 job postings from 117 distinct companies, every single one placed email ownership in a marketing-side seat — and when we audited all 117 sending domains, 62% already had clean outbound authentication. The person being handed the question is usually inheriting something that works, which makes access, not repair, the real problem: are companies really going to hand DNS administration to marketers?

What evidence does an owner actually need?

A single domain-wide pass rate is the wrong instrument, because it averages receivers that behave nothing alike. DMARC aggregate reports arrive per reporting organisation, so Google, Microsoft and Yahoo each tell you separately what they saw. Read together as one number, a domain can show 94% and look healthy. Read apart, the same week can be Google at 98% and Microsoft at 71% — and that 27-point gap is the actual finding, because both receivers are reading the same records for the same mail. A spread that size points at how one receiver handles your mail, not at your DNS.

This is the number an owner can be accountable for, and it is structurally unavailable from any single sending platform: an ESP sees only the traffic it sent. It comes from the reports mailbox providers already mail you, which most senders publish a rua address for and then never read. In our scan of 117 companies hiring for this work, 87% publish a rua address — the data is already being sent to almost everyone; the gap is that nobody is reading it.

Why do most “someone is spoofing you” alerts turn out to be wrong?

Because the most common source of a DMARC failure is legitimate mail handling, not an attacker. A forwarding service, a mailing list, or an inbound security gateway re-sends mail it did not originate, which breaks SPF by design. In the public corpora the single highest-volume source of benign DMARC failures is Gmail’s own send-as relay. An owner who treats every failing source as an intruder will spend their first month chasing forwarders, and an owner who ignores them will miss the one that matters.

The practical distinction is who the sending host is, not what its pass rate looks like:

• A dedicated sending service failing is a misconfiguration you own and should fix.
• An inbound security gateway failing is expected — it re-emits mail, so SPF cannot survive.
• A forwarder or mailing list failing is the mechanism working as designed.
• A platform that does both, like Microsoft 365, cannot be told apart from its hostname alone — and saying so is more useful than guessing.

Three things stay invisible no matter how good the DNS posture is, and an owner should say so out loud:

• Inbox versus spam placement — only seed inboxes measure it; no DNS check can.
• Engagement by segment — that history lives in the sending platform, not in DNS.
• Complaint rate per receiver — Google and Microsoft report it, but only to the domain that asks.

What should a new owner do in week one?

Ownership starts with a baseline, not a project plan. In order, and none of it requires access to the sending platform:

1. Confirm authentication with an authentication audit — SPF, DKIM, DMARC and alignment. Our scan found 97% of hiring companies publish DMARC but only 74% enforce it, so “we have DMARC” usually means p=none.
2. Check the sending IPs against the major blocklists, because a listing is silent and immediate. The blocklist checker finds the real sending infrastructure from your SPF record first.
3. Start reading the reports you are already being sent. Free monitoring ingests them and splits the pass rate by receiver, which is the number nobody can produce from an ESP dashboard.
4. Write down what you cannot yet see — inbox versus spam placement, and engagement by segment. Naming the gap is part of owning it.

Key takeaways

• A domain-wide DMARC pass rate averages receivers that behave differently — one can report 98% while another reports 71% in the same week on the same domain.
• The per-receiver split is structurally unavailable from any single ESP, because each sending platform sees only its own traffic.
• 87% of the 117 companies in our scan already publish a rua address, so the reports are arriving; almost nobody reads them.
• 97% publish DMARC but only 74% enforce it — “we have DMARC” usually means p=none, which asks receivers to do nothing.
• Most failing senders are forwarders and gateways, not attackers. Treating every failure as spoofing burns a new owner’s first month.

FAQ

What does a deliverability owner actually own?

The outcome that mail reaches the inbox, which decomposes into four measurable things: authentication that stays aligned as records drift, a known inventory of who sends as the domain, sender reputation including blocklist status, and list quality. Inbox-versus-spam placement is the one part no DNS check can measure; it requires seed inboxes, and an honest owner names that gap rather than implying it is covered.

Why split the DMARC pass rate by mailbox provider?

Because a single domain-wide figure is a weighted average over receivers that filter very differently. Google can report 98% while Microsoft reports 71% on the same domain in the same week. The gap is the finding: both are reading the same records for the same mail, so a large divergence points at one receiver's handling rather than at your DNS. No single ESP can produce this view because each sees only its own traffic.

If our DMARC record exists, are we protected?

Not usually. In our scan of 117 companies hiring for deliverability work, 97% publish a DMARC record but only 74% set a policy of quarantine or reject. A record at p=none asks receivers to take no action on failures; it turns on reporting, which is valuable, but it stops nobody from sending as you.

Is a source failing DMARC evidence that someone is spoofing us?

Rarely, on its own. Forwarding services, mailing lists and inbound security gateways all re-send mail they did not originate, which breaks SPF by design, and they account for most failures in practice. The useful question is who the sending host is rather than what its pass rate is: a dedicated sending service failing is your misconfiguration, while a forwarder failing is the mechanism working as intended.

Sources

• HireAmino. What 117 companies hiring for deliverability actually publish in DNS — the scan behind the 97%, 87% and 74% figures, audited against live DNS.
• Kitterman, S. RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC) — aggregate reporting, the rua tag and per-reporter structure.
• Yahoo. Sender best practices — the second half of the 2024 bulk-sender requirements, published alongside Google’s.
• Google. Email sender guidelines — bulk-sender authentication requirements and the 0.30% spam-complaint ceiling, in force since February 2024.