A passing SPF or DKIM check is not enough for DMARC. At least one passing result must also align with the domain in the message's visible From: address. A sending subdomain can make this look confusing: SPF might pass for a vendor's bounce domain, DKIM might pass for the vendor's signing domain, and DMARC can still fail for outreach.example.com. Fix the identity your provider authenticates, then retest a real message before changing the DMARC policy.
This guide uses RFC 9989, the current DMARC standard published in May 2026, RFC 7208 for SPF, and Google's sender guidelines, checked October 22, 2026. The examples below use reserved example.com and example.net domains and are hypothetical; we have not tested a private sending account for this article.
Read the three identities before editing DNS
Send a controlled message through the actual mailbox and sequencer path to a Gmail address you own. Open Show original, then copy the relevant lines from From:, Return-Path:, DKIM-Signature, and Authentication-Results. Keep the message timestamp, provider, and sending mailbox in your private troubleshooting notes. Avoid sharing recipient addresses or entire headers publicly.
| Identity | Where it appears | What DMARC compares |
|---|---|---|
| Author domain | The domain in visible From: |
The reference domain. A display name does not change it. |
| SPF domain | The envelope sender shown by Return-Path: or smtp.mailfrom= |
It must both pass SPF and align with the author domain. |
| DKIM domain | d= in a valid DKIM signature or header.d= in the result |
It must both pass DKIM and align with the author domain. |
RFC 9989, section 4.4 says either aligned SPF or aligned DKIM can satisfy DMARC; both are valuable to configure, but a DMARC pass does not require both on a particular message. The domain used for the DMARC policy lookup is the author domain, not whichever vendor happened to pass SPF. Read the actual received result because forwarding, rewriting, or a different campaign sending path may change what passes.
Worked example: authentication passes, alignment fails
Imagine a message sent from Maya <maya@outreach.example.com> with these illustrative results:
From: Maya <maya@outreach.example.com>
Return-Path: <bounce-123@vendor-mail.example.net>
Authentication-Results: mx.example.org;
spf=pass smtp.mailfrom=vendor-mail.example.net;
dkim=pass header.d=vendor-mail.example.net;
dmarc=fail header.from=outreach.example.com
Both authentication methods worked for vendor-mail.example.net. Neither domain shares the organizational domain example.com with outreach.example.com, so neither aligns. Adding include:vendor-mail.example.net to the root domain's SPF record does not change the message's Return-Path, and a new _dmarc.outreach.example.com record does not make the vendor's DKIM signature aligned. The sending provider must support a domain you control in its DKIM signing identity or envelope sender, or you must use another documented sending route.
Now suppose the provider changes DKIM to d=outreach.example.com and the received message shows dkim=pass header.d=outreach.example.com. DKIM is an exact match to From:, so DMARC can pass even if SPF still passes only for the vendor domain. Verify the selector record and the delivered signature, not only the DNS values on a setup screen. Our DKIM checker confirms a published selector; it cannot prove the sender actually signed this message. For Google Workspace-specific signing failures, use our DKIM troubleshooting guide.
Relaxed and strict alignment on a subdomain
RFC 9989 defines relaxed alignment as the same organizational domain and strict alignment as an identical domain. aspf controls SPF alignment and adkim controls DKIM alignment. If either tag is absent, the corresponding alignment mode defaults to relaxed. The policy owner can choose strict mode, so inspect the actual record instead of assuming it.
Visible From: |
Passing identity | Relaxed | Strict |
|---|---|---|---|
outreach.example.com |
SPF smtp.mailfrom=bounces.outreach.example.com |
Aligned: same organizational domain | Not aligned: names differ |
outreach.example.com |
DKIM d=example.com |
Aligned: same organizational domain | Not aligned: names differ |
outreach.example.com |
DKIM d=outreach.example.com |
Aligned | Aligned |
outreach.example.com |
SPF or DKIM at vendor.example.net |
Not aligned | Not aligned |
The table assumes the named SPF or DKIM check passes. A matching domain with spf=fail or dkim=fail does not rescue DMARC. Likewise, a dmarc=pass result does not mean both mechanisms aligned; one is sufficient. RFC 9989 cautions that DMARC pass validates authorized use of the author domain, not the quality or inbox placement of the message.
Find the policy that applies
Look up _dmarc.outreach.example.com and the relevant parent policy before changing anything. RFC 9989's policy discovery and sp tag rules govern how an organizational-domain policy applies to subdomains and when a subdomain-specific record takes precedence. A parent's sp= can specify handling for subdomains; p= can apply down the tree when no different subdomain preference is given. The policy controls requested handling of a DMARC failure, not whether SPF or DKIM domains align.
For a quick DNS inspection, use our DMARC checker, then confirm the exact TXT answer with a DNS query such as dig +short TXT _dmarc.outreach.example.com. If the sender publishes a dedicated subdomain record, verify it is valid and that it reflects the policy you intend. If the subdomain inherits the organizational-domain record, document that before creating a new one. Do not publish a second DMARC record at the same name or switch from p=reject to p=none just to make a broken stream look acceptable. RFC 9989 recommends beginning a new deployment with p=none and aggregate reporting so legitimate senders can be audited before enforcement; a policy change on an existing domain needs the same inventory and owner review.
Fix the sender in the lowest-risk order
- Confirm which path sent the failing message. A Google Workspace mailbox connected to a sequencer, a marketing platform, and a transactional service can sign differently. A test from the provider's preview may not represent a campaign send. Match the message ID and timestamp to the actual sending path.
- Enable the provider's documented custom DKIM domain. Add the exact DNS selector records it gives you, turn signing on where required, and wait until a new received message says
dkim=passforoutreach.example.comor a relaxed-aligned domain you own. Do not invent your own DKIM key or copy another account's selector. - Where supported, configure a custom envelope sender or Return-Path. This may be a bounce subdomain such as
bounces.outreach.example.com. Publish the SPF record the provider specifies at that envelope-sender domain and verify a new message'ssmtp.mailfrom. Under relaxedaspf=r, it can align withoutreach.example.com; under strictaspf=s, the names must match exactly. Some services do not offer a custom Return-Path, so an aligned DKIM pass may be the viable path. - Retest with a received message. Check
spf=,dkim=,dmarc=,header.from=,header.d=, andsmtp.mailfrom=together. A provider dashboard saying “authenticated” is only a setup signal. Keep the before and after results, then inspect aggregate DMARC reports for the other legitimate streams before changing policy.
Do not “fix” a strict-alignment failure by changing the visible From: to a vendor domain without considering who recipients think is writing. If strict aspf=s is intentional and the provider uses a bounce subdomain, align DKIM exactly to the From domain instead or get an owner-approved policy design. If SPF fails with permerror, the ten-DNS-lookup guide covers that separate defect. Replacing a failing SPF include will not, by itself, fix unaligned DKIM or a mismatched From:.
What the fix proves, and what it does not
The successful test proves that one received message from one sending path passed DMARC. Repeat it for each domain, provider, and meaningful sending path. Google's sender guidelines include authentication alongside DNS, TLS, formatting, spam-rate, and applicable unsubscribe requirements; Google does not promise inbox placement because a message passes DMARC.
In a May 2023 cold-email walkthrough, Jan advised setting up SPF, DKIM, and DMARC on every sending domain. That is a historical operating principle, not a claim that the same 2023 mailbox setup, volume, or deliverability advice is current. The actionable step today is to inspect the domains in each message and verify them against current provider documentation. If you manage many authenticated domains, DMARC monitoring tools for multiple sending domains covers the reporting and ownership side; Google Postmaster Tools setup covers the separate Gmail-visibility task.
