What the specs actually say, what receivers actually do, and what that means for your domain.
A Resend domain is a handful of DNS records, and most failed verifications come down to a few repeat mistakes: the return-path SPF record on the root, a half-built send subdomain, a DNS host appending your domain, a receiving MX that loses to your mailbox, an SPF include Resend never published. Why each one breaks, how to check it, and the records that look wrong but aren't.
Read the postFrom November 2026, Spamhaus is rolling out a rule that every IP sending mail have reverse DNS that points back to it, and a HELO name that resolves to it. Big providers handle it for you. Office lines, self-hosted servers and web hosts often don't. How to check yours, and the two ways to fix it.
Read the postSPF, DKIM and DMARC each check something narrower than it looks, and the gaps catch people who have read the specs. Fourteen beliefs that don't hold up, what the RFCs actually say, and what to do about each.
Read the postGoogle Workspace, Intercom, Resend, Loops and Stripe each verify their own records. None of that proves every service sending as your domain is set up correctly. What each one puts in your DNS, and five ways the combination breaks.
Read the postA candid map of the DMARC software market: free visibility tools, report analyzers, authentication platforms, enterprise programs, deliverability suites, and open source — and how to tell which one you actually need.
Read the postRFC 9989 formally warns general-purpose domains off p=reject — and prescribes a monitoring-first ramp instead. Who it applies to and how to climb it.
Read the postRFC 9989 removed pct because receivers never reliably implemented it. What replaced it (t=y), why pct=0 mattered, and the 30-second fix for each value.
Read the postDMARC is finally a real IETF standard. What the new RFCs change — pct removed, the np tag, the DNS Tree Walk — and the five-minute checklist for your own record.
Read the post