You hit send on an invoice. The client never replies. A week later you find out it was sitting in their junk folder the whole time — right next to the pharmacy spam and the Nigerian prince.
That's not bad luck. That's a DNS problem, and it's fixable in an afternoon.
Gmail, Outlook, and Yahoo have no way to know that an email claiming to be from yourcompany.com is genuinely from you. Anyone on the planet can type your address into the "From" field. So instead of trusting the envelope, inbox providers check your domain's DNS records for cryptographic proof.
No proof? At best you land in spam. At worst you get silently dropped.
In February 2024, Google and Yahoo made this official: bulk senders must authenticate with SPF, DKIM, and DMARC or their mail gets rejected. That bar has only risen since. If you're still running a bare domain in 2026, you're not "probably fine" — you're on borrowed time.
Sender Policy Framework is a public list of the servers permitted to send on your behalf: Microsoft 365, Google Workspace, your CRM, your invoicing tool, your marketing platform. If a message arrives from somewhere else, it fails SPF.
The catch is a hard limit of 10 DNS lookups. Add a few SaaS tools and you blow past it — at which point SPF silently stops working entirely. Most businesses that "already set up SPF" are quietly over the limit and have no idea.
DomainKeys Identified Mail signs every outgoing message with a private key. The receiving server checks the signature against a public key in your DNS. If the message was altered in transit — or forged outright — the signature breaks.
DMARC is where it gets useful. It tells inbox providers what to do when SPF and DKIM fail, and — critically — asks them to send you reports.
Those reports are the whole game. Within 72 hours of publishing a DMARC record you'll see every service sending mail as your domain, including the ones you forgot about and the ones you never authorized.
There are three policy levels:
p=none — Monitor only. Nothing is blocked; you just collect data.p=quarantine — Failures go to spam.p=reject — Failures are refused outright. This is the goal.This is the single most common way businesses break their own email.
Publishing p=reject on day one feels decisive. What actually happens is your accounting software, your appointment reminders, and your newsletter all start bouncing — because nobody realized those systems were sending as your domain and were never included in SPF.
The safe sequence:
p=none. Zero risk. Nothing changes for your mail flow.p=quarantine. Watch for fallout.p=reject. Now spoofers are blocked and you know nothing legitimate breaks.Once authentication is solid, a few more records are worth publishing:
p=reject first, which makes it a genuine reason to finish the job.You don't have to guess where you stand. Our free domain analyzer scans your DMARC, SPF, DKIM, BIMI, and MTA-STS records instantly — no signup, no credit card. You'll see exactly what's missing.
Most businesses we scan are missing at least one record. A surprising number have an SPF record that's been silently broken for years.
You can absolutely do this yourself. The records are free to publish; the hard part is reading XML aggregate reports every week and knowing what to do when a new sending service appears.
If you'd rather not, we handle it end to end:
Every plan includes managed setup — we publish the records and walk you from p=none to p=reject without breaking your mail flow. No contracts, cancel anytime.
There's also a free 14-day trial with no credit card required. We'll deploy monitoring, collect real reports from Gmail and Outlook, and show you exactly who's sending mail as your domain. Keep the DNS records whether you stay or not.
Email authentication isn't optional anymore. Without it you're losing invoices to spam folders, and anyone who wants to impersonate your brand can do it for free.
Start with p=none, read the reports, fix what's broken, then enforce. Or let us do it and get on with running your business.