Email Authentication: The Complete Guide to SPF, DKIM and DMARC
Everything you need to protect your domain, reach the inbox and stop spoofing. Written for people who send email, not people who manage mail servers.
Why Email Authentication Matters in 2026
Email authentication is no longer optional. Since February 2024, Gmail and Yahoo require bulk senders to have valid SPF, DKIM and DMARC records. Without them, your email goes to spam — or gets rejected entirely.
But authentication is not just about compliance. It serves three critical purposes for any organisation that sends email:
Deliverability. Inbox providers use authentication as a first-pass filter. Authenticated messages are eligible for the inbox. Unauthenticated messages are not. It is that simple. No amount of content optimisation or list hygiene compensates for missing authentication records.
Spoofing protection. Without authentication, anyone on the internet can send email that appears to come from your domain. This is not theoretical — domain spoofing is used in phishing attacks, business email compromise and brand impersonation. Authentication makes it cryptographically verifiable that a message actually came from an authorised sender.
Domain reputation. ISPs build sender reputation at the domain level, not just the IP level. DKIM signing ties your messages to your domain identity. Over time, consistent authenticated sending builds a reputation that improves inbox placement across all your email — marketing, transactional and operational.
The Three Pillars of Email Authentication
Email authentication is built on three complementary protocols. Each solves a different part of the problem, and you need all three for complete protection.
SPF — Sender Policy Framework
SPF checks the envelope sender. It publishes a list of IP addresses authorised to send email from your domain. When a message arrives, the receiving server looks up your SPF record and checks whether the sending IP is on the list.
Check your SPF record →DKIM — DomainKeys Identified Mail
DKIM proves message integrity. Your sending server signs every outgoing message with a private key. Receivers verify the signature against a public key published in your DNS. If the signature checks out, the message was not altered in transit.
Check your DKIM record →DMARC — Domain-based Message Authentication
DMARC is the policy layer. It tells receiving servers what to do when a message fails SPF and DKIM — monitor it, quarantine it or reject it. DMARC also sends you reports so you can see who is sending email from your domain.
Check your DMARC policy →How SPF, DKIM and DMARC Work Together
Each protocol alone has limitations. SPF checks the sending IP but breaks when messages are forwarded. DKIM verifies message integrity but does not tell receivers what to do on failure. DMARC brings them together into a coherent system.
Alignment is the key concept. DMARC requires that the domain in the From header matches the domain verified by SPF or DKIM (or both). This prevents attackers from passing SPF with their own domain while spoofing yours in the visible From header.
Alignment can be relaxed (organisational domain match — subdomains count) or strict (exact domain match). Most senders start with relaxed alignment, which covers common setups like sending from marketing.example.com while authenticating against example.com.
This is why you need all three. SPF without DMARC means failures are silently ignored. DKIM without SPF means forwarded messages have no fallback authentication. DMARC without SPF and DKIM has nothing to evaluate.
Step-by-Step Setup for All Three
Step 1 — Set Up SPF
Add a TXT record to your domain's DNS. It lists every service authorised to send email from your domain. A typical record looks like: v=spf1 include:_spf.google.com include:sendgrid.net -all. The -all at the end means reject everything else.
Step 2 — Set Up DKIM
Your email provider generates a keypair. You publish the public key as a TXT record at selector._domainkey.yourdomain.com. The provider signs outgoing messages with the private key. Use 2048-bit keys — 1024-bit keys are considered weak by modern standards.
Step 3 — Set Up DMARC
Add a TXT record at _dmarc.yourdomain.com. Start with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com to monitor without blocking, then move to p=quarantine and eventually p=reject over 4-8 weeks.
Step 4 — Verify Everything
Use the NexusProMail Email Toolkit to check all three records at once. Run checks after every DNS change and whenever you add a new sending service.
The 7 Most Common Authentication Mistakes
1. Not having SPF at all
Surprisingly common. Many domains have DKIM configured by their email provider but no SPF record. Without SPF, anyone can send email from your domain using any IP address. Check your domain now — you might be missing it.
2. Exceeding the 10-lookup SPF limit
SPF records are limited to 10 DNS lookups (includes and redirects). Each "include:" directive counts as one lookup, and nested includes count too. When you exceed 10, the entire SPF record fails — it is not a partial failure. Audit your includes and use IP ranges where possible to reduce lookup count.
3. Using a 1024-bit DKIM key
RFC 8301 recommends 2048-bit keys. While 1024-bit keys still technically work, they are considered cryptographically weak and some receivers flag them. Most email providers default to 2048-bit now. If your key predates 2020, check its size and rotate if needed.
4. Starting DMARC at p=reject
Jumping straight to p=reject without monitoring is the fastest way to block your own legitimate email. Start at p=none with aggregate reporting enabled. Review reports for 2-4 weeks to identify all legitimate senders, then move to p=quarantine, then p=reject. The ramp protects you from blocking email you did not know about.
5. Forgetting third-party senders
Your CRM sends email from your domain. Your helpdesk sends email from your domain. Your transactional email provider sends from your domain. Each one needs to be included in your SPF record and have DKIM signing configured. Audit every service that sends email on your behalf — many organisations discover 5-10 senders they forgot about.
6. Not monitoring DMARC reports
Setting up DMARC without reading the aggregate reports is like installing a security camera and never checking the footage. Reports tell you who is sending email from your domain — including unauthorised senders you need to shut down. Set up a rua address and review reports at least monthly.
7. Setting up once and never rechecking
Authentication records go stale. You add a new marketing tool and forget to update SPF. An employee sets up a SaaS product that sends email from your domain. Your DKIM key gets rotated by the provider and the DNS record is not updated. Schedule quarterly authentication audits.
Testing and Verification Tools
After making DNS changes, verify your records are correct. DNS propagation takes 1-4 hours, so check again after a delay if the first check shows the old record.
NexusProMail Email Toolkit
Free SPF, DKIM and DMARC checkers with plain-English analysis, scoring and fix recommendations. No signup required.
Open the toolkit →Command-line checks. You can also verify records directly using dig yourdomain.com TXT for SPF, dig selector._domainkey.yourdomain.com TXT for DKIM, and dig _dmarc.yourdomain.com TXT for DMARC.
What to check after changes. Verify the record content matches what you intended. Confirm there is only one SPF record (multiple records cause failures). Check that DKIM selectors resolve. Confirm DMARC has a rua address for reports. Then send a test email and check the headers for SPF, DKIM and DMARC pass results.
Email Authentication for Transactional Email
Transactional email — password resets, order confirmations, security alerts — arguably needs authentication even more than marketing email. A spoofed password reset email is a direct phishing vector. A spoofed order confirmation builds false trust.
Use a separate subdomain. Send transactional email from mail.yourdomain.com or notify.yourdomain.com, not your root domain. This isolates transactional reputation from marketing reputation. If a marketing campaign triggers spam complaints, your password reset emails continue reaching the inbox.
Authenticate the subdomain separately. Each sending subdomain needs its own SPF, DKIM and DMARC records. Use relaxed DMARC alignment so the subdomain inherits the parent domain's DMARC policy, or set an explicit subdomain policy with sp= in your DMARC record.
Email Authentication FAQ
Do I need SPF, DKIM and DMARC?
Yes. Gmail and Yahoo require all three for bulk senders since February 2024. Even if you send low volume, all three protocols work together — SPF alone or DKIM alone leaves gaps that spoofers can exploit. DMARC ties them together with a policy that tells receivers what to do with unauthenticated mail.
What are Gmail and Yahoo's sender requirements?
Since February 2024, bulk senders (5,000+ messages/day to Gmail) must have valid SPF and DKIM records, a published DMARC policy (at minimum p=none), a one-click unsubscribe header, and spam complaint rates below 0.3%. Yahoo enforces similar rules. Failing these requirements means your email goes to spam or is rejected outright.
Does authentication guarantee inbox delivery?
No. Authentication proves you are who you say you are — it does not prove your content is wanted. Inbox placement also depends on sender reputation, engagement signals, content quality and complaint rates. But without authentication, inbox delivery is nearly impossible with major providers.
How long does it take for DNS changes to propagate?
Most DNS changes propagate within 1-4 hours, though full global propagation can take up to 48 hours. Set a low TTL (300 seconds) on your records before making changes so updates propagate faster. After confirming the records work, you can raise the TTL back to 3600 or higher.
What is BIMI and do I need it?
BIMI (Brand Indicators for Message Identification) displays your logo next to your emails in supporting inboxes. It requires a DMARC policy of p=quarantine or p=reject. BIMI is optional and primarily a branding benefit — focus on SPF, DKIM and DMARC first, then add BIMI once your authentication is mature.
How often should I audit my email authentication?
Review your SPF, DKIM and DMARC records quarterly, or whenever you add a new email sending service (marketing platform, transactional email provider, CRM, helpdesk). Each new sender needs to be included in your SPF record and have DKIM signing configured.
NexusProMail handles SPF, DKIM and DMARC alignment automatically on every send.
Finnish-operated email platform. EU jurisdiction. Pre-signed DPA. Authentication built in from day one.