Set both SPF and DKIM for your sending domains, then publish a DMARC record with p=none to monitor. Both records are required before DMARC can enforce anything, so treat them as one job, not two. Publish a single SPF TXT record, turn on DKIM signing through your mail provider, then add a DMARC record in monitoring mode so you can see what's passing before you block anything.
TL;DR:
- Publishing a single SPF record that includes all sending sources and avoiding multiple records prevents permanent failures in email authentication.
- Using 2048-bit DKIM keys improves trustworthiness, especially when migrating or adding new providers, with recommended overlap during key rotation.
- DMARC enforcement should be staged gradually from monitoring (
p=none) to quarantine and reject, based on thorough analysis of RUA reports.- Successful email authentication requires both correct DNS record setup and verification through tools like
digor Gmail’s "Show original" function; regular monitoring is essential.- Separating marketing and transactional emails onto different subdomains helps manage SPF lookup limits and refine DMARC policies without risking deliverability.
Table of Contents
- What Do SPF and DKIM Actually Do for Email Deliverability?
- How Do You Publish One Correct SPF Record?
- How Do You Set Up DKIM and Publish the Public Key?
- How Does DMARC Alignment Work, and How Should You Roll It Out?
- What Are the Most Common SPF and DKIM Failures?
- How Do You Verify SPF, DKIM, and DMARC Are Actually Working?
- Ihor's Hands-On Tips for Small Hosting Customers
- Is Strict DMARC Enforcement Worth It for a Small Sender?
- How inSave Hosting Handles the DNS Side for You
- Sources
- FAQ
What Do SPF and DKIM Actually Do for Email Deliverability?
SPF and DKIM solve two different halves of the same problem: proving a message really came from you.
SPF (Sender Policy Framework) authorizes specific sending IPs at the domain level. When a receiving server gets your mail, it checks the envelope sender's domain, looks up your SPF TXT record, and confirms the IP that sent the message is on your approved list. It's a yes/no check against a published list of servers.
DKIM (DomainKeys Identified Mail) works differently. Instead of checking where the mail came from, it checks whether the message itself has been tampered with. Your mail server signs each outgoing message with a private key, and that signature gets verified against a public key published at a selector._domainkey DNS record. If even one character of the signed content changes in transit, the signature fails.
Here's why you need both, not just one:
- SPF breaks the moment a message gets forwarded, because the forwarding server's IP isn't on your approved list.
- DKIM usually survives forwarding, since the signature travels with the message content rather than the sending server.
- A message that fails SPF can still pass authentication overall if DKIM checks out, and vice versa.
- DMARC leans on whichever of the two actually aligns with your visible "From" address, which is exactly why relying on only one leaves gaps.
That last point matters more than most guides admit. DMARC doesn't require both SPF and DKIM to pass on every message. It requires at least one of them to pass and align with your From domain. Skip DKIM and you're betting your entire deliverability on SPF surviving every forwarding scenario your recipients throw at it. It won't.
How Do You Publish One Correct SPF Record?
An SPF record is a single TXT record at your root domain, and "single" is doing a lot of work in that sentence. A domain can only have one valid SPF record — publishing two, even if you're trying to add a second vendor, triggers a permanent failure that breaks authentication for everyone.
- Check for existing records. Run a DNS lookup on your domain and see if a
v=spf1TXT record already exists before adding anything. - Merge every sending source into one record. If you use Google Workspace and a transactional provider like SendGrid or Postmark, combine both into a single line:
v=spf1 include:_spf.google.com include:sendgrid.net ~all. - Choose your qualifier deliberately.
~all(soft fail) tells receivers to accept but flag unauthorized mail;-all(hard fail) tells them to reject it outright. Most small senders should start with~alland move to-allonly once they're confident every legitimate source is listed. - Audit your lookup count. Every
include,a,mx,ptr, andredirectmechanism burns one of your 10 allowed DNS lookups, and nested includes (a vendor's include pointing to another include) can quietly exceed that limit without you adding a single line yourself. - Flatten or delegate if you're close to the limit. Some providers offer "flattened" SPF records that resolve nested includes into flat IP ranges, or you can push high-volume sending onto a subdomain with its own SPF record.
Pro Tip: Before you touch your SPF record, run a lookup count on your current setup. If you're already at 8 or 9 out of 10, adding one more marketing tool will silently break your entire authentication chain, and you won't find out until deliverability tanks.
How Do You Set Up DKIM and Publish the Public Key?
DKIM setup starts with generating a key pair through your mail provider, which is almost always handled for you if you're on Google Workspace, Microsoft 365, or a hosting-managed mail platform.
The DNS side follows a fixed naming pattern: selector._domainkey.yourdomain.com. The "selector" is just a label your provider assigns, like google or s1, so the full record might look like google._domainkey.example.com. That record holds your public key as a TXT entry, formatted with a v=DKIM1 tag and the key data itself.
Key length matters more than most admins realize:
- Google recommends a DKIM key of at least 1024 bits when sending to Gmail addresses, with 2048-bit preferred where your provider supports it.
- Weaker keys are still technically valid but increasingly treated with suspicion by major mailbox providers.
- If your host or email platform offers a choice, take 2048-bit every time. There's no meaningful downside once your DNS provider supports the longer TXT value.
Hosted platforms (Google Workspace, Microsoft 365, most transactional email services) manage signing automatically. Self-managed setups using OpenDKIM require you to generate, store, and rotate keys yourself, which is more control but also more room for error.
Pro Tip: When you migrate email providers, don't delete your old DKIM selector the day you switch. Publish the new selector and keep the old one live until you've confirmed mail signed with the new key is being accepted by Gmail and Outlook. Cutting over instantly is how migrations quietly tank deliverability for a week.
How Does DMARC Alignment Work, and How Should You Roll It Out?
DMARC doesn't replace SPF or DKIM. It sits on top of them and checks whether the domain that passed authentication actually matches your visible From address — a step called alignment performed by authentication protocols.
There are two alignment modes. Relaxed alignment (the default, and what most small senders should use) accepts any matching subdomain, so mail authenticated as mail.example.com still aligns with a From address of example.com. Strict alignment requires an exact match between the authenticated domain and the From domain, which is safer but breaks easily if you use subdomains for different sending streams.
A basic DMARC record lives at _dmarc.yourdomain.com and looks like this:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
The p= tag sets your policy, and rua= tells receivers where to send daily aggregate reports.
Roll it out in stages, never all at once:
- Start at
p=nonefor at least two to four weeks. This monitors traffic without blocking anything. - Read your RUA reports to identify every legitimate source sending on your behalf, including forgotten marketing tools or CRM integrations.
- Move to
p=quarantineonce you're confident every real sender passes. - Only move to
p=rejectafter quarantine has run clean for a while. Industry guidance consistently favors this cautious, staged approach over jumping straight to enforcement.
What Are the Most Common SPF and DKIM Failures?
Most authentication problems trace back to a handful of repeat offenders, and nearly all of them are fixable in one DNS edit.
- Multiple SPF TXT records. This is the single most common cause of a PermError, and the fix is always the same: merge every include into one record and delete the rest.
- Exceeding the 10-lookup limit. If you've added vendors over time without auditing lookups, you can breach the ceiling without touching your SPF syntax. Flatten nested includes, remove unused vendor references, or shift volume senders to a dedicated subdomain.
- SPF passes but DMARC still fails. This almost always means an alignment mismatch. Check whether your envelope sender (return path) domain matches your visible From domain, or whether your DKIM signing domain differs from the From header.
- DKIM signatures failing intermittently. Look at which headers are actually signed. Some gateways rewrite subject lines or add disclaimer text after signing, which invalidates the signature. Confirm the selector record still exists and hasn't expired or been overwritten.
Pro Tip: If a client complains their mail is "sometimes" landing in spam, that word "sometimes" is a big clue. Consistent failures point to a broken record; intermittent ones point to a gateway or forwarding rule modifying your mail after it's signed.
How Do You Verify SPF, DKIM, and DMARC Are Actually Working?
Verification isn't optional; it's the only way to know your records parse the way you think they do. A dig command run against your domain shows exactly what receivers see:
dig TXT yourdomain.com for your SPF record, dig TXT selector._domainkey.yourdomain.com for your DKIM public key, and dig TXT _dmarc.yourdomain.com for your DMARC policy.
Beyond the command line, Gmail's "Show original" feature on any received message displays an Authentication-Results header that spells out the verdict directly:
| Check location | What you're looking for |
|---|---|
dig TXT yourdomain.com | One v=spf1 record, no duplicates |
dig TXT selector._domainkey.yourdomain.com | A valid v=DKIM1 public key string |
dig TXT _dmarc.yourdomain.com | Your policy tag and rua= mailto address |
| Gmail "Show original" | spf=pass dkim=pass dmarc=pass on the Authentication-Results line |
| Google Postmaster Tools | Domain and IP reputation trends over time |
Google Postmaster Tools tracks your sending reputation with Gmail specifically, which matters since Gmail is often the largest single slice of any small business's recipient list. For ongoing DMARC monitoring, feed your RUA reports into an aggregator rather than reading raw XML by hand. MXToolbox and mail-tester.com both offer quick one-off checks that catch syntax errors before they cost you deliverability.
Ihor's Hands-On Tips for Small Hosting Customers
Running email for dozens of small business domains teaches you the same lessons over and over. A few worth repeating:
Push your marketing tools and transactional mail onto separate subdomains. It keeps your root domain's SPF lookup count low and lets you set different DMARC policies for newsletters versus receipts, which is exactly how larger senders manage growing vendor lists without hitting the 10-lookup ceiling.
When you switch providers, rotate DKIM selectors deliberately, not instantly. Keep the old selector published for a week or two of overlap while you confirm the new one is accepted.
And if you're not comfortable editing raw DNS zone files, use hosting-managed DNS tools instead of a third-party registrar's control panel. Fewer manual steps means fewer typos in a TXT record that's already hard enough to read correctly.
Pro Tip: Copy your SPF and DKIM values into a plain text file before you touch DNS. If a paste error breaks your record, you want the correct version one click away, not buried in an email thread from six months ago.
— Ihor
Is Strict DMARC Enforcement Worth It for a Small Sender?
p=reject earns its keep once every sending source is known, documented, and monitored. If you can name every service that sends mail on your behalf and you actually read your RUA reports, enforcement is the right move.
Most small teams aren't there yet. Staying at p=quarantine while you build out monitoring and whitelist processes is a reasonable, defensible place to sit for months, not a failure to fix.
How inSave Hosting Handles the DNS Side for You
Managing TXT records in a DNS panel can be challenging for many small site owners. Some hosting plans include DNS management with one-click record edits, so publishing your SPF string or pasting a DKIM public key doesn't require decoding a registrar's cryptic interface.
Support also covers where to place DKIM selector records without guessing at formatting, and daily backups mean a bad DNS edit isn't a disaster while you sort it out. If email deliverability keeps slipping and you'd rather not become a full-time DNS administrator, the shared hosting plans come with that DNS control built in, and the WordPress hosting plans offer the same setup for site owners running WordPress specifically. Check either plan page to see what fits your sending volume, or start from the main hosting overview if you're still comparing options.
Sources
For deeper reference, consult Gmail's sender guidelines, RFC 7208 (SPF), RFC 6376 (DKIM), and RFC 7489 (DMARC), plus practical testing through MXToolbox and mail-tester.com for quick record checks.
- Email sender guidelines - Gmail Help
- DNS Records for Email Deliverability: The Complete Guide - Salesforce
- SPF, DKIM, and DMARC: Email Authentication Explained - Linuxize
- SPF, DKIM and DMARC | Proofpoint
FAQ
Is SPF Required for DKIM to Work?
No. SPF and DKIM operate independently and don't depend on each other technically, but DMARC needs at least one of them to pass and align, which is why most guidance recommends running both together.
How Can an Email Pass SPF and DKIM but Still Fail DMARC?
This happens when neither the SPF-authenticated domain nor the DKIM-signing domain aligns with the visible From header. DMARC checks alignment, not just pass/fail status, so a mismatched return path or signing domain fails DMARC even with both underlying checks passing.
What's the Difference Between SPF, DKIM, and DMARC?
SPF authorizes which servers can send mail for your domain, DKIM signs messages to prove they weren't altered in transit, and DMARC ties the two together by requiring alignment with your From address and tells receivers what to do when checks fail.
What Does "spf=pass dkim=pass dmarc=pass" Mean in Gmail?
It means all three authentication checks succeeded on that message, visible by opening Gmail's "Show original" feature on any received email and reading the Authentication-Results header.
Can inSave Hosting Help Set Up SPF and DKIM Records?
Yes. inSave Hosting's shared and WordPress plans include DNS management tools for publishing SPF, DKIM, and DMARC TXT records without manual zone file editing.