SPF DKIM DMARC Checker for Resend and Cloudflare

What each record proves

SPF lists the servers allowed to send mail for a domain. Receivers check it against the domain in the return path, the envelope sender a bounce goes back to, not the From address people see.

DKIM signs each message with a private key. The public half sits in DNS at <selector>._domainkey.<domain>, and a valid signature proves the message left a server holding that key and wasn't changed on the way.

DMARC ties both to the From address. A message passes when SPF or DKIM passes for a domain that aligns with From, and the DMARC record tells receivers what to do with mail that doesn't and where to send reports about it.

Why your SPF record is on a subdomain

Transactional providers handle bounces themselves, so they put a subdomain of yours in the return path. Resend uses send.<domain> unless you chose another name when you added the domain, and Cloudflare Email Sending uses cf-bounce.<domain>. Receivers look up SPF on that host, so that is where the provider asks for SPF and an MX record, and a checker that reads only the bare domain reports a failure that isn't there.

Google Workspace and Microsoft 365 send with your own address as the return path, so their SPF belongs on the domain itself. Amazon SES uses a subdomain of amazonses.com until you set a custom MAIL FROM domain. Until then SPF passes for Amazon rather than for you, and DMARC has to rely on DKIM.

The SPF lookup limit

Every include, a, mx, ptr, exists and redirect costs a DNS lookup when a receiver evaluates the record, and so does every such term inside the records you include. Past the limit in the table below, receivers stop with a permanent error and SPF fails for every message. Lookups that find nothing have a smaller limit of their own.

The checker follows each include and redirect through DNS and adds them up the way a receiver does. a, mx, ptr and exists count without being resolved. If a record is close to the limit, move a sender to its own subdomain rather than replacing its include with addresses that will change under you.

DMARC after RFC 9989

RFC 9989, published in May 2026, replaces RFC 7489 and puts DMARC on the standards track. Three tags are gone: pct, rf and ri. Receivers ignore them, and the checker points them out. pct was mostly used as pct=0, which some forwarders took as a cue to rewrite the From header. That job now belongs to t=y, which asks receivers to apply the policy one level down.

Two tags are new. np sets the policy for subdomains that don't exist, and psd lets a domain say where its organizational boundary is. Receivers no longer need a public suffix list: when a domain has no record of its own, they walk up the DNS tree to find one. The checker does the same and shows which name the policy came from.

Alignment

DMARC passes only when SPF or DKIM passes for a domain that matches the From address. Relaxed alignment, the default, accepts any domain under the same organizational domain, so a return path of send.example.com aligns with mail from example.com. Strict alignment, aspf=s or adkim=s, wants the exact domain. A provider's bounce subdomain then fails SPF alignment and leaves DKIM to carry DMARC. The DKIM keys these providers ask you to publish sit under your own domain, so DKIM aligns in either mode.

Set up your provider

Resend lists its records on the domain's page and can add them to Cloudflare DNS for you (Resend docs). Cloudflare Email Service adds its sending records under cf-bounce and its routing records on the domain itself when you onboard the domain, and it adds a DMARC record too (Cloudflare docs). Read what that record says before you change it, and use the DMARC record generator to build the next stage.