Authentication and DNS Failures

First 15 minutes

1. Capture the sending IP, MAIL FROM or fallback HELO identity, DNS response, and received Authentication-Results value.
2. Check for multiple SPF records, syntax errors, more than ten DNS-querying terms, and transient DNS lookup failures.
3. Inventory every service currently sending for the evaluated identity.

Now

• If authoritative DNS shows multiple SPF records or a syntax error, correct that record; if the active sender is absent at the evaluated MAIL FROM or HELO identity, add its authorization.

Next 24 hours

• Only if SPF evaluation exceeds ten recursive DNS-querying terms, reduce those terms to within the RFC limit.

Next 7 days

• Add sender-introduction change control so the SPF record is updated when a new service starts sending.

Technical checks

Verification criteria

• A newly received message shows SPF working in its headers after DNS propagation, which Google notes can take up to 48 hours.

Escalation criteria

• Escalate to DNS or the sending provider when temperror persists or a corrected record still returns permerror after authoritative and received-message checks.

Prevention

• Maintain one valid SPF record that includes every active sender and stays within the ten DNS-querying-term limit.

Business impact

• Mail from an omitted sending service is not authorized by the SPF record at the evaluated identity, and a DNS change may take up to 48 hours before a newly received message shows working SPF.

Provider notes

• Google advises header-based verification and notes that DNS changes can take up to 48 hours before SPF starts working.

Open questions

• No DNS response, SPF TXT record, evaluated MAIL FROM or HELO domain, sending IP, or received Authentication-Results header is supplied.
• The failure could be stable fail, permerror, temperror, none, or DMARC alignment failure mislabeled as SPF; the exact result must be preserved.
• Receiver handling of SPF results is local policy, and DNS propagation timing varies by provider and resolver cache.

First 15 minutes

1. Capture Authentication-Results, RFC 5322 From, MAIL FROM, and DKIM d= domains from an affected message.
2. Check whether the SPF-authenticated MAIL FROM domain passes and aligns with the author domain.
3. Check whether any valid DKIM d= domain aligns with the author domain.
4. Query the applicable _dmarc TXT record and confirm that v=DMARC1 is the first tag.

Now

• Correct the MAIL FROM identity when SPF passes but its authenticated domain does not align with the author domain.
• Correct the DKIM signing identity when a valid signature uses an unaligned d= domain.
• Repair a missing, misplaced, or malformed DMARC version tag at the applicable _dmarc record.

Next 24 hours

• Keep monitoring with aggregate reporting while legitimate unauthenticated or unaligned streams are remediated.

Next 7 days

• Advance toward enforcement only after legitimate sources have been inventoried and their authentication and alignment gaps are fixed.

Technical checks

Verification criteria

• A receiver-generated Authentication-Results header on an affected test shows DMARC pass through at least one valid aligned SPF or DKIM branch.
• Aggregate reports identify expected legitimate sources and no longer show their known missing or unaligned identifiers.

Escalation criteria

• Escalate to the deliverability or domain owner when aggregate reports reveal legitimate sources that cannot be identified or authenticated.
• Require explicit owner approval before weakening an existing enforcement policy during incident response.

Prevention

• Continuously inventory legitimate senders through aggregate reports and track missing or unaligned authenticated identifiers.
• Use monitoring mode and aggregate reporting before advancing enforcement, remediating legitimate streams first.

Business impact

• Until an affected message shows at least one valid aligned authentication branch, the team cannot demonstrate a message-level DMARC pass or make a safe sending decision.

Open questions

• No affected message's Authentication-Results, RFC 5322 From, MAIL FROM, DKIM d= domains, selector results, or current DNS response was provided.
• The failing branch is unresolved until message-level pass and alignment results are compared with the applicable DMARC policy.
• Receiver report coverage, indirect forwarding behavior, organizational-domain discovery, and strict versus relaxed alignment can vary by message path and receiver.

First 15 minutes

1. Capture the actual public source IP and the complete remote SMTP response, then separate Gmail 4.7.23 deferrals from 5.7.25 blocks.
2. Resolve the source IP to its PTR hostname and resolve that hostname back through A or AAAA to confirm it returns to the same IP.

Now

• Correct the PTR or forward A or AAAA record so the actual sending IP and its hostname resolve back to each other.

Next 24 hours

• Recheck the forward-and-reverse mapping on every active IP in the affected sending path after DNS changes are visible.

Next 7 days

• Document the verified PTR-to-hostname-to-IP mapping for each production sending IP and include it in infrastructure change checks.

Technical checks

Verification criteria

• A fresh public DNS lookup shows the sending IP's PTR hostname resolving through A or AAAA back to that same IP.
• Controlled Gmail samples no longer return 4.7.23 or 5.7.25 for the affected source IP.

Escalation criteria

• Escalate to the DNS or sending-platform owner if the mapping cannot be corrected, or to provider support if the exact 5.7.25 response persists after the mapping is verified.

Prevention

• Require a public forward-and-reverse DNS preflight for each sending IP before activation or infrastructure change.

Business impact

• Affected Gmail messages can be delayed by 4.7.23 deferrals or blocked by 5.7.25, interrupting time-sensitive customer communication.

Provider notes

• Gmail identifies reverse-DNS temporary deferrals with 4.7.23 and permanent blocks with 5.7.25 in the documented cases.
• Exchange Online's documented 5.7.25 reverse-DNS case is scoped to anonymous inbound IPv6 and should not be generalized to every Microsoft path.

Open questions

• The affected sending IP, its current PTR and forward DNS answers, and the exact Gmail SMTP response were not provided.
• The breadth of rejection across Gmail and other receiving providers is unresolved until SMTP outcomes are grouped by destination and source IP.
• Other mailbox providers can impose different reverse-DNS requirements and response codes.

First 15 minutes

1. Collect one affected message's Microsoft 365 Authentication-Results header and read SPF, DKIM, DMARC, and compauth from that same message.
2. Record the message-level SPF, DKIM, DMARC, and compauth results together from that receiving header.

Now

• Correct only the mechanism identified in the affected message: the SPF record or authorized IP, DKIM signing or selector, or DMARC alignment path.

Next 24 hours

• Send a controlled message through the same path and confirm that its authenticated domain now aligns with the visible From domain.

Next 7 days

• Add change checks that catch duplicate or excessive-lookup SPF records, missing DKIM selectors, and unaligned authenticated domains.

Technical checks

Verification criteria

• A newly received Microsoft 365 message reports the expected SPF, DKIM, DMARC, and compauth outcomes in Authentication-Results.
• The new sample has at least one passing SPF or DKIM identity aligned with the visible From domain when DMARC is expected to pass.

Escalation criteria

• Escalate to Microsoft 365 or the sending provider when the receiving header, message trace, and NDR disagree or authentication-driven rejection, quarantine, or junk placement persists after the identified fix.

Prevention

• Validate SPF structure and authorization, DKIM signing and selector DNS, and DMARC alignment from real received messages after every sending-path change.

Business impact

• Legitimate Microsoft 365 mail can be rejected, quarantined, or routed to Junk Email, delaying or hiding customer and operational messages.

Provider notes

• Microsoft 365's receiving header includes SPF, DKIM, DMARC, and Microsoft's compauth result; use that header as the message-level evidence.

Open questions

• No affected message headers, Authentication-Results fields, Microsoft 365 message trace, or NDR diagnostic were provided.
• The failing mechanism and alignment path are unresolved until the SPF, DKIM, and DMARC results are read from the same affected message.
• The affected domains, DNS records, forwarding path, gateway modifications, and business impact are not available.