Email was not built with authentication in mind, so the industry bolted it on with three mechanisms: SPF, DKIM, and DMARC. Together they answer one question — can this message be trusted to come from where it claims? If you receive mail on your own domain, understanding them is the difference between confident routing and guessing.
SPF — who is allowed to send
Sender Policy Framework is a DNS record listing the servers permitted to send mail for a domain. When a message arrives, the receiver checks the sending server against that list. A pass means the source is authorized; a fail is a strong signal of spoofing.
DKIM — was it tampered with
DomainKeys Identified Mail attaches a cryptographic signature to each message, tied to a public key in DNS. The receiver verifies the signature to confirm the message was not altered in transit and genuinely came from the signing domain.
DMARC — what to do on failure
DMARC ties SPF and DKIM together and tells receivers how to handle failures — monitor, quarantine, or reject — while sending you reports on what is happening.
- SPF proves the server is authorized.
- DKIM proves the content is intact.
- DMARC sets policy and reporting on top of both.
SPF checks the envelope, DKIM checks the contents, DMARC decides the consequences.
What this means when you receive
On the inbound side, authentication results are signal. A message that fails all three deserves more scrutiny than one that passes cleanly. Good inbound infrastructure verifies these on arrival and surfaces the results, so your routing rules can treat authenticated mail differently from suspicious mail.
Getting set up
When you connect a domain, guided checks for SPF, DKIM, and DMARC catch misconfigurations before they cause silent failures. Get the records right once and authentication becomes invisible infrastructure that quietly protects every workflow downstream.