Google Workspace SPF and DKIM Both Failing After Setup: What to Check

You set up SPF and DKIM for Google Workspace. You created your DMARC record. Everything looks configured correctly.

Then your DMARC aggregate report shows both SPF and DKIM failing on the same messages.

This feels like a broken setup. In most cases it is not, but you need to know how to tell the difference before you start changing things that do not need changing.

What both failing actually means

Two different problems produce the same report.

Misconfiguration: your SPF record or DKIM key is wrong, or one was set up incorrectly.

Forwarding: the email was forwarded after Google sent it. The forwarder is not in your SPF record, and forwarding often strips DKIM signatures.

The fastest way to tell them apart is to check the Source IP in your DMARC report. If it is not Google's IP range, you are not looking at a Google Workspace setup problem.

Cause 1: email forwarding (most common)

When an email is forwarded from a Google Workspace user to a personal Gmail, Yahoo, or other account, the original SPF check applies to Google's servers, not the forwarder. The forwarder is not in your SPF record. SPF fails. Many forwarders also strip DKIM signatures.

The DMARC report from the final receiving domain shows both SPF and DKIM failing. Google's authentication was correct. The forwarding chain broke it.

This is not a misconfiguration. Your setup is fine.

Cause 2: DKIM selector mismatch

Your DKIM key is published at a specific selector: google._domainkey.yourdomain.com or a custom selector you set.

Google sends mail using one selector. If the selector in your DNS does not match the selector Google is using, DKIM verification fails.

1. Go to Apps → Google Workspace → Gmail → Authenticate email
2. Find the DKIM selector Google is using
3. Compare it to your DNS record at selector._domainkey.yourdomain.com

If they do not match, regenerate your DKIM key in Google Admin and update the DNS TXT record. Allow time for propagation before retiring the old key.

Cause 3: third-party senders using your domain

Third-party platforms like marketing automation and SaaS tools are not covered by your Google Workspace SPF and DKIM. If they send from your domain without their own DKIM signing, both SPF and DKIM fail at the receiving server.

Check which IPs are failing. If a Source IP is not a Google server and not in your SPF record, it is a third-party sender. Authorize them properly or remove them from your sending infrastructure.

How to read your reports for this scenario

• Source IP: which server actually sent it. If not Google, it is not a Google Workspace auth failure.
• SPF result: pass or fail for the envelope domain.
• DKIM result: pass or fail for the selector domain.
• DMARC result: pass or fail for alignment.

Source IP is your first diagnostic column. If the sending server is not Google, you are looking at forwarding or a third-party sender. That one field resolves most false alarms.

Quick triage checklist

1. Check the Source IP. If not Google's IP range, your setup is not the problem.
2. Ask users about forwarding. Auto-forwarding to external accounts is the most common source of simultaneous failures.
3. Verify DKIM selector. Compare the Google Admin selector against your DNS TXT record and regenerate if mismatched.
4. Audit third-party senders. Identify IPs sending as your domain without authorization.
5. Check receiving domain patterns. If only large receivers like Gmail and Yahoo show failures, it is likely forwarding artifacts.

When this is normal

Low-volume simultaneous failures, under 1 to 2 percent of total, from large receivers like Gmail and Yahoo are often normal. These receivers handle huge volumes of forwarded and multi-hop mail.

What is not normal is sudden high-volume failures after a configuration change, or failures from your primary direct-sending partners.

The short version

Both SPF and DKIM failing is usually forwarding, not misconfiguration. Check Source IP first. If it is not Google, your setup is fine.

If the Source IP is Google and both fail, check your DKIM selector match, then audit third-party senders. Those are the two real configuration problems behind simultaneous failures.

Read your aggregate reports with Source IP as your first diagnostic column. Tools like DMARCFlow processes those reports and maps your sending sources against their authentication results, so if failures are clustering at Gmail and Yahoo rather than coming from Google's own infrastructure, you can see that pattern immediately rather than cross-referencing raw XML fields. Where a genuine misconfiguration exists, the suggestions panel flags the specific cause, DKIM selector mismatch, unauthorized sender, alignment failure, so you know what actually needs fixing.