A vendor flagged our DMARC record, here's why that was fine

What actually happened

Nothing dramatic. Someone on the vendor's technical side was going through our estate, spotted a domain still sitting on a monitoring policy, and dropped us a note asking whether we knew.

We did, and we said so. But it's a fair question and a good habit, the kind of check-in you actually want from a supplier, rather than the quarterly "how are you finding the platform" call.

The domain came to us that way: new client, inherited estate, mail authentication already on the list. The record wasn't neglected, it was mid-project.

Why "not enforcing" isn't automatically a failure

This is the bit a dashboard can't tell you.

A DMARC policy at p=none looks like nothing is happening. On an inherited domain, it's often the only responsible setting for the first few weeks, you can't safely enforce a policy until you know every system that legitimately sends as that business. And on a client you've just taken on, you don't. Nobody does on day one.

There's the tenant, obviously. Then the accounts package, the CRM, the booking system, the e-signature tool, the mailshot platform, the recruitment portal, the photocopier, and the one service somebody set up in 2019 that still fires a monthly report. None of that is documented. Most of it isn't in the handover. Switch to reject before you've found them all and you don't get security, you get a client whose invoices stop arriving, and a very short conversation about why.

What a discovery phase actually looks like

It's unglamorous and it's mostly waiting.

You put a DMARC record in place with reporting turned on, aimed somewhere the reports get read rather than a mailbox nobody opens. Then you let it run, the aggregate reports tell you precisely who is sending as that domain and whether they're passing.

Every legitimate sender that shows up failing gets fixed at source: SPF entry where it belongs, DKIM signing enabled and verified. Every sender you can't identify gets chased down until you can, because "probably fine" is not something you want to be relying on when you tighten the policy.

On an inherited domain that hasn't been enforcing (naughty, naughty), you spend a few weeks at none while the reports come in, then move to quarantine while you tidy up the stragglers, and only flip to reject once you're genuinely happy nothing legitimate is left outside it. Weeks, not an afternoon.

Two things are worth doing immediately, because they carry no risk. Lock down the parked domains, old trading names, campaign domains nobody uses, straight to reject, since there's no legitimate mail there to break. And clean out the SPF record while you're in there, because inherited records are usually stuffed with decommissioned services and drifting towards the DNS lookup limit.

Why it matters beyond spoofing

Worth saying, because it changes the business case.

The large mailbox providers now treat authentication as a condition of delivery, not a bonus. Bulk senders without proper SPF, DKIM and a DMARC record get throttled or junked. If a client's marketing has quietly stopped landing, this is one of the first places to look.

So it isn't only that nobody can trade on their name. It's that their own mail actually arrives.

What we'd do differently

Honestly, not much on this one. It's more an argument for making mail authentication a standard part of onboarding rather than something you get to eventually.

Run the lookup on day one of every new client, on every domain they own, not just the one on the letterhead. Get the reporting record in early, because the clock on discovery only starts when the data starts flowing. And write down where you got to, so that when someone checks in and asks, the answer is a status rather than a scramble.

If you've inherited a domain and you've no idea what's sending as it, that's the normal starting position. Finding out is the work.