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.
Chong hit exactly this case on a customer domain: send.ohad.com was fully configured, but ohad.com itself had DKIM set only for the From address, with the rest of the chain missing. Every individual check looked fine in isolation. The alignment did not hold, so DMARC failed.
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
Set DMARC to p=quarantine or stronger. Outlook now requires SPF, DKIM and DMARC aligned at p=quarantine or above for senders above 5,000 messages a day, and a policy of 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.
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.
p=quarantine or stronger. Outlook requires SPF, DKIM and DMARC aligned at p=quarantine or above for senders above 5,000 messages a day.