SPF, DKIM & DMARC: Email Authentication Explained
SPF, DKIM, and DMARC are DNS records that prove email from your domain is legitimate. SPF lists which servers may send for your domain, DKIM adds a cryptographic signature to each message, and DMARC tells receivers what to do when a message fails both checks — and sends you reports. Since 2024, Google and Yahoo require authentication for senders to their inboxes, so unauthenticated business email increasingly lands in spam or gets rejected outright.
- Google/Yahoo mandate
- SPF or DKIM required for all senders to Gmail and Yahoo; bulk senders (5,000+/day) also need DMARC (Google & Yahoo, effective February 2024)
- Spam share
- Roughly 45% or more of global email traffic is spam (industry estimates)
- DMARC standardized
- Published as RFC 7489 in 2015, building on earlier 2012 industry work (IETF)
- Spoofing vector
- Domain spoofing and lookalike sending remain core techniques in phishing and business email compromise (FBI IC3 reports)
Why legitimate business email lands in spam #
The underlying problem is that the original email protocol, SMTP, lets any server claim to send mail from any address — nothing in the 1980s design verifies the From line. Spammers and phishers exploited this for decades, so mailbox providers like Gmail and Microsoft built layered defenses: authentication checks, content analysis, sender reputation scoring, and engagement signals. When your legitimate invoice email lands in spam, it is usually because your domain fails the authentication layer, which caps everything downstream — great content from an unverified sender still looks like a forgery. Common small-business triggers: sending from a website contact form through a server not authorized in SPF, adding a CRM or newsletter tool without updating DNS, missing DKIM signatures from Microsoft 365 or Google Workspace, and no DMARC record at all. The encouraging news is that authentication is the most fixable deliverability factor: three DNS records, set correctly once, remove the single biggest reason business email gets filtered.
SPF: who's allowed to send for your domain #
SPF (Sender Policy Framework) is a TXT record on your domain listing every server or service authorized to send email on its behalf. When a message arrives claiming to be from yourbusiness.com, the receiving server checks whether the connecting server's IP appears in your SPF record. A typical record authorizes your email provider (Google Workspace or Microsoft 365) plus any tools that send as your domain — your CRM, invoicing software, newsletter platform, and your website's transactional email service. Three rules keep SPF healthy. First, you get exactly one SPF record per domain; publishing two invalidates both, a mistake we find constantly. Second, SPF allows a maximum of ten DNS lookups, and every include: statement consumes them — stacking too many services silently breaks the record. Third, end with ~all (softfail) or -all (fail) so unlisted servers are flagged. SPF's blind spot: it checks a hidden envelope address, not the From line users see, which is exactly the gap DKIM and DMARC close.
DKIM: the tamper-evident signature #
DKIM (DomainKeys Identified Mail) takes a different approach: instead of listing approved servers, it cryptographically signs each outgoing message. Your email provider holds a private key and stamps every message with a signature covering the key headers and body. The matching public key is published in your DNS as a TXT record at a named selector — something like google._domainkey.yourbusiness.com. Receiving servers fetch that key and verify the signature, proving two things at once: the message genuinely originated from a system authorized by your domain, and nobody altered it in transit. DKIM survives forwarding, which SPF does not, making it the more durable signal of the two. Setup is provider-specific but formulaic: generate keys in your email provider's admin console, publish the DNS records they give you, and switch signing on. The most common failures we see are DKIM never being enabled for Microsoft 365 (it is not automatic for custom domains) and third-party tools sending unsigned mail or signing with their own domain instead of yours.
DMARC: the policy that ties it together #
DMARC (Domain-based Message Authentication, Reporting and Conformance) is the layer that turns SPF and DKIM from suggestions into policy. It is a TXT record at _dmarc.yourbusiness.com that answers the question receivers otherwise guess at: when a message fails authentication, what should we do with it? Your options escalate: p=none (deliver anyway, just report), p=quarantine (send to spam), and p=reject (refuse outright). DMARC also gives you visibility — the rua tag names an address where receivers send aggregate XML reports listing every server sending as your domain and whether it passed. Those reports are how you discover the invoicing tool nobody remembered, or the spammer forging your domain from another continent. A message passes DMARC if it passes either SPF or DKIM with alignment, so one mechanism can carry a message when the other breaks. The records below show a realistic small-business setup: Google Workspace plus a newsletter service in SPF, and a DMARC record at quarantine with reporting enabled.
yourbusiness.com. TXT "v=spf1 include:_spf.google.com include:sendgrid.net ~all"
_dmarc.yourbusiness.com. TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100; adkim=r; aspf=r"What is alignment, and why does it matter? #
Alignment is the detail that trips up otherwise correct setups. Passing SPF or DKIM in isolation is not enough for DMARC — the domain that passed has to match the domain in the From header your recipients actually see. SPF validates the hidden envelope sender (the return-path), and many sending services use their own domain there, like bounce.emailtool.com. That SPF pass does not align with yourbusiness.com in the From line, so it contributes nothing to DMARC. Likewise, a DKIM signature from emailtool.com instead of yourbusiness.com passes DKIM but fails alignment. This is why DMARC reports show messages failing even when SPF and DKIM individually pass. The practical fix for third-party services is usually custom domain authentication: the tool has you publish a few CNAME records so it can sign with your domain and use an aligned return path — look for settings called domain authentication or custom DKIM. Rule of thumb: every service that sends as your domain should be configured to sign as your domain.
How should I roll out DMARC, from p=none to p=reject? #
Never start at p=reject — you will bounce legitimate mail from senders you forgot about. The safe progression: 1) publish p=none with a rua reporting address and let it run for two to four weeks, gathering data with zero delivery impact; 2) review the aggregate reports (a report-parsing tool makes the XML readable) and identify every legitimate source — email provider, website forms, CRM, invoicing, newsletters; 3) fix each one's SPF inclusion and DKIM alignment until reports show your real mail passing consistently; 4) move to p=quarantine, optionally easing in with pct=25 and ratcheting up; 5) after a clean month, move to p=reject, at which point forged mail from your domain is refused outright. Budget four to eight weeks for the full journey at a typical small business. The destination is worth it: p=reject materially blunts phishing that impersonates your domain — attacks aimed at your own customers and staff — and strengthens your sending reputation with major providers.
What do Google and Yahoo require since 2024? #
In February 2024, Google and Yahoo turned long-standing best practices into enforced requirements, and they have tightened since. For anyone sending to Gmail or Yahoo mailboxes — which covers most of your customers — every sender must authenticate with at least SPF or DKIM, sending domains must have valid forward and reverse DNS, and spam complaint rates must stay low, ideally under 0.1% and never above 0.3% in Google's Postmaster Tools. Bulk senders, defined as roughly 5,000 or more messages per day to Gmail, face more: both SPF and DKIM, a DMARC record (p=none minimum), From-header alignment, and one-click unsubscribe in marketing mail honored within two days. Microsoft announced comparable requirements for Outlook consumer domains in 2025, so this is now the industry floor, not a Google quirk. For a small business the takeaway is simple: the era of unauthenticated email is over. Even at low volume, missing authentication increasingly means spam-foldering by default rather than a benefit of the doubt.
How to check your records #
Verification takes two minutes and should happen after any email or DNS change. The dig commands shown here pull your SPF record, the DMARC policy, and a DKIM key at a known selector — common selectors are google for Google Workspace and selector1/selector2 for Microsoft 365. Reading raw records has limits, though: syntax can be valid while alignment is broken, and the ten-lookup SPF limit is hard to tally by eye. Two better checks: send a message to a Gmail address you control, open it, choose Show original, and Gmail displays plain PASS or FAIL verdicts for SPF, DKIM, and DMARC on that actual message. And run your domain through our free Email Deliverability Checker, which validates all three records, catches duplicate SPF and lookup-limit problems, and explains failures in plain English. Re-test whenever you add a sending service — every new tool is a fresh chance to fall out of alignment.
dig yourbusiness.com TXT +short | grep spf1
dig _dmarc.yourbusiness.com TXT +short
dig google._dmarc.yourbusiness.com TXT +short 2>/dev/null
dig google._domainkey.yourbusiness.com TXT +shortWhen authentication isn't enough #
SPF, DKIM, and DMARC get you through the door; they do not guarantee the inbox. Deliverability also rides on sender reputation (your domain's and your sending IP's history), list quality (bounces and spam complaints from stale or purchased lists poison reputation fast), engagement (providers watch whether recipients open, reply, or delete unread), and content signals. If your records all pass but mail still folders, work that list in order — reputation and list hygiene explain most residual problems. Know when to bring in help: DMARC reports you cannot interpret, an SPF record bumping the ten-lookup ceiling, a migration between email providers, or a domain that has already been spoofed in a phishing run. Our domains-DNS-email service handles the full setup — SPF consolidation, DKIM for every sending tool, staged DMARC rollout with report monitoring — as part of managing the DNS it all lives in. Start with our free Email Deliverability Checker either way; it tells you in one pass whether the foundation is sound.
FAQ
Do I need SPF, DKIM, and DMARC if I'm a small business?
Yes. Since February 2024, Google and Yahoo require at least SPF or DKIM from every sender, and missing authentication increasingly routes mail to spam regardless of volume. All three records together also stop criminals from convincingly forging your domain in phishing emails to your own customers. Setup is a one-time DNS task.
What's the difference between SPF and DKIM?
SPF is a list of servers allowed to send mail for your domain, checked against the connecting server's IP. DKIM is a cryptographic signature attached to each message, verified with a public key in your DNS. SPF breaks when mail is forwarded; DKIM survives it. DMARC accepts a pass from either, so you want both.
What does p=none mean in DMARC, and is it enough?
p=none tells receivers to deliver failing mail normally but send you reports — monitoring mode. It is the correct starting point and satisfies Google's bulk-sender minimum, but it does not stop spoofing: forged mail from your domain is still delivered. Use the reports to fix legitimate senders, then progress to p=quarantine and ultimately p=reject.
Why is my email failing DMARC when SPF and DKIM pass?
Almost always alignment. The domain that passed SPF or DKIM must match your From-header domain. Many third-party tools use their own domain in the hidden return path and sign DKIM with their own domain, so the passes don't count for your DMARC. Enable custom domain authentication in each tool so it signs as your domain.
How many SPF records can a domain have?
Exactly one. Publishing two or more SPF TXT records makes the result permanently invalid, and receivers treat your domain as unauthenticated. If you use multiple sending services, merge them into a single record with multiple include: statements — while watching the separate limit of ten DNS lookups per SPF evaluation.
How can I check whether my email authentication is set up correctly?
Fastest real-world test: email a Gmail account you control, open Show original, and read the SPF, DKIM, and DMARC verdicts on that message. For a full audit — record syntax, duplicate SPF, lookup limits, DMARC policy — run your domain through our free Email Deliverability Checker, and recheck after adding any new sending service.
Was this helpful?