Free tools Windows power users keep installed
One-click scans. No signup required.
To fix email authentication, identify the affected sending stream, inspect the receiving server’s Authentication-Results header, and check SPF, DKIM, and DMARC as separate but connected tests. SPF authorizes an IP for an SMTP identity; DKIM verifies a domain-linked message signature; DMARC checks whether a passing SPF or DKIM identity aligns with the domain readers see in the From field. Correct the sender’s DNS or provider configuration before tightening DMARC enforcement.
What SPF, DKIM, and DMARC each check
These mechanisms answer different questions. A message can pass one and fail another, and the result can vary by recipient because receivers evaluate the message they actually receive.
As an Amazon Associate I earn from qualifying purchases.
| Mechanism | What it checks | Where to investigate | Common failure trigger |
|---|---|---|---|
| SPF | Whether the connecting IP is authorized for the SMTP identity, usually the MAIL FROM domain or, in some cases, the HELO domain. | The SPF TXT record for the identity used by that sending stream. | An unlisted sending service, lookup/evaluation error, or forwarding that changes the connecting IP. |
| DKIM | Whether a message carries a valid cryptographic signature associated with a signing domain. | The message’s DKIM-Signature fields and the public key at the selector under the signing domain. |
Missing or incorrect key/configuration, or changes to signed content or headers. |
| DMARC | Whether SPF or DKIM passes and its authenticated domain aligns with the visible RFC5322.From domain; it also publishes a requested handling policy and may request reports. | The DMARC TXT record and the message’s SPF, DKIM, and DMARC results and identities. | Neither mechanism passes with an aligned domain, or the policy is misconfigured for the stream. |
SPF is specified in RFC 7208, and DKIM in RFC 6376. The current DMARC standard is RFC 9989, published in 2026; it obsoletes RFCs 7489 and 9091, so older DMARC guides may describe superseded standard text. DMARC authenticates domain use, not the legitimacy of message content or an individual mailbox name, and it is not a complete anti-phishing system.
How do I check SPF, DKIM, and DMARC in email headers?
- Get the original message headers. Collect a complete header from a passing example and a failing example for the same stream if possible. Record the visible From domain, recipient provider, time, message ID, and sending service.
- Find the receiver’s Authentication-Results. Read the receiving system’s
Authentication-Resultsfield forspf=,dkim=, anddmarc=. It reports what happened to that specific message; a DNS checker cannot establish the receiver’s result. Google also recommends using this field when troubleshooting SPF (Google Workspace SPF troubleshooting). - Record the evaluated identities. For SPF, identify the MAIL FROM or HELO domain involved. For DKIM, inspect
d=(signing domain) ands=(selector) inDKIM-Signature. Compare both authenticated domains with the visible From domain to assess DMARC alignment. - Compare good and bad messages. Differences in sender service, envelope domain, selector, recipient path, or message transformations can isolate whether the fault is DNS, provider setup, forwarding, or alignment.
Why is SPF failing?
Check the SPF identity used for the actual SMTP transaction, not just the address shown to the recipient. The visible From domain is not necessarily the MAIL FROM domain evaluated by SPF.
#1 Best Overall
Verify the policy and sender inventory
- Query the TXT record at the MAIL FROM or HELO domain identified in the message’s authentication results.
- Confirm there is one valid SPF policy for that domain and that it covers every service legitimately sending for it. Inventory transactional systems, marketing platforms, website forms, and other third parties; remove mechanisms for services no longer in use.
- Use each provider’s instructions for its authorized mechanism. DNS host interfaces and provider-specific steps differ, so do not copy a generic record that may authorize the wrong sources.
Google Workspace says SPF changes can take up to 48 hours to start working. Treat that as operational guidance, not a guaranteed DNS propagation time (Google Workspace SPF setup).
Count DNS lookups, not just include strings
RFC 7208 limits an SPF evaluation to 10 DNS-querying terms across recursive evaluation. The counted mechanisms and modifier are include, a, mx, ptr, exists, and redirect. The limit is not simply ten visible include: strings: included policies can trigger more lookups. Implementations must stop once the limit is exceeded and return permerror. See the RFC 7208 lookup-limit rules.
Interpret the result before changing DNS
failorsoftfailcan mean a legitimate sender is missing from the policy, but can also correctly identify unauthorized mail.temperrorpoints to a temporary lookup problem.permerroroften indicates a policy or evaluation problem, including excessive DNS-querying terms.
Forwarding commonly causes SPF failure because the receiver sees the forwarder’s IP rather than the original sender’s. Do not solve this by adding arbitrary forwarders to your SPF record. Check whether DKIM survives and whether it can satisfy DMARC alignment. Google lists missing senders, DNS errors, and forwarding among common SPF trouble sources (Google Workspace SPF troubleshooting).
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11How do I fix a DKIM failure?
- Read the signature. In
DKIM-Signature, noted=ands=. The public key should be published at the selector name under the signing domain. - Check provider configuration. Confirm the service is signing with the intended domain and that the public key published in DNS matches the service’s configuration. For Google Workspace, the admin process is to generate a key, publish it in DNS, enable signing, then verify with a test message and its headers (Google Workspace DKIM setup).
- Check when the failure occurs. If mail passes before forwarding or mailing-list delivery but fails afterward, investigate message changes before replacing keys. Altered MIME boundaries, Subject headers, or body content can invalidate a signature (Google guidance on forwarded-message authentication).
- Account for multiple senders. Configure DKIM separately for each provider that sends for the organization. Google’s authentication dashboard guidance recommends unique DKIM keys/configuration for third-party senders; keep the signing domain aligned with the visible From domain where possible (Google authentication dashboard guidance).
Why does DMARC fail when SPF passes?
Because SPF passing is not enough: the domain authenticated by SPF must also align with the visible From domain. For example, if SPF passes for a provider’s envelope domain but the visible From uses your organization’s domain, that SPF result may not satisfy DMARC. A passing DKIM signature can independently satisfy DMARC if its signing domain aligns. DMARC needs at least one passing aligned mechanism, not necessarily both (RFC 9989; Google sender guidance).
In the same message, compare the visible From domain with both the SPF-authenticated domain and DKIM’s d= domain. Then inspect the DMARC TXT record at _dmarc.<domain>, including policy scope, any subdomain policy, and reporting destinations. Relaxed alignment can accommodate related domains and is often sufficient; strict alignment may cause valid mail from related subdomains or third-party streams to fail alignment. Google recommends relaxed alignment in many cases and fully aligning SPF and DKIM for reliability (Google authentication dashboard guidance).
How do I roll out DMARC without blocking legitimate email?
- Inventory and configure senders. Establish SPF and DKIM for every legitimate stream before enforcing DMARC. Include low-volume systems such as web forms and transactional notifications, not only the main marketing or mailbox provider.
- Start with monitoring. Publish a valid DMARC policy using
p=noneand review aggregate reports across the domain and its senders. Treat reports as evidence to investigate, not as an automatic authorization list: distinguish known vendors, forwarding, spoofing, and unknown sources. - Move gradually to enforcement. Google recommends monitoring first, then moving to quarantine for a small percentage after at least one week without observed issues, and increasing enforcement carefully. This is Google’s rollout guidance, not a universal standards-mandated waiting period (Google Workspace DMARC rollout).
- Investigate before weakening policy. If legitimate mail is affected, identify its stream and correct SPF/DKIM authentication or alignment. Do not switch back or broaden authorization without understanding the failure.
p=none asks receivers not to quarantine or reject messages based on DMARC policy; quarantine and reject request stronger handling and carry more risk if a legitimate stream is misconfigured. Receiver behavior is not universal, so the policy is a request rather than a guarantee of identical handling everywhere (RFC 9989).
Which receiver requirements apply to Gmail?
Requirements depend on the recipient provider. For mail sent to personal Gmail accounts, Google says senders sending more than 5,000 messages per day must configure SPF, DKIM, and DMARC for their sending domains; direct mail must align the From domain with SPF or DKIM. This is Gmail guidance and should not be generalized to every mailbox provider (Google email sender guidelines).
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
