How email authentication works
Email was designed without any check on who a message claims to be from, so anyone can put your domain in the From line. Authentication closes that gap by publishing proof in your domain’s DNS, where any receiving mail server can look it up. Three records do the work, and they are not alternatives — each answers a different question.
- SPF lists the servers allowed to send mail for your domain. The receiver compares the server that delivered the message against that list.
- DKIM adds a cryptographic signature to each message. The receiver fetches your public key from DNS and verifies the signature, which also proves the message was not altered on the way.
- DMARC ties the other two to the domain a human actually sees in the From line, and states your policy when a message fails: take no action, send it to spam, or reject it outright. It also asks receivers to send you reports on what is being sent in your name.
That last point is called alignment, and it is where most surprises live. A message can pass SPF for the sending platform’s own domain and still fail DMARC, because the domain that passed is not the one the recipient reads.
Why email authentication matters
Unauthenticated mail is treated as suspect, and the large mailbox providers have tightened their expectations of anyone sending in bulk. Without these records your invoices, quotes and campaigns are more likely to sit in spam, and a business whose email quietly stops arriving usually finds out from a customer rather than a report.
The second reason is impersonation. Without a DMARC policy, someone can send invoices or job offers that appear to come from your domain, and the damage lands on your name. A published policy of rejection tells receiving servers to refuse those messages before anybody reads them.
Common mistakes with email authentication
Publishing more than one SPF record for the same domain is the classic error: the standard allows only one, so a second added for a new tool breaks both. SPF also has a hard cap on how many DNS lookups it may trigger, and stacking one platform after another silently exceeds it, at which point the record stops passing.
The other frequent failures are jumping straight to a rejection policy before reading the reports, so legitimate mail from your invoicing tool or booking system disappears; leaving subdomains unprotected; and adding a new sending platform without updating anything. Authentication is also not a spam filter. It proves who sent the message, not that anyone wanted it, so poor sender reputation still lands you in the spam folder with all three records passing.
How to act on it
Start by listing every system that sends mail as you: the marketing platform, the website’s contact form, the CRM, the invoicing tool, the booking system. Each one needs to appear in SPF and to sign with DKIM. Publish DKIM keys per platform rather than sharing one, so a tool can be removed cleanly later.
Then introduce DMARC gradually. Publish it in monitoring mode first, read the reports until every legitimate sender is accounted for, and only then move to quarantine and rejection. Recheck the records whenever you add a tool, change host or migrate DNS, because a migration that drops a TXT record takes your authentication with it and the symptoms appear days later.