SPF and DKIM pass, but DMARC fails? Check which domains authenticated

Find three domains in one failed message

Gaon sends its newsletter through an external service using news@example.com. Here is an illustrative set of headers from the receiving server. Long signature values and unrelated fields have been omitted.

From: Gaon Trading News <news@example.com>
Return-Path: <bounce@mailer.example.net>
DKIM-Signature: v=1; d=mailer.example.net; s=send; ...

Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=mailer.example.net;
  dkim=pass header.d=mailer.example.net;
  dmarc=fail header.from=example.com

Write down the domain after @ in the From address. This is the domain DMARC checks against. Then compare it with smtp.mailfrom in the SPF result and header.d in the DKIM result.

MAIL FROM is the envelope address used during server-to-server delivery, including for delivery failure notices. You can usually find it in the received message's Return-Path, but use the receiver's authentication results to establish what SPF actually checked. DMARC does not compare the display name or the address in Reply-To. SPF and the MAIL FROM identity ↗

Open the received original and identify the trusted result

In Gmail on the web, open the received message, select the More menu beside Reply, and choose Show original. Other mail applications provide a message-source or internet-headers view. Use the copy at the receiving end; the sender's Sent folder does not show the receiving server's checks. Viewing full headers in Gmail ↗

A message may contain several Authentication-Results headers. Do not choose whichever comes first or happens to say PASS. Senders can insert a header with the same name, and even a familiar server name in that header is not proof that it is trustworthy. Use results recorded within the receiving service's trusted boundary. If you cannot identify them, ask its administrator to review the original message and sending time. Forged authentication headers and trust boundaries ↗

If authentication results are missing, or the message bounced before you could obtain a received original, do not assume a DMARC failure. Collect the delivery log and bounce response and establish what the receiver reported.

Authentication and alignment must succeed through the same method

Gaon's SPF PASS says the connecting server is authorized by mailer.example.net. Its DKIM PASS says the signature for mailer.example.net is valid. Neither result establishes authorized use of example.com.

DMARC compares a successfully authenticated domain with the From domain. When the two meet its matching rules, they are aligned. A message needs at least one complete passing route below. DMARC alignment rules ↗

Suppose SPF passes for the service domain but DKIM fails for the company domain. You cannot combine SPF's PASS with DKIM's company name to produce a DMARC pass. Seeing d=example.com in a signature is insufficient; that signature must also verify successfully.

With multiple DKIM signatures, match each domain to its own result

A service may attach both its own signature and its customer's signature. Read each signature's d= domain, s= selector, and verification result together. One valid signature aligned with the From domain is enough for DMARC to pass through DKIM. DKIM signing domains and multiple signatures ↗

The first row is the easy one to misread: the passing signature and the company-domain signature are different signatures. If a tool collapses several results into one summary, open its detailed view or obtain the full headers.

Relaxed and strict alignment define how domains must match

Some services use a company subdomain such as bounce.example.com for the return address. Whether that aligns with a From domain of example.com depends on aspf and adkim.

aspf controls SPF alignment; adkim controls DKIM alignment. Both default to relaxed mode, r, which allows domains with the same organizational domain. Strict mode, s, requires an exact domain match. The comparison concerns domains, so different mailbox names such as news@ and bounce@ do not themselves cause alignment failure. Microsoft's explanation of alignment modes ↗

The final domain contains the company name at the beginning, but it is not a subdomain of example.com. The similar-looking examp1e.com is a separate domain too. Relaxed alignment does not accept similar spellings.

Nor can you always identify an organizational domain by taking the last two labels. Public suffixes such as co.uk span multiple labels, and the current DMARC standard defines a DNS tree walk to establish organizational boundaries. For a complex subdomain structure, check the policy actually applied and the receiver's result. Organizational domains and DNS policy discovery ↗

adkim=r; aspf=r is a practical starting point when legitimate services use your subdomains. Choose s when exact matching serves a specific requirement and the relevant sending routes can meet it. Before changing an existing strict setting, understand why it was selected. In Gaon's example, changing to relaxed mode would not help: the service authenticates an entirely different organizational domain.

Configure the newsletter service to sign with the company domain

Suppose Gaon's newsletter provider supports custom DKIM. It can add a valid signature for the company domain while leaving the service's return address unchanged.

1. Register the sending domain with the newsletter service

   Add example.com in the actual service's domain authentication settings. Enabling DKIM in Google Workspace or Microsoft 365 does not sign mail sent independently by the newsletter provider.

2. Publish the DNS records issued by that service

   Copy each record's name, type, and value or target as a set. Add every record the provider requires. Do not combine a key or CNAME target issued to another organization with your own domain.

3. Verify DNS and enable signing

   Check whether the DNS interface appends your domain automatically. Finish the service's verification and turn on signing. Domain ownership verification alone may not enable DKIM on real campaigns.

4. Send a fresh test through the same campaign route

   Use news@example.com and an external test mailbox. Check the received original for DKIM PASS on the company domain, even if the service's dashboard already says setup is complete.

For a signature containing d=example.com; s=nl2026, the public-key lookup is nl2026._domainkey.example.com. That example explains where the receiver looks; use the selector and DNS values actually issued to you. Some providers publish the key in TXT, while others use CNAME to point to a provider-managed key. How DKIM finds the public key ↗

Google likewise treats publishing DNS, starting authentication, and checking received mail as separate steps. A key can exist without the sender actually using it. Google's DKIM activation and verification steps ↗

From: Gaon Trading News <news@example.com>
Return-Path: <bounce@mailer.example.net>
DKIM-Signature: v=1; d=example.com; s=nl2026; ...

Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=mailer.example.net;
  dkim=pass header.d=example.com header.s=nl2026;
  dmarc=pass header.from=example.com

MAIL FROM is still mailer.example.net, so SPF still does not align. But DKIM now passes for example.com, which matches From, and DMARC passes. This shortened example shows only the company signature. A provider signature may also remain on the real message.

To align through SPF, the service needs a custom MAIL FROM

If the provider supports it, you can use a company subdomain such as bounce.example.com for the envelope return address. Configure custom MAIL FROM in that service and publish the DNS records it issues. Amazon SES, for example, requires SPF and MX records for this return domain. Follow the provider's specific requirements; substituting your employee-mail MX is not equivalent. Custom MAIL FROM in Amazon SES ↗

Then check for SPF PASS with smtp.mailfrom=bounce.example.com. With From set to example.com, it aligns under aspf=r but not aspf=s. Correcting alignment for external senders ↗

If neither method is supported, ask the provider whether it can send through a route authenticated for your company; changing service may be necessary. Changing only From to a company subdomain does not resolve a mismatch with the provider's separate domain.

If direct delivery passes, compare what changes during forwarding

Suppose Gaon's corrected newsletter fails only when it passes through a customer's automatic forwarding address. Compare what the intermediary changes. This example concerns automatic forwarding that preserves the original From address.

If the forwarder preserves MAIL FROM, the final receiver checks the forwarder's IP against the original domain's SPF policy. SPF may fail if that IP is not authorized. A valid, aligned company DKIM signature can still allow DMARC to pass. How forwarding affects authentication ↗

SRS can help SPF without restoring alignment

Some forwarding services use Sender Rewriting Scheme, or SRS, to replace MAIL FROM with an address at their own domain. SPF may then pass. But if that domain is forwarder.example.net and From remains example.com, it does not align. Microsoft explicitly notes that SRS alone does not resolve DMARC problems. Microsoft on SRS and DMARC ↗

A mailing list or security gateway can also break DKIM by changing a signed subject or appending text to the body. Distinguish a company-domain signature that fails verification from a passing signature with the wrong domain. The former calls for checking keys and changes after signing; the latter calls for checking the sending-domain configuration. Original messages from both sides of the change and the verification error help narrow the cause. Message modifications and DKIM ↗

ARC carries an intermediary's authentication observations in a signed chain. The final receiver can consider the chain's validity and its trust in that intermediary when deciding what to do. Valid ARC does not force DMARC to PASS. A receiver accepting a message despite a DMARC failure is different from the message passing DMARC. The purpose and operation of ARC ↗

Collect a directly received copy and a forwarded copy. Compare the connecting IP, MAIL FROM, and company DKIM result, then ask the forwarding administrator about signature preservation, SRS, and ARC. Adding every external forwarder to the company SPF record is not a sound starting point.

Test with a new message and separate the remaining causes

Changing DNS cannot change the FAIL stored in yesterday's message. It records what happened then. Once DNS and service settings are ready, send a new message through the route that originally failed.

Use the same newsletter service, From address, and type of campaign. Confirm company DKIM PASS and DMARC PASS, then test any forwarding route separately. A successful message sent manually from an employee's Gmail account does not verify the newsletter fix.

permerror means the SPF policy could not be correctly interpreted or evaluated. temperror indicates a temporary problem, such as a DNS failure. Neither is SPF PASS, even if the domain looks right. Read the specific error instead of grouping every failure under alignment. SPF result definitions ↗

If a valid aligned method appears to be present but DMARC still fails, revisit your interpretation. You may be combining results from different receivers or overlooking a subdomain policy. Ask the receiving administrator which From domain and policy were evaluated before adding more DNS records.

After a real campaign, check aggregate reports for improvement on the same sending route. RUA is aggregated, so investigate an individual message through its original headers and delivery logs. DMARC aggregate reporting ↗ Authentication can pass while spam placement or other rejection reasons remain, so record those delivery outcomes separately.

Changing policy to p=none or adding a sender to an inbox allowlist does not correct alignment. A completed fix should let you show which authenticated domain changed and which method now allows a fresh message to pass.