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 1.0
• SAP Sales Cloud Version 2 1.0

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:
  • 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.

Use the new "Ignore DKIM and DMARC Checks for Inbound Emails": (Please use with caution and consider the risks involved)

• As an administrator, you can choose to ignore DKIM and DMARC checks for inbound emails.
• Once configured, the inbound emails are then accepted and processed based only on the SPF check. If the SPF check is a Pass and the domain is maintained as a trusted domain, the emails arrive the system.

Add the offending Domain to the Trusted List of Domains:

1. 1. Navigate to User Profile Settings > Emails > Inbound Monitoring.
   2. Identify the failed record with the error message "ex. MTA DKIM Verdict Failed or MTA DMARC Verdict Failed."
   3. Download the MIME for the failed record by clicking "Download MIME."
   4. Open the downloaded file.
   5. Locate the authentication information, for example: dkim=pass header.i=@sap.com;
   6. Copy the domain address highlighted.
      • Ensure to exclude the "@" symbol from the domain address
      • Enter the copied domain address in the "Trusted Domains" section of the Email MTA configuration screen.
   7. Click on the ">" arrow to expand the left pane, and select the "MTA Configuration".
   8. Click the Pencil ✏ to activate the screen, then click the plus (+) to add a new entry.
   9. Paste the domain into the field, and save the changes
   10. Test. If the issue persists:
       1. Download the MIME per the Handling DKIM/DMARC Failures in Inbound Emails:
       2. Check if there is still SPF/DKIM/DMARC failures

If the Issue Persists: 

1. Re-download and review the MIME file to check for recurring SPF/DKIM/DMARC failures.
2. Identify possible causes:
   • SPF Misconfiguration: Ensure the SPF record includes the relay server IP.
   • DKIM Signature Issues: Verify that forwarding or intermediate servers are not altering headers.
   • Trusted Domains Configuration: Ensure the domain is listed correctly and referenced during validation.

Recommendations for the Relay Server or Sender Side:

1. SPF Configuration:
   • Ensure the SPF record includes the relay server’s IP.
   • Example SPF record:
     v=spf1 ip4:192.0.2.15 -all
2. Enable DKIM Signing:
   • Configure the customer’s exchange server to add a DKIM signature when forwarding emails.
   • Publish the DKIM public key in DNS using a TXT record.
   • Example:
     Hostname: default._domainkey.example.com
     Value: v=DKIM1; k=rsa; p=[public-key]
3. Implement DMARC-Compliant Forwarding (Optional):
   Use tools like ARC (Authenticated Received Chain) to preserve original authentication results when forwarding.
4. Check for Post-Signing Modifications:
   Identify if any intermediary systems modify the email body or headers after the DKIM signature is applied.

Dummy Examples:

Case 1: Missing DKIM Signature 

• Email Headers:
  Return-Path: <john.doe@example.com>
  Authentication-Results: smtp.server.com;
  spf=pass (domain of example.com designates 192.0.2.15 as permitted sender);
  dkim=none; dmarc=fail header.from=example.com;
  
  
• Problem:
  
  • The DKIM signature is missing for the relay server (mailserver.acmecorp.com), causing DMARC failure.
    
    
• Steps to Correct:
  1. Add acmecorp.com as a Trusted Domain in Service Cloud.
  2. Configure mailserver.acmecorp.com to add a DKIM signature.
  3. Publish the public key in DNS:
     Hostname: default._domainkey.acmecorp.com
     Value: v=DKIM1; k=rsa; p=[public-key]
  4. Test, and confirm the presence of the DKIM signature. 

Case 2: SPF Softfail 

• Email Headers:
  Return-Path: <jane.smith@gmail.com>
  Authentication-Results: smtp.server.com;
  spf=softfail (domain of gmail.com does not designate 192.0.2.15 as permitted sender);
  dkim=pass (signature verified) header.i=@gmail.com;
  dmarc=fail header.from=gmail.com;

• Problem:
  
  • The relay server (mailrelay.acmecorp.com) is not authorized to send on behalf of gmail.com, causing SPF softfail and DMARC failure. 
    
    
• Steps to Correct:
  1. Update the SPF record for acmecorp.com to include the relay server’s IP:
     v=spf1 ip4:192.0.2.15 -all
  2. Optionally, implement ARC to preserve authentication results for forwarded emails.

Conclusion

• By addressing configuration issues on both the Service Cloud and customer’s exchange server side, these steps ensure compliance with DKIM, SPF, and DMARC policies.
• The above steps should help with successful email processing and delivery to Service Cloud.
• If issues persist, further diagnostics or assistance from the sender's MTA may be required.

Important Clarification on Trusted Domains

Adding a domain to the Trusted Domains list can help in certain cases, but it does not guarantee that all emails from that domain will be accepted. Please note the following:

• If DKIM passes but DMARC fails (due to misalignment), adding the domain may allow the email to be processed.
• Should the SPF fails, adding the domain will not resolve the issue. The domain’s SPF record must be updated to include the relay or forwarding IP address.
• In the event, DKIM fails because the email body or headers were modified after signing (e.g., by an intermediary mail server), the message will still be rejected, even if the domain is trusted.
• The Trusted Domains setting is not a bypass but a controlled exception mechanism intended for domains that are both trusted and properly configured.

SAP cannot globally relax authentication checks due to platform-wide security risks. Customers are responsible for ensuring that any domain added to this list is vetted and meets their internal security standards.

Handling DKIM/DMARC Failures in Inbound Emails

KBA , CEC-CRM-CHN , Channels for SAP Sales/Service Cloud , CEC-CRM-EML , Emails for SAP Sales/Service Cloud , Problem