It started with an afternoon alert: someone was abusing our sites' sign-in form as a spam cannon — the one-time-code mailer could be pointed at arbitrary addresses. The AI added rate limits within the hour (per recipient they existed; per caller and globally they didn't). But the real damage arrived with a delay: shortly after, Microsoft blocked my personal address for outbound mail — the address the sign-in codes had been sent from. My most important e-mail address, frozen because my own sign-in page had been abused.
The plan was obvious: automated mail moves to its own address, noreply@carecom.de, cleanly separated from my mailbox. The AI knew the moves — new mailbox, permission for the sending application, settings on the servers. And then nothing worked anyway.
Two traps nobody sees
Trap one lived in Microsoft 365's fine print: new mailboxes are born with their SMTP sending path disabled, and that switch blocks before any permission check — the correctly granted permission never even got asked. The log said it plainly: “535 5.7.139 Authentication unsuccessful, SmtpClientAuthentication is disabled”. One admin command later, sending worked — and my personal address got the same switch in the opposite direction: explicitly closed to programs. The incident became a hardening.
Trap two only showed itself when the new address's first mail arrived — in the spam folder. The AI checked the three DNS records with which a domain proves who may send in its name: SPF fine, DKIM signature fine, but the DMARC policy — the record that tells receivers how strictly to check — answered with the wrong content. Instead of a policy, the main domain's text records came back.
The resolution came from a look at the DNS zone: “So it's not a stray _dmarc record — it's a wildcard CNAME. It catches every subdomain name that doesn't have its own entry.” A single, years-old placeholder record (*.carecom.de pointing at the main domain) answered every query for non-existent subdomains — including the spam filters' query for the DMARC policy. To every checker it looked as if there was an answer, just the wrong one. The fix was surgical: an explicit record for exactly _dmarc — which outranks the wildcard without touching it. And because such records live in caches for up to 24 hours, the AI verified the result directly against the authoritative name server rather than a public resolver: policy live.
Three domains green — and the stumbles on record
By the end of the afternoon, three site domains were sending with full authentication — checked, not assumed. Total time from abuse alert to “all green”: three and a half hours, waiting windows included.
The stumbles belong on record. Early in the migration the AI had declared that no DNS work would be needed — two hours later, DNS was exactly the problem. It got lost in Microsoft's object-ID thicket (“I think all of that was unnecessary,” was my summary of that detour). And it once misfiled an old failed attempt as a fresh test — “You're completely right — I had that wrong.” None of it was bad; all of it would have gone unnoticed if nobody had been thinking along.
The takeaway for your own domain: “works on my machine” means little in e-mail — whether your messages arrive is decided by three public DNS records you can have checked in minutes. And if an old wildcard record lives in your DNS zone: it also answers where you never intended any answer at all.
/compact — the essentials when context is scarce:
An abused sign-in form led to the personal sender address being blocked; the move to noreply@ hit two invisible traps: the SMTP switch that new Microsoft 365 mailboxes have disabled by default (blocks before any permission check, error 535 5.7.139), and a years-old wildcard DNS record answering the DMARC query with wrong content — mail landed in spam. Fix: one admin command plus an explicit _dmarc record that outranks the placeholder; verification straight against the authoritative name server. Three domains green in three and a half hours — with the AI's detours openly on record (DNS first declared unnecessary, ID confusion, a mixed-up timeline).