Email authentication is a set of three DNS-based standards (SPF, DKIM, and DMARC) that let receiving mail servers verify that messages claiming to come from your domain are actually sent by you. Without them, anyone can forge your From address, and inbox providers like Gmail have no technical basis for trusting your mail. This guide covers what each record does, what it cannot do on its own, and how the three work together during message evaluation.
Why Email Spoofing Is a Serious Problem
Email’s original design had no concept of sender verification. The SMTP protocol, standardized in the 1980s, accepts whatever domain is placed in the MAIL FROM and From: headers. Any server can claim to be @yourcompany.com.
Attackers exploit this routinely. According to the Verizon 2024 Data Breach Investigations Report, phishing and pretexting together represented 73% of breaches within the social engineering pattern. Domain spoofing is the technical enabler: a message appearing to come from a trusted brand is far more likely to be opened.
Authentication standards close this gap by giving receivers something they can verify cryptographically or through DNS, rather than relying on the sender’s word.
SPF: Declaring Which Servers May Send for Your Domain
Sender Policy Framework (SPF), defined in RFC 7208, lets you publish a list of IP addresses and hostnames that are authorized to send email on behalf of your domain. Receivers check this list during the SMTP conversation, before the message body is even transmitted.
SPF authorizes the hosts that are allowed to use your domain names, and a receiving host can check such authorization by querying your DNS.
What an SPF Record Looks Like
SPF is a single TXT record published at your root domain:
yourdomain.com. IN TXT "v=spf1 include:_spf.youresp.com ip4:203.0.113.5 ~all"Breaking this down:
v=spf1identifies this as an SPF record.include:_spf.youresp.comdelegates authorization to your ESP’s IP ranges.ip4:203.0.113.5explicitly authorizes a specific IP (useful for a dedicated sending server).~allis a softfail: mail from unlisted sources should be treated with suspicion, but not outright rejected. Use-all(hardfail) once you are confident every legitimate source is listed.
What SPF Does NOT Protect Against
SPF validates the envelope sender (the MAIL FROM address used during the SMTP handshake), not the From: header the recipient sees in their email client. An attacker can send from [email protected] while displaying From: [email protected]. SPF on yourcompany.com will pass because the envelope domain is different. This is the gap that DMARC closes.
SPF also has a hard limit of ten DNS lookups per evaluation. Records with too many include: directives fail silently, causing legitimate mail to bounce.
DKIM: Signing Messages with a Cryptographic Key
DomainKeys Identified Mail (DKIM), defined in RFC 6376, works differently. Instead of checking the sending IP against a list, DKIM attaches a cryptographic signature to every outgoing message. The signing key is private (kept by your mail server or ESP). The corresponding public key is published in your DNS.
When a receiver gets the message, they retrieve your public key and use it to verify the signature. If the signature matches, they know the message was signed by someone who controls your domain and that the signed headers and body have not been altered in transit.
DKIM permits a person, role, or organization that owns the signing domain to claim responsibility for a message by associating the domain with the message through a cryptographic signature that receiving systems can validate.
What a DKIM DNS Record Looks Like
DKIM records live at a subdomain based on a selector (a label your ESP assigns) plus ._domainkey.yourdomain.com:
selector1._domainkey.yourdomain.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQ...AQAB"v=DKIM1marks this as a DKIM public key record.k=rsaspecifies RSA as the key algorithm.p=...is the base64-encoded public key your ESP generates.
You will typically have one selector per sending service. If you send via your transactional platform and separately via a marketing tool, each will have its own selector and key pair.
What DKIM Does NOT Protect Against
DKIM signature verification confirms that the signing domain authorized the message. It does not confirm that the signing domain matches the From: address the recipient sees. A message signed by dkim.thirdpartyplatform.com while displaying From: [email protected] can pass DKIM but still misrepresent the sender. Again, DMARC handles this.
DKIM also does not prevent replay attacks: a valid signed message can technically be retransmitted. Practical mitigations include short key rotation schedules and timestamped headers.
DMARC: Policy, Alignment, and Reporting
Domain-based Message Authentication, Reporting, and Conformance (DMARC), defined in RFC 7489, sits on top of SPF and DKIM. It does three things:
- Defines a policy telling receivers what to do with mail that fails authentication (
none,quarantine, orreject). - Enforces alignment, meaning the authenticated domain must match the
From:header the user sees. - Enables reporting, sending aggregate and forensic reports back to you so you can monitor who is sending email on behalf of your domain.
What a DMARC Record Looks Like
DMARC is published at _dmarc.yourdomain.com:
_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; adkim=r; aspf=r"v=DMARC1marks this as a DMARC record.p=quarantineinstructs receivers to place failing mail in spam. Usep=noneto start in monitoring mode; escalate toquarantine, thenrejectonce you understand your mail flows.rua=mailto:...sends aggregate XML reports to that address (or a third-party reporting service).adkim=randaspf=rset alignment to relaxed, meaning subdomains of your domain are allowed to match.
The DMARC Setup Guide
Configuring DMARC step by step, including how to read aggregate reports and safely move from p=none to p=reject, is covered in our How to Set Up DMARC (Step-by-Step Guide).
SPF vs. DKIM vs. DMARC: What Each One Does
| SPF | DKIM | DMARC | |
|---|---|---|---|
| What it authenticates | Sending IP/server | Message signature | From: header alignment |
| Where it lives | DNS TXT at root domain | DNS TXT at selector._domainkey. | DNS TXT at _dmarc. |
| Protects against | Unauthorized servers sending from your domain | Message tampering in transit | Domain spoofing visible to the recipient |
| Survives forwarding? | No (forwarded mail changes the envelope IP) | Yes (signature travels with the message) | Depends on which authentication passes |
| Key limitation | Validates envelope sender, not From: header | Validates signing domain, not From: header | Requires at least one of SPF or DKIM to pass and align |
| Maximum DNS lookups | 10 | None (key fetched once per selector) | N/A |
How a Receiver Evaluates a Message: Step by Step
Understanding the sequence helps explain why SPF can pass while DMARC fails, which trips up many engineering teams.
Step 1: SMTP connection. Your server connects to the receiver’s MTA and initiates the SMTP conversation, presenting the envelope sender domain in MAIL FROM.
Step 2: SPF check. The receiver queries the SPF record of the MAIL FROM domain and checks whether your sending IP is listed. Result: pass, fail, softfail, or neutral.
Step 3: DKIM verification. The receiver reads the DKIM-Signature header in the incoming message, retrieves your public key from DNS using the selector, and verifies the signature against the message headers and body. Result: pass or fail.
Step 4: DMARC evaluation. The receiver fetches your DMARC record from _dmarc.yourdomain.com and applies two checks:
- Did SPF pass, AND does the
MAIL FROMdomain align with theFrom:header domain? - Did DKIM pass, AND does the
d=domain in the DKIM signature align with theFrom:header domain?
DMARC passes if at least one of those two conditions is true.
Step 5: Policy application. If DMARC fails, the receiver applies the policy from your record: none (deliver anyway, report), quarantine (route to spam), or reject (bounce).
Why SPF Can Pass But DMARC Still Fails
The most common confusion: your SPF record passes, so why is DMARC failing?
SPF alignment requires that the MAIL FROM domain match the From: header domain. Many ESPs use their own domain in MAIL FROM (the Return-Path), which is what SPF validates. So SPF passes for the ESP’s domain, but that domain does not align with your From: @yourdomain.com. DMARC alignment fails.
The fix is either to configure a custom Return-Path (MAIL FROM) on your sending domain, or to ensure DKIM alignment passes instead (by signing with your own domain via a DKIM key on your DNS). A good transactional email platform handles both; see our overview of the best transactional email services compared to understand how ESPs differ on DKIM signing and Return-Path customization.
This relationship between DMARC alignment and deliverability is also part of why emails end up in spam even when senders believe they are “authenticated.” The why do my emails go to spam guide covers the broader list of deliverability factors. Authentication failures also surface as hard bounces with a 5.7.1 SMTP code; the soft bounce vs. hard bounce guide explains how to handle those correctly and protect your sender reputation.
The February 2024 Requirement: Now Industry Standard
Starting February 1, 2024, Google requires senders of 5,000 or more messages per day to Gmail addresses to have SPF, DKIM, and DMARC all configured. Yahoo/Yahoo Mail imposed parallel requirements on the same timeline. According to Google’s Email sender guidelines, bulk senders must also ensure that the From: header domain aligns with either the SPF or DKIM authenticated domain (DMARC alignment), and spam complaint rates must stay below 0.30% as measured in Postmaster Tools.
The 5,000/day threshold defines “bulk sender” for these platforms, but Google’s guidelines note that all senders (regardless of volume) must have SPF or DKIM set up to avoid delivery issues. If your SaaS sends transactional email at any volume, authentication is no longer optional.
Coldletter handles DKIM signing with your own domain and supports configuring a custom Return-Path so DMARC alignment works correctly out of the box, rather than requiring manual DNS gymnastics after setup.
How to Check Your Own Authentication Setup
You do not need to wait for DMARC reports to verify your configuration. Three quick checks:
1. SPF. Look up your domain’s TXT records. Your SPF should be a single record starting with v=spf1. Multiple SPF records on the same domain will cause failures; merge them into one.
2. DKIM. Your ESP or mail system will tell you which selector they use. Query selector._domainkey.yourdomain.com for a TXT record starting with v=DKIM1.
3. DMARC. Query _dmarc.yourdomain.com for a TXT record starting with v=DMARC1. If there is no record, you have no policy.
Free DNS lookup tools (MXToolbox, Google Admin Toolbox) let you run these checks from the browser. For ongoing monitoring, set up your rua= address or connect an aggregate report parser so you see the full picture of who is sending mail as your domain.
Email authentication fits into the larger story of how email sending actually works at the SMTP level, so that context is worth reading if you want to understand the full path a message takes from your server to the recipient’s inbox. For the complete set of practices that affect inbox placement beyond authentication, see the email deliverability best practices guide.
Frequently Asked Questions
Does SPF alone protect my domain from spoofing?
No. SPF validates the envelope sender (the MAIL FROM address used during the SMTP handshake), not the From: header your recipients see. An attacker can pass SPF on a different domain while displaying your brand name in the From: field. DMARC alignment is what closes this gap, by requiring the authenticated domain to match the visible From: header.
Can I set DMARC to p=none and still be protected?
Not fully. p=none is a monitoring-only policy: receivers report authentication failures to you but deliver the mail regardless. It gives you visibility into your sending sources without risking mail flow disruption. Once you have reviewed your aggregate reports and confirmed all legitimate senders are covered by SPF or DKIM, escalate to p=quarantine, then p=reject, to actually block unauthorized mail.
Why does DKIM survive email forwarding but SPF does not?
When a message is forwarded, the forwarding server relays it from its own IP address, which is not in your SPF record. SPF therefore fails. DKIM signatures, by contrast, are embedded in the message headers and travel with the message unchanged; the receiving server can still verify the original signature using your public key. This is why most DMARC implementations rely primarily on DKIM alignment rather than SPF alignment for forwarded mail.
What is the difference between DMARC p=quarantine and p=reject?
p=quarantine instructs receiving servers to route failing messages to the spam or junk folder. The mail is delivered but treated with suspicion. p=reject tells receivers to outright refuse messages that fail DMARC, returning a bounce to the sender. Most teams start at p=none, move to p=quarantine once they have mapped all legitimate sending sources, and escalate to p=reject after confirming no false positives in their aggregate reports.
Do I need email authentication if I send fewer than 5,000 emails per day?
Yes. The 5,000-per-day threshold in Google’s February 2024 guidelines applies to the stricter bulk-sender requirements, but Google’s general guidelines require that all senders have SPF or DKIM configured regardless of volume. More practically, authentication affects inbox placement at every volume: unauthenticated mail is treated as higher-risk by spam filters across all major providers, not just Gmail and Yahoo.
How many DKIM selectors do I need?
One per service that sends email as your domain. If you send transactional email through one platform and marketing email through another, each needs its own DKIM key pair and its own selector published in your DNS. This also means you can rotate or revoke a single service’s key without affecting the others. Each selector record lives at <selector>._domainkey.yourdomain.com.
I’ve spent my career building software at scale with a soft spot for email: deliverability, lifecycle campaigns, and getting messages to actually land. I started Coldletter to fix what bugged me about transactional and marketing email tools. I’m based in Vancouver.