3432810 - Inbound Monitor captures MTA DMARC Verdict Failed or MTA DKIM Verdict Failed

Image/data in this KBA is from SAP internal systems, sample data, or demo systems. Any resemblance to real data is purely coincidental.

• Customer is receiving Failed transmissions due to MTA DMARC Verdict Failed or MTA DKIM Verdict Failed.
• Error Message:
  • Example: "MTA DKIM Verdict Failed" or "MTA DMARC Verdict Failed."
• Inbound emails fail to process due to authentication errors.
• Observed issues include:
  • Missing DKIM signatures.
  • SPF softfail or fail.
  • DMARC failures due to alignment issues.
• This article provides step-by-step instructions to troubleshoot and resolve email authentication failures caused by DKIM, SPF, and DMARC issues when processing inbound emails in Service Cloud. It highlights the typical flow of inbound emails, where emails are first received by the customer’s exchange email server before being forwarded to the Service Cloud V2 technical email address. 

• SAP Service Cloud Version 2
• SAP Sales Cloud Version 2

1. Go to Settings -> Emails -> Inbound Monitoring
2. Some channels show the error "MTA DMARC Verdict Failed" or "MTA DKIM Verdict Failed"

• For inbound emails, the email flow involves the following steps:
  1. Emails are sent by the sender to the customer’s exchange email server.
  2. The customer’s exchange server forwards the email to the Service Cloud V2 Technical Email Address.
  3. The Service Cloud validates the email using authentication mechanisms like SPF, DKIM, and DMARC.
• It is important to understand that if the SPF record fails, simply adding the domain as a trusted domain in Service Cloud V2 under the MTA Configuration will not resolve the issue. Additional steps must be taken to ensure SPF alignment and proper email authentication. 
  
  • SAP expects that all customer infrastructures properly validate their SPF checks.
  • It’s essential that your forwarding server is acknowledged as a valid sender IP by your domain, ensuring that every message sent is reliably and securely delivered.
• Inbound emails trigger application verification of MIME for the trusted domain during AWS SES authentication checks.
• If DKIM signature succeeds but DKIM/DMARC verification fails, application permits email interaction creation.
• Technical Explanation:
  • SPF (Sender Policy Framework): Validates sending IP against the domain in the Return-Path.
  • DKIM (DomainKeys Identified Mail): Validates digital signature integrity.
    • DKIM works by allowing the sender to sign their emails with a private key. 
    • When the email is received, the receiving server uses the public key (published in the sender's DNS records) to verify the integrity of the message.
    • A crucial part of this process is ensuring that the body-hash, a component of the DKIM signature, matches the content of the email.
    • If any modification occurs to the email body after it has been signed, the body-hash will not match, causing the DKIM verification to fail.
  • DMARC (Domain-based Message Authentication, Reporting, and Conformance): Enforces alignment between SPF/DKIM and the From address domain.
• Failures commonly occur when:
  • The customer’s mail relay modifies email content or headers post-DKIM signing.
  • SPF validation fails due to the relay’s IP not being authorized.
  • The customer’s relay does not update the Return-Path before forwarding, leading to SPF failure against a third-party or end-customer domain.

• Use the “Ignore DKIM and DMARC Checks for Inbound Emails” Setting 

  • ⚠️ Use with caution and consider the risks involved.
  • Admins can enable this option to allow processing of inbound emails based only on SPF checks.
    • Conditions:
      • SPF check must pass.
      • The domain must be added to Trusted Domains.
    • Note:
      • You may observe situations where the DKIM/DMARC is ignored, but users still need to manually "Reprocess" the emails.
      • This could be because the SFP record was either not provided/maintained or got a Soft-Failed. 
      • These are expected outcomes, hence reprocess is a manual safeguard which requires human intervention.
      • To resolve this, it is recommended the customer update the Return-Path to an address owned by the customer and the forwarding server should be now meet SPF requirements.

• Add Customer-Owned Domains to Trusted Domains

  • These domains must be owned by the customer
  • Domains assigned to Exchange/Email Servers forwarding emails to Service Cloud V2 .
  • Do not add end-customer domains—doing so misconfigures authentication and poses security risks.
    Steps:
    1. Go to User Profile Settings > Emails > Inbound Monitoring.
    2. Identify records with errors like “MTA DKIM Verdict Failed”.
    3. Download the MIME file.
    4. Open the MIME and locate authentication lines such as: dkim=pass header.i=@example.com;
    5. Copy the domain (omit the “@”).
    6. Navigate to MTA Configuration:
    7. Expand the left pane with the “>” arrow.
       • Click the ✏ pencil icon.
       • Click the ➕ plus button to add the domain under Trusted Domains.
    8. Save changes.
    9. Re-test email processing.
       • If issues persist, re-download the MIME file and review for continued SPF/DKIM/DMARC failures.

• If the Issue Persists, re-check the MIME file for: 

  • SPF misconfiguration: Ensure the SPF record includes the IP of the relay server.
  • DKIM signature issues: Ensure the relay doesn’t modify the email after signing.
  • Return-Path errors: Confirm the customer's relay updates the Return-Path to a customer-owned domain.

• Recommendations for Relay or Sender-Side Configuration

  • SPF Configuration 
    • Ensure SPF records include the relay IP.
    • Example: v=spf1 ip4:192.0.2.15 -all
  • DKIM Signing 
    • Enable DKIM signing on the customer’s exchange server.
    • Publish the public key in DNS as a TXT record:
      • Hostname: default._domainkey.example.com
      • Value: v=DKIM1; k=rsa; p=[public-key]
    • Optional: ARC (Authenticated Received Chain) 
      • Preserves original authentication results when forwarding.
    • Avoid Post-Signing Modifications
      • Ensure no intermediate servers alter the body or headers after DKIM signing.

• Example Scenarios

  • Scenario 1: Missing DKIM Signature
    
    • Headers:
      Return-Path: <john.doe@example.com>
      dkim=none; dmarc=fail header.from=example.com; 
    • Problem: DKIM signature is missing due to a misconfigured relay (e.g., mailserver.acmecorp.com). 
    • Fix:
      • Add acmecorp.com to Trusted Domains.
      • Configure DKIM on mailserver.acmecorp.com.
      • Publish DKIM public key in DNS.
      • Test and validate DKIM signature.
  • Scenario 2: SPF Softfail
    
    • Headers:
      Return-Path: <jane.smith@gmail.com>
      spf=softfail; dkim=pass; dmarc=fail;
    • Problem: The relay is not authorized to send on behalf of gmail.com. 
    • Fix:
      • Ensure Return-Path is rewritten to a customer-owned domain (e.g., mailer@acmecorp.com).
      • Add the domain to Trusted Domains.
      • Update SPF record for acmecorp.com to include relay IP.
      • Optionally, implement ARC.

• Important Clarification on Trusted Domains

  • Adding a domain to the Trusted Domains list helps in specific cases—but is not a blanket override.
    • If DKIM passes but DMARC fails due to misalignment, trusting the domain may allow email processing. 
    • If SPF fails, the domain's SPF record must be corrected. Trusting alone won’t help.
    • If DKIM fails due to body/header modifications post-signing, the email will still be rejected—even if the domain is trusted.
    • Only customer-owned domains—from which emails are forwarded—should be trusted. Do not trust end-customer domains.
  • SAP cannot globally disable authentication checks due to platform-wide security risks. Customers are responsible for ensuring that any domain added to the trusted list complies with internal security policies.

Handling DKIM/DMARC Failures in Inbound Emails

MTA DMARC Verdict Failed, MTA DKIM Verdict Failed, Inbound Email, Error, SPF, Domains, Return-Path, Header, MIME, DKIM Signature, Failure, Service Cloud , KBA , CEC-CRM-CHN , Channels for SAP Sales/Service Cloud , CEC-CRM-EML , Emails for SAP Sales/Service Cloud , Problem