Spot the bug.

Two SPF records means no SPF. Receivers return permerror and stop, so every sender you had authorised loses its authorisation at the same moment. The fix is one record with both includes in it.

Nothing here is provably wrong from the DNS alone — and that is the trap. The tenant hostname is the one value no rule can derive, so it gets a mandatory human check against the mail provider’s own console. That check cannot be switched off for anybody.

The site will load beautifully from your desk. Meanwhile some resolvers honour the CNAME and drop everything else at the apex, including the MX — so mail goes intermittent, per-resolver, and "it works for me" is true for everyone who says it.

It resolves for nobody outside the office, so the name looks configured and answers with something unreachable — the hardest fault to chase, because the record is right there. It also publishes the shape of the client’s internal network to anyone who asks.

Eleven includes, and the limit is ten. Past it, evaluation returns permerror and SPF fails for the whole domain — including the ten senders that worked yesterday. Nobody is warned; you cross the line by adding a vendor, and the vendor that breaks is not the one you added.

Every record here is correct. It is simply un-moveable: at 86400 the old address stays cached for a day after you change it, and so would a rollback. The window to fix this closed on Thursday.