EmailFlow OS
Enter a domain and this free checker reads its SPF record, its DMARC record and a DKIM key from public DNS, then tells you in plain English what each one allows, what is missing and what would break delivery. No sign-up, no email address, nothing to install.
Three DNS names, each as a TXT query. SPF lives on the domain itself, for example example.com. DMARC lives one level below, at _dmarc.example.com. A DKIM key lives at selector._domainkey.example.com, where the selector is a name chosen by the service that signs your mail. The answers come from Cloudflare’s public resolver over DNS over HTTPS, so you see what a resolver on the open internet returns right now, independent of what your own network still has cached.
SPF (RFC 7208) lists the servers that may send mail for a domain. The receiver compares the address of the connecting server with that list, using the domain of the envelope sender, not the From line your reader sees. The checker reads three things from the record:
-all asks receivers to fail mail from unlisted servers, ~all marks it as a soft fail, ?all is neutral and +all lets every server on the internet pass.DKIM (RFC 6376) signs each message with a private key; the receiver fetches the public key from selector._domainkey and verifies the signature. DNS cannot list which selectors exist, so a checker has to know the name. Open a message you sent, view its source and look for s= in the DKIM-Signature header: that value is the selector, and d= is the signing domain. Google Workspace uses google unless you chose another prefix, and Microsoft 365 publishes selector1 and selector2 for custom domains. Other services, Brevo among them, show the exact record in their domain settings; copy it from there rather than from an old tutorial. A key with an empty p= value has been revoked (RFC 6376, section 3.6.1), and every signature that points to it fails.
DMARC (RFC 7489) connects SPF and DKIM to the domain in the visible From line. A message passes when SPF or DKIM passes for a domain that matches the From domain, which is called alignment. The record then tells receivers what to do with mail that fails: p=none only asks for reports, p=quarantine asks them to treat it as suspicious, usually the spam folder, and p=reject asks them to refuse it. The rua tag names the address for daily aggregate reports, which show every server that sent mail as your domain. If a domain publishes more than one DMARC record, receivers ignore DMARC for it altogether.
Since February 1, 2024, Google requires every sender to Gmail accounts to set up SPF or DKIM. Senders of more than 5,000 messages a day to Gmail accounts need SPF and DKIM, a DMARC record whose policy may be none, and a From domain aligned with the SPF or the DKIM domain (Google, Email sender guidelines, read on 24 October 2026). Yahoo began enforcing the same split in February 2024: SPF or DKIM for all senders, and for bulk senders SPF and DKIM plus a valid DMARC policy of at least p=none that passes (Yahoo, Sender Best Practices, read on 24 October 2026). Both pages add rules on unsubscribing and on spam rates, which a DNS check cannot see.
p=none and a rua address, read the reports until every legitimate sender passes, then move to quarantine and later reject.The setup order with examples is in DKIM, DMARC and SPF for cold email senders. If your DNS is at GoDaddy, the GoDaddy DKIM setup for Brevo senders covers the Host field that doubles your domain. On Google Workspace, read how to add the Google Workspace DKIM record next to Brevo’s.
EmailFlow OS sends every campaign through your own Brevo account and under your own domain, never from a shared platform address. You record one video, EmailFlow OS makes a personalized version of it for each recipient on your list and writes an email for each of them. Because the mail leaves under your domain, the SPF, DKIM and DMARC records this page checks are the ones receivers apply to your campaigns. The EmailFlow OS features page describes the sending setup step by step.
EmailFlow OS