Why Is My SPF or DMARC Failing?

You checked your email headers and saw "SPF: FAIL" or "DMARC: FAIL." Or maybe your deliverability tanked and someone told you to check your DNS records. Either way, failing email authentication is one of the fastest ways to land in spam — and fixing it requires understanding exactly what broke and why. Here is a complete diagnosis and fix guide for every common SPF, DKIM, and DMARC failure.

SPF failure causes

SPF (Sender Policy Framework) tells receiving mail servers which IP addresses are allowed to send email on behalf of your domain. When SPF fails, the receiving server sees your email as unauthorized.

Missing include for your sending platform

The most common SPF failure is simply not including your sending platform in your SPF record. If you send through Google Workspace, your SPF record must include include:_spf.google.com. If you also send through Smartlead, you need their include as well. Every platform that sends email on your behalf must be listed.

How to check: Use the Superkabe SPF Lookup tool to see your current SPF record and what it resolves to. Then verify that every service you send email through is included.

How to fix: Add the missing include to your SPF record. Here is what a complete SPF record looks like for a domain using Google Workspace and Smartlead:

Too many DNS lookups (the 10-lookup limit)

The SPF specification limits DNS lookups to 10 per record. Each include:, a:, mx:, and redirect: mechanism counts as one lookup. But includes can be nested — include:_spf.google.com itself triggers 3-4 additional lookups internally. If your total exceeds 10, SPF returns a PermError and fails.

How to check: The SPF Lookup tool shows the total lookup count. Alternatively, run dig TXT yourdomain.com and manually trace each include.

How to fix: Replace include: statements with direct IP addresses where possible. For example, instead of including a third-party service, use their IP range: ip4:198.51.100.0/24. This uses zero DNS lookups. Another option is an SPF flattening service that automatically resolves includes to IPs and keeps your record under the limit.

Use the Superkabe SPF Generator to build an optimized record that stays within the 10-lookup limit.

Multiple SPF records on the same domain

A domain can only have one SPF record (one TXT record starting with v=spf1). If you have two, SPF validation returns a PermError and fails for every email. This commonly happens when one team member adds an SPF record for Google Workspace and another adds a separate one for a transactional email service.

How to fix: Merge all sending sources into a single SPF record. Delete the duplicate and combine the includes:

Using -all too early instead of ~all

The -all mechanism (hard fail) tells receiving servers to reject any email not in your SPF record. The ~all mechanism (soft fail) tells them to accept but flag it. If you set -all before you have included every legitimate sending source, you will reject your own emails.

How to fix: Switch to ~all until you are certain every sending service is included. Monitor for a few weeks using DMARC aggregate reports to confirm no legitimate sources are missing, then switch to -all.

DKIM failure causes

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each email. The receiving server checks this signature against the public key published in your DNS. When DKIM fails, the receiving server cannot verify the email was sent by an authorized source and was not tampered with in transit.

Key not published at the correct selector subdomain

DKIM keys are published at a specific subdomain: selector._domainkey.yourdomain.com. The selector is provided by your email platform (for Google Workspace, it is usually google). If the CNAME or TXT record is published at the wrong subdomain, or the selector does not match what the email header specifies, DKIM fails.

How to check: Use the Superkabe DKIM Lookup tool. Enter your domain and selector to see if the key is published and valid.

How to fix: In Google Workspace Admin Console, go to Apps > Google Workspace > Gmail > Authenticate email. Copy the DKIM record value and publish it as a TXT record at google._domainkey.yourdomain.com. For other providers, follow their specific DKIM setup documentation. Allow up to 48 hours for DNS propagation, then click "Start authentication" in your admin console.

Key rotated by provider but DNS not updated

Some email providers rotate DKIM keys periodically for security. When this happens, the old key in your DNS no longer matches the signature in outgoing emails. Google Workspace can rotate keys automatically, but if you set up DKIM manually (as most cold email setups do), you need to update the DNS record to match the new key.

How to fix: Check your email provider's admin console for the current DKIM key. Compare it to what is published in your DNS. If they differ, update the DNS record with the new key. Set a quarterly reminder to verify DKIM keys have not rotated.

Wrong key length (1024 vs 2048 bit)

DKIM keys come in 1024-bit and 2048-bit lengths. The industry standard is moving to 2048-bit for stronger security. Some receiving servers may flag 1024-bit keys as weak, though most still accept them. The more common issue is publishing a 2048-bit key in a DNS TXT record that exceeds the 255-character string limit — this requires splitting the key into two strings within the same TXT record.

How to fix: If your provider offers 2048-bit keys, use them. If the DNS record fails to save due to length, your registrar may need the key split into two quoted strings within a single TXT record. Most modern DNS providers handle this automatically, but some older panels require manual splitting.

DMARC failure causes

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM together. It passes if at least one of them passes with domain alignment — meaning the domain in the SPF or DKIM check matches the domain in the From header.

SPF and DKIM both failing

DMARC requires at least one of SPF or DKIM to pass with alignment. If both fail, DMARC automatically fails. This is the most common scenario — fix your SPF and DKIM issues first (see sections above), and DMARC will pass.

How to check: Look at the email headers for all three results. If SPF and DKIM both show FAIL, focus on fixing those first. Use the Superkabe DMARC Lookup tool to verify your DMARC record is published correctly.

Alignment mode mismatch (strict vs relaxed)

DMARC alignment means the domain in the From header must match the domain authenticated by SPF or DKIM. In relaxed mode (the default), subdomains count — so mail from user@sub.yourdomain.com aligns with SPF for yourdomain.com. In strict mode, the domains must match exactly.

If you set aspf=s or adkim=s (strict) in your DMARC record, and your emails come from a subdomain while your authentication is set up on the root domain, alignment fails even though the underlying checks pass.

How to fix: Unless you have a specific reason for strict alignment, use relaxed mode. Remove aspf=s and adkim=s from your DMARC record, or explicitly set them to aspf=r and adkim=r.

No DMARC record at all

While a missing DMARC record does not technically cause a "DMARC: FAIL" (the result is "none"), it does mean you have no policy protection. ISPs like Gmail and Yahoo now require DMARC records for bulk senders. Without DMARC, you lose visibility into who is sending email as your domain, and some ISPs may treat your emails with lower trust.

How to fix: Add a DMARC record as a TXT record at _dmarc.yourdomain.com. Start with a monitoring-only policy:

After 2-4 weeks of monitoring aggregate reports and confirming no legitimate sources are failing, move to quarantine:

Once you are confident, move to reject for maximum protection. Use the Superkabe DMARC Generator to create a properly formatted record.

Subdomain vs root domain policy confusion

DMARC has a sp= tag that sets policy for subdomains. If you send from outreach.yourdomain.com but only have a DMARC record on the root domain with sp=reject, emails from the subdomain will be rejected unless the subdomain has its own DMARC record that overrides the parent policy.

How to fix: If you use subdomains for sending, either set sp=none on the root domain DMARC record while you set up subdomain authentication, or publish a separate DMARC record for each sending subdomain at _dmarc.subdomain.yourdomain.com.

Step-by-step fix checklist

Follow this order to fix authentication failures systematically:

1. Check SPF first. Run your domain through the SPF Lookup tool. Verify you have exactly one SPF record, all sending sources are included, and you are under 10 DNS lookups.
2. Check DKIM second. Use the DKIM Lookup tool with your selector (usually "google" for Google Workspace). Confirm the key is published and matches what your provider shows in their admin console.
3. Check DMARC third. Use the DMARC Lookup tool to verify your record exists at _dmarc.yourdomain.com and the policy is appropriate for your current stage.
4. Send a test email. After making DNS changes (allow 15-60 minutes for propagation), send a test email to a Gmail account. Open it, click the three dots, select "Show original," and confirm SPF: PASS, DKIM: PASS, DMARC: PASS.
5. Monitor aggregate reports. Set up the rua= tag in your DMARC record to receive aggregate reports. These reports show every IP that sends email as your domain and whether they pass or fail authentication.

How Superkabe monitors DNS health continuously

Fixing SPF, DKIM, and DMARC once is not enough. DNS records can break silently — a provider rotates DKIM keys, someone on your team adds a second SPF record, a DNS migration drops records. You will not know until your emails start hitting spam.

Superkabe's infrastructure assessment checks all three authentication records across every sending domain connected to your account. Checks run continuously, not just at setup time. If an SPF record adds a lookup that pushes you past the 10-lookup limit, if a DKIM key stops resolving, or if a DMARC record is deleted during a DNS migration, you get an alert before your next campaign sends unauthenticated emails.

This matters because DNS issues are silent killers. Your Smartlead campaigns keep sending, your warmup tool keeps showing good scores, but your live emails fail authentication and land in spam. By the time you check headers manually and discover the failure, domain reputation damage has already accumulated over days or weeks.

Frequently Asked Questions