What Is Email Authentication
Email authentication is the set of DNS-based protocols that verify an email is actually authorized by the domain it claims to come from. Without it, anyone can forge an email that looks like it came from your domain; and most email systems have no way to know the difference.
Three protocols work together to close that gap: SPF, DKIM, and DMARC. None is sufficient alone. All three together create a chain that's hard to break.
SPF: Authorize sending IPs
SPF (Sender Policy Framework) publishes a DNS record that says "these IPs are allowed to send email from my domain." A receiving mail server queries your SPF record and checks whether the sending IP is on the list.
The catch: SPF only checks the envelope sender (the MAIL FROM address used by the SMTP protocol). It does not check the visible From: header that users see in their inbox. An attacker can pass SPF checks by sending from an authorized IP, then forging the From: header to look like your domain.
An SPF record looks like this:
v=spf1 include:_spf.google.com include:sendgrid.net ~all
The include: statements add IPs from other providers (Google Workspace, SendGrid, etc.). The ~all means "softfail everything else": messages from unauthorized IPs still deliver, but with a fail indicator.
SPF is necessary but insufficient. It stops lazy impersonation but not sophisticated spoofing.
DKIM: Cryptographic signature
DKIM (DomainKeys Identified Mail) works differently. Your mail server adds a cryptographic signature to every message it sends. The signature is bound to a specific domain (your domain) and a selector (a key identifier like default or google).
A receiving server uses your public DKIM key (published in DNS) to verify that the signature is valid and that the message has not been modified in transit. If the signature is valid, the receiving server knows the message came from a mail server that has access to your private key.
The signature survives most forwarding. If the forwarding service does not modify the message body or headers, the signature remains valid. That makes DKIM more robust than SPF for real-world mail flow.
But here's the problem: DKIM only proves that the message was signed by something with access to your key. It doesn't prove the signer authorized the message. And if a forwarding service modifies the message, the signature breaks.
DMARC: The policy layer
DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy layer. It says: "At least one of SPF or DKIM must pass, and the passing mechanism must align with my From: header domain. If that doesn't happen, reject the message; or quarantine it, or just monitor it."
Alignment is the key concept. SPF aligns if the envelope sender domain matches the From: header domain. DKIM aligns if the domain in the DKIM signature matches the From: header domain.
A DMARC record looks like this:
v=DMARC1; p=none; rua=mailto:reports@dmarcdrift.com; ruf=mailto:forensics@example.com
The p= tag sets the policy: none (monitor only), quarantine (soft reject, move to spam), or reject (hard reject, bounce).
The rua= address is where aggregate reports go. These reports arrive weekly and contain a summary of SPF and DKIM alignment across all mail from your domain.
Why you need all three
SPF alone is bypassed by forging the From: header. DKIM alone is vulnerable to modification during forwarding or replay attacks where the signature is valid but the sender is not authorized. DMARC enforces that at least one of them aligns with the visible sender; closing the spoofing gap.
DMARC also enables reporting. Once your DMARC record exists, you start collecting aggregate data about email traffic from your domain. That data tells you where mail is coming from, whether it passes authentication, and whether anything is failing unexpectedly.
Getting started
Start by publishing SPF and DKIM records for every mail service you use. Then add a DMARC record with p=none. This puts you in monitoring mode: legitimate mail still delivers, but you start collecting data.
Watch the reports for a few weeks. Once you see that legitimate mail is passing authentication and malicious attempts are failing, move to p=quarantine (soft reject) or p=reject (hard reject).
Use the email authentication checker to verify that all three records are published and that SPF and DKIM are aligned with your domain. The tool will show you exactly what's in each record and whether it would pass DMARC checks.
Once your DMARC record is live, aggregate reports will start arriving within 24–48 hours. DMARCdrift turns the XML into a readable digest; free for one domain.