Get SupportIf SPF and DKIM both look like they passed but DMARC failed, check alignment.
DMARC passes when at least one of these is true:
- SPF passes and its authenticated domain aligns with the domain in the visible From address.
- DKIM passes and a DKIM signing domain aligns with the domain in the visible From address.
A sending vendor can authenticate its own domain perfectly and still fail DMARC for your message. Find the misaligned source before you weaken the policy.
Confirm that DMARC actually failed
A checker warning is not the same thing as a failed message.
Start with one real message that followed the failing path. Save:
- the full
Authentication-Resultsheader; - the visible From address;
- the Return-Path or MAIL FROM domain;
- every DKIM
d=signing domain; - the receiving provider;
- the timestamp;
- the bounce or error text, if there is one;
- the sending source: Google, Microsoft, a sequencer, a support tool, a form, or another service.
Then separate three different conditions:
- Authentication failure: SPF or DKIM did not pass.
- Alignment failure: SPF or DKIM passed, but for a domain that does not align with the visible From domain.
- Policy mode: the domain publishes
p=none,p=quarantine, orp=reject.
A message can fail DMARC while the policy is p=none. That means the receiver evaluated the message as a failure but the published policy did not request quarantine or rejection. It does not mean DMARC passed.
Read the three domains that decide the result
Suppose the recipient sees this address:
person@example.com
The visible From domain is example.com. Now inspect the two authentication paths.
SPF uses the envelope domain
SPF checks whether the sending IP is authorized by the domain used in the SMTP envelope. In message headers, that domain commonly appears in the Return-Path.
If the Return-Path is bounce.example.com and SPF passes, the result can align with example.com under relaxed alignment because both share the same organizational domain.
If the Return-Path is vendor.example.net, SPF may pass for the vendor while remaining misaligned with example.com.
DKIM uses the signing domain
DKIM adds a cryptographic signature. The signing domain appears in the d= value.
If a valid signature uses d=example.com, DKIM can provide the aligned path DMARC needs.
If a valid signature uses d=vendor.example.net, DKIM authentication can pass while DMARC still fails for person@example.com.
Alignment is the bridge
DMARC connects authentication to the identity the recipient can see. That is why “SPF: pass” or “DKIM: pass” by itself is incomplete evidence.
| Visible From | SPF result / MAIL FROM | DKIM result / d= | DMARC | Reason |
|---|---|---|---|---|
person@example.com | pass / bounce.example.com | fail | pass | The passing SPF domain aligns under relaxed alignment |
person@example.com | pass / vendor.example.net | pass / example.com | pass | SPF is misaligned, but DKIM passes and aligns |
person@example.com | pass / vendor.example.net | pass / vendor.example.net | fail | Both methods authenticate the vendor domain, not the From domain |
Strict alignment requires an exact match. Relaxed alignment allows subdomains that share the same organizational domain. Most troubleshooting does not need a long standards lesson; it needs the three domains written next to each other.
Walk the DMARC failure tree
Use the result from one real message. Do not make several DNS changes at once.
1. Is there a DMARC result in the header?
If there is no DMARC evaluation, confirm that you are reading the final recipient's headers and that a valid DMARC record is published at _dmarc.example.com.
If multiple DMARC TXT records exist at the same name, fix that publication problem before investigating the message source. DMARC expects one policy record.
2. Did SPF pass?
If SPF failed:
- identify the envelope domain;
- confirm which service sent the message;
- inspect the authoritative SPF record for that domain;
- check for syntax errors, missing authorization, or lookup-processing errors;
- use the sending service's current instructions for the exact path.
Do not add every vendor you recognize to the visible From domain's SPF record. SPF needs to match the envelope domain and source used by the real message.
3. If SPF passed, did it align?
Compare the MAIL FROM or Return-Path domain with the visible From domain.
If they do not align, determine whether the sending service supports a custom bounce domain or another documented aligned SPF path. If it does not, DKIM may need to supply the aligned result instead.
4. Did DKIM pass?
If DKIM failed:
- find the selector and
d=domain in the signature; - query the selector at
<selector>._domainkey.<signing-domain>; - confirm that the public key is published in authoritative DNS;
- verify that DKIM signing is enabled in the sending system;
- check whether a forwarding or transit system modified signed parts of the message.
The fact that a DKIM record exists does not prove the failing message used it.
5. If DKIM passed, did it align?
Compare the valid signature's d= domain with the visible From domain.
Some messages have more than one DKIM signature. DMARC needs one valid, aligned signature—not every signature—to pass through DKIM.
If the only passing signature belongs to the vendor's domain, configure the sender's documented custom DKIM path for your domain if one is available.
6. Did forwarding or message modification change the path?
Forwarding commonly breaks SPF because the forwarding server is not authorized by the original envelope domain. DKIM can survive forwarding if the signed content is not changed.
A mailing list, security gateway, or forwarding service may modify the subject, body, or headers and break the signature. Capture the message before and after that hop if possible. The repair belongs at the system changing the path, not in an unrelated DNS record.
7. Which source owns the fix?
Name the exact source. “Our domain” is not specific enough.
The owner could be:
- Google Workspace;
- Microsoft 365;
- a cold email sequencer;
- a CRM;
- a ticketing system;
- a marketing platform;
- a website form;
- a billing or transactional mail service;
- a forwarder or security gateway.
Each source can have a different MAIL FROM domain, DKIM signing domain, and configuration owner.
Fix the source, not the symptom
Build a source inventory before changing policy.
| Field | What to record |
|---|---|
| Sending source | Product and exact message path |
| Owner | Person responsible for its configuration |
| Visible From | Domain the recipient sees |
| MAIL FROM | Envelope or Return-Path domain |
| DKIM signing domain | Every relevant d= value |
| SPF | Authentication result and alignment result |
| DKIM | Authentication result and alignment result |
| Transit | Forwarder, gateway, or modifier in the path |
| Current instructions | Official provider documentation used |
| Fix | Exact DNS or provider change |
| Retest | Header and timestamp from the same path |
Work one source at a time:
- Capture the failing evidence.
- Identify which aligned path should pass.
- Make the smallest supported change.
- Send through the same source again.
- Read the new final-recipient header.
- Record the result and owner.
If the second test uses a different sender, recipient provider, or transit path, it does not prove the first path is fixed.
Do not change the policy first
The policy tells receivers what the domain owner requests when DMARC fails:
p=nonerequests monitoring treatment;p=quarantinerequests suspicious-message treatment;p=rejectrequests rejection.
Changing from reject to none can change requested handling. It does not make a misaligned source aligned.
RFC 9989 became the current DMARC standard in May 2026 and replaced RFC 7489. It also removed the pct tag. Some provider documentation still shows the older standard and recommends pct as a rollout control. Do not assume that every receiver will apply it consistently under the current standard.
Use a source inventory, aggregate reports, controlled remediation, and separate test domains or subdomains when needed. Choose policy based on the domain's legitimate sources and evidence—not a universal template.
Google and Microsoft details worth checking
Google's troubleshooting documentation directs administrators to inspect message headers, alignment, SPF, DKIM, DMARC records, and aggregate reports. Google also documents the 5.7.26 authentication-related rejection family. Use the exact error text; similar-looking failures can have different causes.
Microsoft's documentation explains the same alignment relationship between the MAIL FROM, visible From, and DKIM signing domains. It also documents Microsoft-specific behavior for custom domains and messages that pass through Microsoft 365. Its page still references RFC 7489 and pct, so use it for Microsoft configuration details while using RFC 9989 for the current protocol rule.
Cheap Inboxes provides documented DNS and DMARC management workflows for domains in the service. The developer overview is the right product reference when you need to inspect the supported management path. It does not replace reading the header from the failed message.
The shortest useful DMARC checklist
When DMARC is failing:
- Capture one real failed message.
- Write down the visible From, MAIL FROM, and DKIM
d=domains. - Confirm whether SPF passed and aligned.
- Confirm whether any DKIM signature passed and aligned.
- Identify the exact sending source or transit hop.
- Fix that source using current provider documentation.
- Retest the same path.
- Verify the new header and aggregate reporting.
- Change policy only when the source inventory and evidence support the decision.
If the authentication path is healthy and the mail still has a problem, move to the broader cold email deliverability diagnostic. DNS is only one layer.