Two domains, ours, before and after

Domain one

dps.sbs — sitting exactly on the ten-lookup limit, reporting to nobody, signing as somebody else

A small operations company. One mailbox, ops@dps.sbs, on Google Workspace, with a domain that had been through a web host at some point in its life. Nothing had gone wrong. Nobody had complained. That is the normal condition of a domain with these faults.

Fault 1 — no headroom left at all

The sender list was full

# as found
v=spf1 +a +mx +ip4:162.0.209.62 +ip4:184.94.213.127
       include:spf.web-hosting.com include:_spf.google.com ~all

SPF permits a maximum of ten DNS lookups while a record is being evaluated. This record used exactly ten. Not close to the limit — on it. Add one more service, a newsletter tool or a booking system, and the record stops being evaluated at all: the receiver returns permerror and the domain has no working SPF. Not the new entry. The whole record.

Two of those mechanisms did nothing whatsoever. +a authorises the web server's address, which here is Cloudflare's and never sends mail. +mx authorises the incoming mail servers, and incoming servers do not send. Removing them cost nothing and bought two lookups back:

# now — 8 lookups, two spare
v=spf1 ip4:162.0.209.62 ip4:184.94.213.127
       include:spf.web-hosting.com include:_spf.google.com ~all

Still not comfortable. One include — spf.web-hosting.com — accounts for seven of the remaining eight, and we do not yet know whether anything still sends from there. That is what the reports in Fault 2 are for. It gets removed on evidence, not on a hunch.

Fault 2 — the evidence was being thrown away

DMARC was switched on and addressed to nobody

# as found
v=DMARC1; p=none;                       ← no rua=

# now
v=DMARC1; p=none; fo=1; rua=mailto:ops@dps.sbs

Every serious mail receiver in the world is willing to send this domain a daily report naming every server that sent mail using its name, and whether that mail authenticated. For free. Nobody had asked them to. The record looked configured — a checker that only tests for the presence of a DMARC record would have passed it — and it collected nothing.

This is the change we make first on every domain, because it costs nothing, breaks nothing, and every later decision depends on the information it starts gathering.

Fault 3 — the one you can only see in a delivered message

Mail was signed, but not as dps.sbs

Google Workspace will sign outgoing mail with the domain's own key — but only once somebody generates that key and publishes it. Until then Google signs with a fallback domain of its own. The DNS looks fine. The mail looks signed. It is signed by the wrong name.

Here is the header of a real message from ops@dps.sbs, delivered 5 September 2026:

# before
DKIM-Signature: d=dps-sbs.20251104.gappssmtp.com; s=20251104
Authentication-Results: mx.google.com;
   dkim=pass header.i=@dps-sbs.20251104.gappssmtp.com
   spf=pass  smtp.mailfrom=ops@dps.sbs
   dmarc=pass (p=NONE) header.from=dps.sbs

Read that carefully. Everything says pass. But the signature identity is dps-sbs.20251104.gappssmtp.com, which does not align with the From address, so DMARC passed on SPF alone. SPF is the half that does not survive forwarding. The moment a recipient's system forwards that message onward — a Mimecast gateway, a Google group, a personal redirect — the SPF result is gone, the signature never aligned in the first place, and the message fails DMARC outright.

The same sender, after publishing a 2048-bit key on the google selector, 6 September 2026:

# after
DKIM-Signature: d=dps.sbs; s=google
Authentication-Results: mx.google.com;
   dkim=pass header.i=@dps.sbs header.s=google
   spf=pass  smtp.mailfrom=ops@dps.sbs
   dmarc=pass header.from=dps.sbs

Now both identities align independently. Lose one and the message still authenticates. That is the whole point of having two.

Domain two

dubaiparfem.shop — reports addressed to a domain that had not agreed to receive them

A small webshop. Its DMARC record was more complete than the first domain's, and had been set up by the platform used to build the site. It named a reporting address:

# as found
v=DMARC1; p=none; rua=mailto:dmarcreports@lovable.dev

When the reporting address is on a different domain from the one being reported on, RFC 7489 §7.1 requires the receiving domain to publish a record giving its permission — otherwise a sender has a way to point a firehose of reports at any third party it dislikes. The permission record for this pairing would have to exist at:

dubaiparfem.shop._report._dmarc.lovable.dev   TXT   NXDOMAIN
# checked against three independent resolvers — it does not exist

So conforming receivers were declining to send the reports, and the ones that did send them delivered them to a mailbox belonging to somebody else. Either way the shop's owner saw nothing. On paper the domain was monitored. In practice it had never received a single report, and no tool that merely checks whether a DMARC record exists would have said otherwise.

The shop also had no DKIM key of its own — the same fallback-signature situation as the first domain. Both were fixed the same day:

# now
v=DMARC1; p=none; fo=1; rua=mailto:prodaja@dubaiparfem.shop
google._domainkey.dubaiparfem.shop  TXT  v=DKIM1; k=rsa; p=…  ← 2048-bit

Reports now go to a mailbox on the same domain they describe, which needs no permission record and cannot silently stop working. And a delivered message from prodaja@dubaiparfem.shop, the same evening:

DKIM-Signature: d=dubaiparfem.shop; s=google
Authentication-Results: mx.google.com;
   dkim=pass header.i=@dubaiparfem.shop header.s=google
   spf=pass  smtp.mailfrom=prodaja@dubaiparfem.shop
   dmarc=pass header.from=dubaiparfem.shop

	dps.sbs	dubaiparfem.shop
SPF lookups	10 of 10 → 8	4 of 10 — unchanged
Aggregate reports	nowhere → ops@dps.sbs	unauthorised third party → prodaja@dubaiparfem.shop
Signature identity	gappssmtp.com fallback → d=dps.sbs, 2048-bit	none → d=dubaiparfem.shop, 2048-bit
DMARC alignment in delivered mail	SPF only → SPF and DKIM	SPF only → SPF and DKIM
Policy	p=none — deliberately unchanged	p=none — deliberately unchanged

What this does not show

Both domains are still at p=none, on purpose

It would have taken thirty more seconds to set both to p=quarantine and finish this page with a stronger sentence. We did not, and the reason is the whole argument for the service.

Neither domain has yet received a single aggregate report — the address to collect them only started existing on 6 September 2026. Until a fortnight of reports has arrived, nobody knows what else sends mail as these domains. An old booking system. A newsletter tool from two years ago. An accountant's invoicing platform. Enforcing a policy before that evidence exists is how a business discovers, from a customer, that its order confirmations stopped arriving.

So the sequence is fixed and it is slow on purpose: collect first, enforce second. Reporting on day one, because it is free and risks nothing. Signature and alignment next, because they only make legitimate mail stronger. Policy last, on evidence. Anyone who moves a live domain to reject in one sitting is guessing with somebody else's mail.

Three other things this page is not:

Not a client engagement. We own both domains. There was nobody to persuade, no change window, and no third party who could have made it harder — which is the easy half of the work removed.
Not a claim about outcomes. Nothing here says anyone's deliverability improved, because two days of data cannot show that and we are not going to pretend otherwise.
Not somebody else's fault. The webshop's reporting address was a sensible default from the platform that built the site, not negligence. Defaults are simply not the same thing as a configuration somebody checked.

When the policy does move, this page gets updated

Both domains go to p=quarantine once their reports account for every sender, and the dates will be added here — including if something unexpected turns up and delays it. A case study that only ever records good news is a brochure.

Three faults on a live business domain, found from outside in about a minute

Because a case study you cannot check is a claim, not evidence