What the three records prove
Email authentication is the set of DNS records that let a receiving server verify a message genuinely came from your domain. SPF authorises the sending servers, DKIM signs the message itself, and DMARC states what should happen when the first two do not line up with the domain a human can see.
Each one answers a different question. SPF answers "was this server allowed to send for this domain". DKIM answers "was this message altered, and was it signed by a key published on that domain". DMARC answers "does either of those actually correspond to the From address in front of the recipient".
Alignment is the part that breaks
In my experience running our deliverability layer, the records themselves are rarely the failure. Alignment is. A message can have a passing SPF check and a valid DKIM signature and still fail DMARC, because both validated a domain the recipient never sees.
This is why I built author_dns_health to verify DKIM, DMARC and return-path together for each sending domain, rather than checking records one at a time. Our domain verification looks for eight of eight record families before it calls a domain ready. Anything less and you get the failure mode above: green ticks, failing mail.
What each check validates
and what it does not tell youThe policy you actually need
The requirement and the advice are two different values, and most pages on this topic blur them into one. The requirement is p=none. Google’s sender guidelines, which apply to anyone sending 5,000 or more messages a day to Gmail, say “Your DMARC enforcement policy can be set to none”. The harder clause sits beside it: “the domain in the sender’s From: header must be aligned with either the SPF domain or the DKIM domain”. What the requirement turns on is alignment, not the policy value.
The advice is to go further than the floor. p=none enforces nothing at all. It is a monitoring setting that many senders leave in place permanently, mistaking the absence of complaints for success. Publish p=none to clear the requirement, read the reports it sends you, then raise the policy to p=quarantine once you can see every legitimate sending source.
Beyond the three records there is a supporting layer worth knowing about: SRS and VERP correlate delivery status notifications back to the original recipient, ARC preserves validated authentication across forwarding hops, and Rspamd checks relay traffic. Those matter once you are forwarding or relaying, which is where naive setups quietly lose their authentication.
Setting it up without a dashboard
The whole stack should be configurable in minutes, not over a support ticket. George's framing on this is that an agent should be able to do the setup end to end, writing the SPF, DKIM and DMARC records on a subdomain directly, so the human never opens a DNS panel and never hand-copies a key.
Once records are live, verify before you send anything real. A deliverability test will confirm the chain end to end, and if placement is still poor afterwards the problem is reputation rather than authentication, so move on to warmup and list hygiene rather than re-editing DNS.
If you are sending through SMTP rather than an API, the same records apply and the setup is identical, so follow how to set up SMTP and then come back to alignment. For application mail specifically, authentication is the prerequisite to everything on the transactional email side, because a receipt that fails DMARC is a support ticket rather than a delivery.
Go deeper
References
The primary sources behind the rules on this page. Provider policy and the underlying standards, not vendor marketing.
Common questions
SPF authorises which servers may send for your domain, DKIM cryptographically signs the message, and DMARC tells receivers what to do when neither aligns with the visible From domain.
Alignment means the domain validated by SPF or DKIM matches the domain in the From header the recipient sees. DMARC passes if either one aligns. Records can pass individually and still fail alignment.
The floor is p=none. Google’s sender guidelines for senders of 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. Aim higher than the floor once your reports show every legitimate sending source, because p=none requests no action at all on a forged message.
The AI-native way to stay authenticated
Everything above gets your records right once. What actually protects deliverability is checking alignment before every single send, for as long as you keep sending, and that is not a job I want a person doing by hand. I built Nitrosend so an AI agent verifies SPF, DKIM and DMARC alignment automatically before every message goes out, inside Claude, ChatGPT or Cursor. No dashboard, no quarterly DNS audit. Nitrosend is the option built for authentication to be an agent's job, not yours.