DNS Verification Failures (SPF/DKIM/DMARC)

Add exists:%{i}._spf.inkyphishfence.com to your domains SPF record to ensure passing checks.

Full example with M365 for reference:

v=spf1 include:spf.protection.outlook.com exists:%{i}._spf.inkyphishfence.com -all

The exists mechanism is used to construct an arbitrary host name that is used for a DNS ‘A' record query. These 'A’ records are all of the current INKY IP addresses and will include any future address.

Why do I see SPF, DKIM, and DMARC failures in my message headers after enabling INKY?

When you receive an inbound message into your mail environment the message is checked for the basic DNS verification checks (SPF/DKIM/DMARC). These are the true authentication checks as they are directly validating that the message originated from a legitimate source. If a message fails an (SPF/DKIM/DMARC) check at this stage, the message is either illegitimate or there is likely an issue with the sender's infrastructure. You can view the status of this stage’s (SPF/DKIM/DMARC) checks in the INKY admin dashboard under the threat details tab or in the INKY visualization dashboard under the more tab.

https://inkyops.atlassian.net/wiki/spaces/ICSS/pages/561643558 https://inkyops.atlassian.net/wiki/spaces/ICSS/pages/1122893833/Visualization+Dashboard+-+Message+Details#More-Tab

After the message has been received into your mail environment, the message will be redirected to INKY for processing and analysis. Once this has been completed, the message will be sent back to your mail environment and will originate from an INKY IP address. At this point, your mail environment will perform a second SPF/DKIM/DMARC check on the message, and this time all three checks will ultimately fail. This is a result of your mail environment verifying the sending (FROM:) domain’s SPF record against the INKY IP address the message is originating from. Additionally, when INKY inserts a banner into the message the DKIM signature (if any) will naturally break.

The mail flow scenario described above is expected behavior and nothing to be concerned with. If you have any questions or need clarification, please reach out to support@inky.com.

Office 365 Example:

Authentication-Results: spf=fail (sender IP is 3.231.237.226)
smtp.mailfrom=microsoft.com; yourdomain.com; dkim=fail (body hash did not
verify) header.d=microsoft.com;yourdomain.com; dmarc=fail action=oreject
header.from=microsoft.com;

Google Workspace Example:

ARC-Authentication-Results: i=4; mx.google.com;
       dkim=neutral (body hash did not verify) header.i=@yourdomain.com header.s=selector2 header.b=RzU1bfds;
       arc=pass (i=3 spf=pass spfdomain=domain.com dkim=pass dkdomain=domain.com dmarc=pass fromdomain=yourdomain.com);
       spf=softfail (google.com: domain of transitioning john.smith@yourdomain.com does not designate 209.85.222.198 as permitted sender) smtp.mailfrom=john.smith@yourdomain.com

What is an SPF Record?

SPF (Sender Policy Framework) records are a component of DNS authentication that offers basic protection against malicious actors from spoofing your domain across the internet. In its simplest form, an SPF record allows the recipient mail server to validate mail originated from a trusted source designated by the sender. For a more in-depth explanation of SPF please review the following link.

What is a DKIM Record?

DKIM (DomainKeys Identified Mail) is another component of DNS authentication that prevents phishing, spoofing and spam. DKIM works by applying a message signature at the last mail hop prior to the message being sent to the recipient. The recipient then verifies the signature against a cryptographic key that exists in the sender's public DNS records. If the message has been modified at any point between when it was signed and when it is verified, the DKIM verification will fail. More information regarding DKIM can be found here.

Should I add INKY’s IP addresses to my SPF Record?

No. INKY should never be the last message hop before being sent to the recipient mail server. Because of this, the recipient mail server should always see the IP address connecting from Office 365, Google Workspace, or your upstream provider.