SPF checks which servers can send mail for your domain, DKIM signs messages so receivers can confirm they weren't altered, and DMARC uses both results to decide whether a message gets delivered, binned or flagged. The immediate next step is to inventory every service that sends mail on your behalf, publish SPF and DKIM for each one, then publish a DMARC record at p=none with reporting switched on. Give that monitoring stage some time before tightening anything.
TL;DR:
- Keep one SPF TXT record per domain and stay within ten DNS lookups; excess lookups can trigger a permanent error instead of authentication.
- DMARC passes when either SPF or DKIM passes with alignment; aligned DKIM can preserve delivery when forwarding breaks SPF for a message.
- Wait at least 48 hours after enabling SPF and DKIM before adding DMARC, then monitor reports for several weeks before moving beyond p=none.
- Move to quarantine only after reports confirm every legitimate sender passes authentication, and switch to rejection after another monitoring period at quarantine.
- Strict alignment can break legitimate third party or subdomain sending; relaxed alignment is a sensible starting point, and gradual pct increases limit the impact.
Table of Contents
- SPF at a glance: what it checks, record anatomy and common pitfalls
- DKIM at a glance: signing, selectors and DNS keys
- DMARC at a glance: policy, alignment, and reporting
- How SPF, DKIM and DMARC work together on a message (alignment and pass/fail scenarios)
- Step-by-step rollout checklist: inventory, SPF, DKIM, DMARC, monitor and enforce
- How to check and test your records: DNS checks, headers, and report analysis
- Common mistakes and troubleshooting checklist
- Publisher perspective: our operational view on SPF, DKIM and DMARC
- How we can help with SPF, DKIM and DMARC setup and monitoring
- FAQ
- Sources
SPF at a glance: what it checks, record anatomy and common pitfalls
SPF, or Sender Policy Framework, lets a domain owner list the servers allowed to send mail using that domain in the MAIL FROM or HELO identity, as set out in RFC 7208. A receiving server checks the sending IP against this list and decides whether the message looks legitimate.
An SPF record is a single DNS TXT entry that starts with v=spf1, followed by mechanisms such as include: for third-party senders, ip4: or ip6: for specific addresses, and a final qualifier. That last part matters more than it looks: -all tells receivers to reject anything not listed, while ~all asks them to treat it with suspicion but still deliver it. Microsoft recommends using -all once DKIM and DMARC are also in place, since SPF alone is not a complete defence.
Two rules trip up most administrators we see:
- Only one SPF TXT record is permitted per domain, so multiple marketing tools or CRMs must share a single record rather than each adding their own.
- SPF allows no more than ten DNS lookups per check, and every
include:can trigger several, so a sprawling list of services quickly breaches that ceiling and causes a permanent error rather than a pass.
Before writing anything, map every system that sends mail for your domain, which is your invoice software, your helpdesk, your marketing platform and your actual mail server, so the record reflects what genuinely happens rather than guesswork.
DKIM at a glance: signing, selectors and DNS keys
DKIM, or DomainKeys Identified Mail, attaches a digital signature to outgoing messages covering specific headers and the body content. A receiving server fetches the matching public key from DNS and checks that nothing was altered in transit.
Each signature carries a selector, a short label that points to a particular DNS record, and a d= value naming the signing domain. Public keys live at a predictable address, selector._domainkey.yourdomain.com, which is why Microsoft's DKIM guidance walks through publishing that exact record. Many third-party platforms simplify this for you by asking you to add a CNAME record pointing to keys they manage and rotate on your behalf.
Alignment is the detail that catches people out. DMARC only credits a DKIM pass when the d= domain in the signature matches the domain in the visible From address, so a signature from a marketing platform's own domain does nothing for your DMARC posture unless it's been configured to sign as you.
- Generate a key pair for each sending platform rather than reusing one key everywhere.
- Publish the public key at the correct selector before switching signing on, never after.
- Check that the live
d=value matches your sending domain, not the vendor's. - Rotate keys periodically and remove selectors for services you no longer use.
Pro Tip: Keep a simple spreadsheet of every selector you've published and which service owns it, so a leaver or a cancelled subscription doesn't leave an orphaned key quietly sitting in your DNS.
DMARC at a glance: policy, alignment, and reporting
DMARC sits above SPF and DKIM and tells receiving servers what to do when a message fails both checks, plus where to send a summary of what happened. A typical record looks like v=DMARC1; p=none; rua=mailto:reports@yourdomain.com; pct=100; adkim=r; aspf=r.
The policy tag (p=) is the headline setting: none means monitor only, quarantine sends failing mail to spam, and reject blocks it outright. The rua tag is where aggregate reports land, and ruf can request forensic copies of individual failures, though far fewer receivers support that. pct= controls what percentage of mail the policy applies to, useful for a gradual rollout.
adkim=randaspf=ruse relaxed alignment, accepting any subdomain match against the organisational domain.- Switching either to strict mode (
s) demands an exact match, which can break legitimate subdomain or third-party sending unless everything is configured precisely. - Relaxed alignment is the sensible starting point for most domains, with strict mode reserved for domains with tightly controlled sending.
Google Workspace's own guidance recommends waiting at least 48 hours after enabling SPF and DKIM before adding DMARC, so there's time for authentication to settle and for reports to reflect genuine sending patterns rather than configuration noise.
Starting with p=none costs nothing in deliverability while giving you a complete picture, via rua reports, of every server claiming to send as your domain before you risk blocking anything real.
How SPF, DKIM and DMARC work together on a message (alignment and pass/fail scenarios)
A message passes DMARC if either SPF or DKIM passes and that pass is aligned with the visible From domain. It doesn't need both; one aligned pass is sufficient, which is exactly why forwarding and some third-party sending can still work once DKIM is configured correctly even when SPF breaks.
A typical Authentication-Results header reads:
Authentication-Results: mx.example.com;
spf=pass smtp.mailfrom=yourdomain.com;
dkim=pass header.d=yourdomain.com;
dmarc=pass header.from=yourdomain.com
Compare smtp.mailfrom, header.d and header.from against each other, since Microsoft's security operations guidance notes that field names and formatting vary slightly between providers but these three tokens are always present and comparable.
spf=fail smtp.mailfrom=yourdomain.com; dkim=pass header.d=yourdomain.com; dmarc=pass header.from=yourdomain.com
This is a common and healthy outcome: SPF failed, perhaps because a forwarding server changed the sending IP, but DKIM's signature survived and aligned, so DMARC still passed.
Aggregate rua reports arrive as XML and reward a closer read. Each record names a source_ip, a count of messages from it, and a policy_evaluated block showing the SPF and DKIM results and the action taken.
| Field | What it shows |
|---|---|
| source_ip | Which server actually sent the message |
| count | How many messages came from that IP in the reporting window |
| policy_evaluated | Whether SPF and DKIM aligned, and what policy action applied |
Step-by-step rollout checklist: inventory, SPF, DKIM, DMARC, monitor and enforce
A safe rollout follows a fixed order, and skipping steps is where most problems start.
- Inventory every sending source, including your mail server, helpdesk, invoicing tool, CRM and marketing platform.
- Publish one SPF TXT record covering every legitimate source, consolidating includes to stay under the ten-lookup ceiling.
- Enable DKIM signing on each platform and publish the selector it provides, checking the
d=value matches your domain. - Publish a DMARC record at
_dmarc.yourdomain.comwithp=noneand anruaaddress, so reports start flowing immediately. - Monitor for at least 48 to 72 hours, though a full week or two gives a more reliable picture, especially for domains with irregular sending patterns like monthly newsletters.
- Move to
p=quarantineonce reports confirm every legitimate source passes, then top=rejectafter a further monitoring period at quarantine.
Pro Tip: Raise pct= gradually, say from 25% to 100%, rather than jumping straight to full enforcement, so a missed sender shows up as a small trickle of failures rather than a flood of bounced customer mail.
If your organisation runs its own Microsoft 365 tenant, our guide to harder Exchange Online spam filtering covers complementary settings worth reviewing alongside this rollout.
How to check and test your records: DNS checks, headers, and report analysis
Verification is straightforward once you know where to look. Use dig txt yourdomain.com, dig txt selector._domainkey.yourdomain.com and dig txt _dmarc.yourdomain.com from a terminal, or any equivalent online DNS lookup tool, to confirm each record is published and syntactically correct.
- Send a test message to a Gmail or Outlook.com address and open the full headers to read the Authentication-Results line directly.
- Look specifically for
spf=pass,dkim=passanddmarc=pass, and if any showfail,permerrorortemperror, that's your starting point for troubleshooting. - A
permerroron SPF usually means too many DNS lookups or a malformed record, whiletemperroroften clears on its own after a DNS propagation delay. - Collect rua aggregate reports with a parsing tool or reporting service, since reading raw XML by hand across multiple domains is impractical and the only reliable way to spot an untracked sender hiding among legitimate traffic.
If you've recently moved domains or changed registrars, our walkthrough on domain transfers without email downtime covers the DNS sequencing that keeps authentication records intact during the switch.
Common mistakes and troubleshooting checklist
Most failures trace back to a handful of recurring issues.
- Multiple SPF TXT records: only one is valid, so a second record added by a new tool silently breaks the first.
- Too many DNS lookups: consolidate includes or move high-volume bulk mail to a dedicated subdomain with its own simpler SPF record.
- Missing or mismatched DKIM keys: a selector published with a typo, or a key the sending platform never actually activated, both produce a silent
dkim=fail. - Alignment failures: if DKIM passes but DMARC still fails, check whether the signing
d=domain actually matches your From address rather than the vendor's own domain. - Forwarding and mailing lists: these often rewrite headers or envelope senders in ways that break SPF, which is exactly why a correctly aligned DKIM signature matters as a fallback.
Pro Tip: When a message passes through a mailing list or forwarder that strips DKIM signatures entirely, ARC headers can preserve the original authentication results for the next hop, though support for reading them varies by receiving provider.
Publisher perspective: our operational view on SPF, DKIM and DMARC
Across the setups we look after, the same two gaps show up repeatedly: a marketing or invoicing tool added years ago that nobody remembered to include in the SPF record, and a DKIM selector left active for a platform that was cancelled long ago. Both sit quietly until a DMARC report, or a bounced customer email, brings them to light.
Checking rua reports weekly during the monitoring phase, then monthly once enforcement is stable, catches most of this before it affects deliverability. When reports show legitimate mail failing and the cause isn't obvious within a day or two, that's the point to bring in dedicated support rather than guessing against a live mail flow.
— Will
How we can help with SPF, DKIM and DMARC setup and monitoring
Getting SPF, DKIM and DMARC right across every sending platform, then watching the reports as your business adds new tools, is an ongoing job rather than a one-off task. Through our managed IT support service, we handle the DNS configuration, the selector management and the regular reading of DMARC reports, so nothing gets left on p=none indefinitely or breaks quietly when a new service gets added.
For ongoing oversight, our Care Plans build in the monitoring and alerting that catches an authentication failure before it becomes a deliverability problem, and our remote monitoring and management service extends that same watchfulness across the rest of your infrastructure. If your sending runs through Microsoft 365, our Microsoft 365 service covers the platform-specific configuration this guide references. Get in touch and we'll review what you've already got in place and tell you exactly what's missing.
FAQ
What is the difference between SPF, DKIM and DMARC?
SPF checks whether a sending server's IP address is authorised for a domain, and DKIM checks a cryptographic signature to confirm a message wasn't altered. DMARC sits above both, using their results to set a policy, monitor, quarantine or reject, and to send reports back to the domain owner.
Do I need SPF and DKIM if I already have DMARC?
Yes, DMARC does nothing on its own: it only evaluates the pass or fail results that SPF and DKIM produce, and without at least one of them aligned, DMARC has no way to authenticate the message. NCSC guidance treats all three as complementary layers rather than substitutes for each other.
How long should I monitor DMARC before enforcing a policy?
Google Workspace recommends allowing SPF and DKIM at least 48 hours to settle before adding DMARC, and most administrators then run p=none with reporting for several weeks to confirm every legitimate sender appears in the reports before moving to quarantine or reject.
What does an SPF permerror mean?
A permerror usually means the SPF record is malformed or exceeds the ten-DNS-lookup limit set out in RFC 7208. The fix is typically to simplify nested include: statements or move high-volume senders to a dedicated subdomain with its own record.
Can DMARC pass if SPF fails but DKIM passes?
Yes, DMARC only requires one of SPF or DKIM to pass with alignment, so a DKIM pass alone is enough even if SPF fails, which commonly happens when a message is forwarded or routed through an intermediary server.
Sources
- Set up DMARC (Google Workspace Help)
- Set up SPF to identify valid email sources for your Microsoft 365 domain - Microsoft Defender for Office 365
- Email security and anti‑spoofing collection - NCSC
- Sender Policy Framework (SPF) — RFC 7208