Your carefully crafted email ends up in a spam folder, or worse, never arrives at all. The recipient never sees it, your open rates crater, and legitimate business communication breaks down. In almost every case, the root cause is missing or misconfigured email authentication records: SPF, DKIM, and DMARC. These three DNS-based standards work together to prove your mail is legitimate, and Gmail, Microsoft 365, Yahoo, and virtually every other major mailbox provider now treat them as hard requirements rather than optional best practices. This guide covers exactly what each record does, how to configure it correctly, how to verify it works, and how to keep it working as your infrastructure evolves.
Why Email Authentication Matters More Than Ever
In February 2024, Google and Yahoo simultaneously tightened their bulk sender requirements, making SPF and DKIM mandatory and DMARC required for anyone sending more than 5,000 messages per day to Gmail addresses. Microsoft followed with similar guidance for Outlook and Hotmail. The practical effect is that domains without proper authentication see sharply elevated spam placement rates even for transactional messages like password resets and invoices.
Beyond deliverability, these records protect your brand. Without DMARC in place, anyone can send an email that appears to come from your domain. Phishing campaigns routinely abuse unprotected domains because there is no mechanism to reject or report forged mail. SPF, DKIM, and DMARC together close that door.
Understanding SPF: Sender Policy Framework
SPF is a DNS TXT record published at your root domain that lists every IP address and mail server authorized to send email on your behalf. When a receiving mail server gets a message claiming to be from your domain, it looks up your SPF record and checks whether the sending IP is on the approved list. If it is not, the message fails SPF.
SPF Record Syntax Explained
A typical SPF record looks like this:
- v=spf1 declares this as an SPF record.
- include: pulls in the SPF policy of a third-party provider, such as Google Workspace or SendGrid.
- ip4: authorizes a specific IPv4 address or range.
- ip6: authorizes an IPv6 address or range.
- ~all is a softfail: unauthorized senders are marked but not outright rejected. Use -all for a hard fail once you are confident your record is complete.
Building Your SPF Record Step by Step
- List every service that sends mail as your domain: your primary mail server, Google Workspace, Microsoft 365, marketing platforms like Mailchimp or HubSpot, transactional providers like SendGrid or Postmark, and any on-premise SMTP relay.
- Find the SPF include string for each provider in their documentation. Google Workspace uses include:_spf.google.com, Microsoft 365 uses include:spf.protection.outlook.com, SendGrid uses include:sendgrid.net.
- Create a single TXT record at your root domain (@ or yourdomain.com) combining all of them. You must have only one SPF TXT record. Multiple SPF records cause an immediate hard fail.
- Start with ~all during testing, then switch to -all after verifying no legitimate mail is failing.
The SPF 10-Lookup Limit
SPF allows a maximum of 10 DNS lookups during evaluation. Each include: mechanism counts as one lookup, and some includes trigger additional lookups of their own. Exceeding the limit causes a PermError, which many receivers treat as a fail. If you use many third-party senders, consider an SPF flattening service or manually replace include statements with their underlying IP ranges using ip4 and ip6 mechanisms.
Understanding DKIM: DomainKeys Identified Mail
DKIM adds a cryptographic signature to every outgoing message. Your mail server signs the email with a private key, and a public key published in DNS lets receiving servers verify the signature has not been tampered with in transit. Unlike SPF, DKIM survives forwarding because the signature travels with the message headers, not with the sending IP.
How DKIM Works in Practice
Your mail server generates a public/private key pair. The private key stays on the server and signs each message. The public key goes into a DNS TXT record at a specific subdomain in the format:
The selector is an arbitrary label, typically something like google, mail, s1, or a date. When a receiving server sees a DKIM-Signature header in a message, it extracts the domain (d=) and selector (s=) values, fetches the public key from DNS, and uses it to verify the signature.
Setting Up DKIM for Common Providers
Google Workspace: In the Admin Console, go to Apps, Google Workspace, Gmail, then Authenticate Email. Click Generate New Record, choose a 2048-bit key, copy the TXT record value, and add it to your DNS at the subdomain Google specifies (usually google._domainkey.yourdomain.com). Return to the Admin Console and click Start Authentication.
Microsoft 365: In the Microsoft 365 Defender portal, go to Email and Collaboration, Policies and Rules, Threat Policies, then DKIM. Select your domain and toggle to Enable. Microsoft will display two CNAME records to add in your DNS. CNAME-based DKIM is slightly different from TXT but functionally identical from a receiving server's perspective.
SendGrid: In Settings, Sender Authentication, authenticate your domain. SendGrid provides two CNAME records for DKIM plus an SPF include. Add all three to your DNS and click Verify.
Self-hosted Postfix with OpenDKIM:
The output of that last command is the TXT record value to publish at mail._domainkey.yourdomain.com. After adding it to DNS, restart OpenDKIM and Postfix.
Key Length and Rotation
Always generate 2048-bit keys. The older 1024-bit keys are considered weak and some providers actively downgrade trust for messages signed with them. Rotate your DKIM keys every six to twelve months by generating a new key pair, publishing the new public key under a new selector, updating your mail server to sign with the new private key, and only then removing the old DNS record. This avoids a gap in signing.
Understanding DMARC: Domain-Based Message Authentication, Reporting and Conformance
DMARC builds on top of SPF and DKIM. It tells receiving servers what to do when a message fails authentication, and it instructs them to send you reports so you can see who is sending mail as your domain. For DMARC to pass, a message must pass either SPF or DKIM, and the domain used in that passing check must align with the domain in the From header that users actually see.
DMARC Alignment Explained
Alignment is the critical concept most guides gloss over. SPF checks the envelope sender (the Return-Path domain), not the From header. DKIM checks the d= value in the signature. DMARC requires at least one of these to match the From domain. In strict alignment mode, the match must be exact. In relaxed mode (the default), organizational domain matches are sufficient, so mail.yourdomain.com aligns with yourdomain.com.
Publishing Your First DMARC Record
DMARC records are TXT records published at _dmarc.yourdomain.com. Start with a monitoring-only policy:
- p=none means take no action on failing mail. This is your data-gathering phase.
- rua= is the address for aggregate reports (sent daily by major providers as XML files).
- ruf= is the address for forensic reports (individual failure reports, less commonly sent due to privacy concerns).
- fo=1 requests a forensic report any time SPF or DKIM fails, rather than only when both fail.
Reading DMARC Reports and Moving to Enforcement
Raw DMARC XML reports are difficult to read. Use a free tool like Postmark's DMARC digests, Dmarcian's free tier, or Google Postmaster Tools to parse them into readable dashboards. Spend two to four weeks reviewing reports to identify every source sending mail as your domain. Once you confirm all legitimate sources are passing authentication, escalate the policy:
The pct=25 tag applies the quarantine policy to only 25 percent of failing messages, giving you a controlled rollout. Gradually increase pct to 100, then move to p=reject:
With p=reject, major providers will outright drop unauthenticated messages claiming to be from your domain. This is the goal. Do not rush to reject without confirming your legitimate mail streams are clean.
Verifying Your Configuration
After publishing all three records, verify them using command-line tools or online checkers. From a Unix/Linux/macOS terminal:
On Windows PowerShell:
Use the DNS Lookup tool to query these records from multiple global vantage points and confirm they return consistent results. Also send a test message to mail-tester.com or MXToolbox's email test address and review the full authentication header breakdown they provide.
In the received email headers, look for these lines:
All three should show pass. If any shows fail or neutral, re-examine the relevant record.
Common Mistakes and How to Fix Them
Multiple SPF Records
You can only have one SPF TXT record per domain. If you added SPF for Google Workspace and later added one for SendGrid as a separate record, you will get a PermError. Merge them into a single record: v=spf1 include:_spf.google.com include:sendgrid.net ~all.
DKIM Record Not Found
If a DKIM lookup returns NXDOMAIN, double-check that you published the record at exactly the right subdomain including the selector. Some DNS control panels add your domain automatically; others expect the full subdomain. If your panel expects just the subdomain portion, enter google._domainkey, not google._domainkey.yourdomain.com.
DMARC Fails Despite SPF and DKIM Passing
This is almost always an alignment problem. Your SPF might be passing for a transactional subdomain like mail.yourdomain.com but the From header shows yourdomain.com. In strict alignment mode, these do not match. Switch to relaxed alignment (the default) or ensure the signing domain matches the From domain exactly.
Forwarded Mail Failing SPF
When a recipient forwards your email through their server, the forwarding server's IP is not in your SPF record, so SPF fails. DKIM should still pass because the signature is intact. This is exactly why DMARC allows either SPF or DKIM to satisfy the requirement. Ensure DKIM is always signing your outbound mail so forwarded messages still pass DMARC via DKIM alignment.
Maintaining Your Email Authentication Long-Term
Authentication is not a one-time task. Every time you add a new email marketing platform, a new CRM with email capabilities, or a new transactional provider, you need to update your SPF record and configure DKIM for the new service. Create a runbook or checklist that any developer or IT admin must complete before a new email-sending integration goes live.
Subscribe to postmaster notifications from Google Postmaster Tools and Microsoft SNDS. These dashboards show your domain reputation and flag authentication problems in near real time. Review your DMARC aggregate reports at least monthly even when everything appears to be working, because spoofing attempts or misconfigured new services will appear there before they become a deliverability problem.
Rotate DKIM keys annually, audit your SPF includes for any services you no longer use, and tighten your DMARC policy progressively if you started at p=none. A domain sitting at p=none indefinitely still provides no protection against spoofing; the goal is always p=reject with full reporting in place.
Getting SPF, DKIM, and DMARC right takes an afternoon of focused work, but the payoff is immediate: better inbox placement, protection against domain abuse, and the visibility to catch authentication problems before your customers do.