Do I need both SPF and DKIM, or is one enough?

One passing, aligned mechanism satisfies the baseline requirement and satisfies DMARC. Google's bulk sender requirements ask for both, and there is a practical reason beyond compliance: SPF breaks on forwarding and DKIM breaks on messages modified in transit, so having both means one usually survives.

Why does Gmail say unauthenticated when SPF passes?

Because SPF passed for a domain other than the one in the From: header. Compare smtp.mailfrom in the Authentication-Results header against header.from. If SPF passed for your ESP's bounce domain, it authenticated the vendor, not you, and it does not align.

Does p=none in my DMARC record cause this rejection?

No. The DMARC-policy variant of 5.7.26 fires when the policy is quarantine or reject. A p=none record satisfies the requirement to have DMARC published while asking receivers to take no enforcement action, which is why it is the right starting point.

I only send a handful of messages a day. Do the bulk rules apply?

The bulk-specific requirements — both SPF and DKIM, a DMARC record, and one-click unsubscribe — are tied to a volume threshold Google publishes. Below it, the baseline still applies: you need one passing authentication mechanism, valid reverse DNS, and TLS. Meeting the bulk requirements anyway costs little and removes the question entirely.

Everything passes in my test but production mail is still rejected. Why?

Test mail usually leaves through a different path than production. Check whether production sends from a different IP, a different Return-Path domain, or through a relay that is not in your SPF record. The sending IP named in the bounce is the definitive answer to which path was actually used.

How quickly does the rejection stop after I publish the records?

As soon as Google's resolvers see the new records, since authentication is evaluated per message rather than cached as a verdict about you. The delay is DNS caching: the previous answer is held for its TTL, so lower TTLs before a planned change and expect up to the old TTL afterwards.

Gmail "550 5.7.26 Unauthenticated Email" — the Fix

This is one of the more helpful rejections in email, because Gmail usually tells you exactly which check failed. The bounce arrives in two common shapes, and which one you got narrows the fix considerably.

550-5.7.26 This mail has been blocked because the sender is unauthenticated.
550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM.
550-5.7.26 Authentication results:
550-5.7.26  DKIM = did not pass
550-5.7.26  SPF [example.com] with ip: [203.0.113.25] = did not pass

Shape 1 — no authentication at all passed

550-5.7.26 Unauthenticated email from example.com is not accepted due to
550-5.7.26 domain's DMARC policy. Please contact the administrator of
550-5.7.26 example.com domain if this was a legitimate mail.

Shape 2 — the domain publishes an enforcing DMARC policy and this message did not satisfy it

Shape 1 means you have no working SPF and no working DKIM for the sending path. Shape 2 means the domain owner has published p=quarantine or p=reject and this particular message failed alignment — which is a different problem, and usually a more subtle one.

What does Gmail actually require?

Google publishes sender requirements with two tiers. Every sender must meet the baseline; senders who exceed Google's bulk-sending threshold must meet a stricter set. Google states the exact volume threshold and the current spam-rate figure in its own sender guidelines and in Postmaster Tools, and those numbers do get revised — check the current published values rather than a figure copied from a blog post.

Requirement	All senders	Bulk senders
SPF or DKIM passing for the sending domain	Required	Both required
DMARC record published for the `From:` domain	Not required	Required (`p=none` is enough to satisfy it)
`From:` domain aligned with SPF or DKIM	Not strictly required	Required
Valid forward-confirmed PTR on the sending IP	Required	Required
TLS on the SMTP connection	Required	Required
One-click unsubscribe (RFC 8058) on marketing mail	Not applicable	Required
Reported spam rate kept below Google's published threshold	Expected	Enforced

Alignment is the requirement people miss. A message can have spf=pass *and* dkim=pass and still be treated as unauthenticated, because both passed for a domain that is not the one in the From: header. Gmail cares about the domain your recipients see.

How do you confirm what failed?

Send a message from the affected system to a Gmail address you control — if it is being rejected outright, send to a Gmail-hosted address on a different domain, or use any external mailbox and read the header there. In Gmail, open the message, use "Show original", and read the Authentication-Results line.

Authentication-Results: mx.google.com;
       dkim=pass [email protected] header.s=selector1 header.b=Ab1Cd2Ef;
       spf=pass (google.com: domain of [email protected] designates
             203.0.113.25 as permitted sender) smtp.mailfrom=mail.example.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

A passing result — compare header.from against smtp.mailfrom and header.i / header.d

spf=pass with smtp.mailfrom= on a vendor domain → SPF authenticates but does not align. Fix with a custom Return-Path on your domain.
dkim=pass with header.d= on a vendor domain → DKIM authenticates but does not align. Ask the vendor to sign with a key on your domain.
spf=permerror → your record is structurally broken, most often more than ten DNS lookups or two v=spf1 records.
spf=temperror → DNS failed to answer during evaluation. Check nameserver health with the NS lookup and DNSSEC checker.
dkim=neutral (body hash did not verify) → the message is being modified after signing. See body hash did not verify.
dkim=none → nothing signed the message at all.

Email Header Analyzer

Decode Received chains, SPF/DKIM/DMARC results, and delays

The fix, in order

1. Publish a single, valid SPF record

# Must return exactly one v=spf1 string
dig +short TXT example.com | grep spf1
dig +short TXT example.com | grep -c spf1

Two records, or zero, both mean SPF cannot pass

Include every service that sends with your domain in the Return-Path, keep the total DNS-querying mechanism count at ten or below, and end with ~all while you are still discovering senders. Build it with the SPF generator and count the chain with the SPF checker. If you are on Google Workspace, the correct record is one short include.

2. Turn on DKIM signing and publish the key

DKIM is the more valuable of the two, because it survives forwarding and mailing lists in a way SPF does not. Generate the key in your mail platform, publish it at selector._domainkey.example.com, and only then enable signing — publishing after you enable produces a window of dkim=fail that is worse than no signature.

# Google Workspace default selector
dig +short TXT google._domainkey.example.com

# Microsoft 365 publishes two CNAMEs, not TXT records
dig +short CNAME selector1._domainkey.example.com
dig +short CNAME selector2._domainkey.example.com

Verifying a published DKIM key

Do not know your selector? How to find your DKIM selector covers reading it from a message header, provider defaults, and discovery. The DKIM checker will probe common selectors for you.

3. Fix alignment

You need one of these two, not both. Whichever is easier with your vendor:

SPF alignment — configure a custom Return-Path / bounce domain at the ESP, typically something like mail.example.com, and publish that subdomain's SPF record with the vendor's include in it. The MAIL FROM domain then shares your organizational domain and aligns under DMARC's default relaxed mode.
DKIM alignment — have the vendor generate a key for your domain and publish the record they give you (usually a CNAME to their key). The d= tag on the signature then reads example.com and aligns.

4. Publish DMARC

Start at p=none with an aggregate report address. It satisfies the bulk-sender requirement for having a policy, and the reports are the only reliable inventory of who sends as your domain.

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1"

A safe starter DMARC record

Build it with the DMARC generator, verify with the DMARC checker, and tighten it using the staged plan in p=none vs quarantine vs reject.

5. Fix PTR and TLS

# Reverse must resolve, and forward must come back to the same IP
dig +short -x 203.0.113.25
dig +short A mail.example.com

# Confirm the MTA offers STARTTLS and a valid certificate
openssl s_client -starttls smtp -connect mail.example.com:587 -crlf < /dev/null 2>&1 \
  | grep -E "subject=|Verify return code"

Reverse DNS and STARTTLS checks on the sending host

PTR is configured by whoever owns the IP block, not in your DNS zone — see set a PTR record on your VPS and check it with the reverse DNS lookup. The same requirement now applies at Yahoo and Microsoft, covered in PTR records are now required.

What if you are a bulk sender?

Authentication gets you accepted; it does not get you into the inbox. Once 5.7.26 stops, the remaining work is complaint rate and list hygiene. Add a List-Unsubscribe header with the RFC 8058 one-click POST form, honour unsubscribes quickly, stop mailing addresses that have not engaged, and watch your reported spam rate in Postmaster Tools. A domain that authenticates perfectly and generates complaints will still be filtered — Gmail simply stops telling you about it in a bounce.

If you were rejected with shape 2 — the DMARC-policy variant — and you are not the domain owner, you are sending as someone else's domain. That is normal for a vendor or a forwarder, and the fix belongs with the domain owner: they must either authorize you in SPF or let you sign with their DKIM key. Do not work around it by rewriting the From: header to your own domain unless you understand what that does to replies.

Once the records are published, run the deliverability test for a combined view, then send a real message and read the header. Authentication is evaluated per message, so the moment Gmail's resolvers see the corrected records, the rejection stops.