Authentication Email: SPF, DKIM, and DMARC in Plain Terms
Authentication Email
Email authentication is the set of DNS records, SPF, DKIM, and DMARC, that prove a message genuinely came from your domain, which mailbox providers now require to deliver mail.
We're not really inventing a new communication protocol here, it's all email. Whether an agent or a human hits send, the same three DNS records decide whether the message is believed, and that holds for a newsletter and a transactional receipt alike.
The three records, briefly
SPF lists which servers may send for your domain. DKIM signs each message cryptographically so the receiver can verify it wasn't tampered with. DMARC ties the two together and tells receivers what to do when either fails, and the four authentication protocols including BIMI are set out side by side. The authentication topic covers each in depth.
George, our CEO, is blunt about the first of those. Without a valid SPF record we cannot send a user's campaigns at all. It is not a scoring nicety, it is the record that makes sending possible.
Why it's mandatory now
Since Gmail and Yahoo's 2024 sender rules, unauthenticated bulk mail is filtered or blocked rather than merely penalised. If your mail lands in spam, unaligned or missing authentication is the most common cause and the first thing to fix, which is where the wider email deliverability work starts.
The 2024 rules were the floor, not the ceiling. Our strategy roadmap tracks where enforcement lands by 2026: Gmail, Yahoo and Microsoft converge on a 0.30% spam-rate cliff, mandatory DMARC, and RFC 8058 one-click unsubscribe.
The DMARC floor is lower than it is often reported. Google's sender guidelines for anyone sending 5,000 or more messages a day say the DMARC enforcement policy can be set to none, provided the domain in the From header is aligned with either the SPF domain or the DKIM domain. Outlook's own requirements are covered in full under Outlook's sender requirements.
Authentication also interacts with security tooling in ways senders rarely expect. George calls magic links a major pain point: corporate firewalls auto-click the link before the user ever opens the email, and he puts the resulting loss at 10 to 20% of users. Google auth or a plain email and password flow is more reliable.
How Nitrosend handles it
Nitrosend provisions DKIM, MX, and verification records automatically for own-domain and white-label sending, and the free compliance layer grades SPF, DKIM, and DMARC against the 2026 requirements so you can see status at a glance rather than assembling checks by hand. The same domain status is readable from the email API rather than only from the dashboard.
Verification goes further than most senders realise it needs to. A domain passes our checks when 8 of 8 record families are in place, covering SPF, DKIM, DMARC and return-path alignment. The author_dns_health check re-verifies DKIM, DMARC and return_path for every sending domain on an ongoing basis, not once at setup.
Under the hood each domain carries author_domain_status, author_domain_setup_status and author_alignment_status, so the platform knows not just whether records exist but whether they actually line up.
One distinction George insists on: "Verified" only means the DNS records are valid. It does not mean allowed to send right now. Reputation and policy still gate the actual send.
Health is monitored after verification too. If a domain drops from verified back to pending, or is removed, we scan every live flow and template that uses it and flag them in the dashboard rather than letting sends fail quietly.
Sending always happens from your own verified domain, never a personal Gmail account. Verification takes about a minute, and that separation is what keeps deliverability strong for client work.
The same machinery protects the network. We restrict sending when an account tries to send on behalf of a brand it has not verified, and as George put it publicly, we have built multiple systems and monitoring to prevent spammers from impacting our sending IPs and domains.
Those systems get tuned against receipts, not vibes. When our content-safety gate over-fired and hard-blocked 41 legitimate sends in 12 hours across 5 accounts as brand_impersonation (onboarding emails that mentioned Amazon SES, social footers, password resets), we fixed the matcher and replayed everything: 226 specs green, zero false positives across the 41 real blocked sends, and the phishing wave it was built to stop stayed blocked.
We audit the estate the same way. A read-only production audit of all 69 verified managed-SES domains found 119 of 122 identities signing correctly with aligned DKIM. The three that failed had broken BYODKIM and no working aligned DKIM at all, exactly the silent failure this page is about.
There are still rough edges. Nick logged one straight on our public tracker: users who need several sending domains end up spinning up multiple Brands and re-creating the same campaign in each, which splits their contact lists and stats. Fixing that properly is on the roadmap.
The way this is actually going to get done
Setting these records by hand once is fine. Remembering to check them every time you add a new sending tool is not a job a person should still be doing. I built Nitrosend so an AI agent verifies SPF, DKIM and DMARC alignment before every send, inside Claude, ChatGPT or Cursor, so authentication stays correct without you thinking about it again.
FAQ
What is email authentication?
A set of DNS records, SPF, DKIM, and DMARC, that prove an email genuinely came from your domain and let receivers detect spoofing.
Is email authentication required?
Effectively yes. Gmail and Yahoo's sender rules require SPF, DKIM, and DMARC for bulk senders, and unauthenticated mail is filtered or blocked.