Trusted Entity DNS Modification for Third-Party Email Authentication
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Companies face challenges in authenticating emails sent by third parties on their behalf, as existing email authentication methods like SPF and DKIM fail when the third party's email server IP or DKIM public key are not listed in the company's DNS records, leading to authentication failures.
Innovation Solution
A system and method where a trusted entity adds the third party's email authentication information, such as SPF records and DKIM information, to the company's DNS record, enabling successful authentication when the third party sends emails on behalf of the company's domain, by verifying the third party's authorization and modifying the DNS records accordingly.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If SPF record is configured to authorize the company's email server, then the company's emails are authenticated successfully, but the third party's emails cannot be authenticated because the third party's IP is not listed in the SPF record
Solution Approach 1:
The SPF record is segmented into multiple authorized IP addresses and hostnames, including both the company's email server and the third party's email server. This allows the SPF authentication mechanism to independently verify emails from different sources against the comprehensive authorized list in the SPF record, resolving the contradiction between authenticating company emails and enabling third party email sending.
Solution Approach 2:
The SPF record serves multiple functions by authorizing both the company's internal email server and external third party email servers. This multi-functional configuration allows a single SPF record to authenticate emails from diverse sources, eliminating the need for separate authentication mechanisms for company and third party emails.
2Reliability
If DKIM public key is published in the company's DNS record for signature verification, then the company's signed emails are authenticated successfully, but the third party's signed emails cannot be authenticated because the third party's public key is not stored in the company's DNS record
Solution Approach 1:
The DKIM authentication mechanism is segmented to accommodate multiple signing entities. The company's DNS record publishes multiple public keys corresponding to different private keys used by the company and the third party. This allows the verification process to independently check signatures from any authorized entity against the appropriate public key in the DNS record.
Solution Approach 2:
The company's DNS record serves the universal function of publishing public keys for multiple different email signing entities. This single DNS record configuration enables authentication of emails signed by both the company's private key and the third party's private key, providing multi-functional support for different signing capabilities.
3Reliability
If the third party is given direct access to modify DNS records to add their authentication information, then email authentication can be configured successfully, but the security risk increases due to potential unauthorized modifications
Solution Approach 1:
The company acts as an intermediary between the third party and the DNS record. Instead of giving the third party direct access to modify DNS records, the company receives the third party's public key or authentication information and responsibly adds it to the DNS record. This intermediary approach maintains security by controlling DNS modification access while still enabling third party email authentication.
Solution Approach 2:
The company performs preliminary verification and preparation before adding the third party's authentication information to the DNS record. The third party first provides their public key or authentication details to the company, which then validates and prepares the information before making the DNS record modification. This preliminary action ensures security and accuracy while enabling authentication.
Data Source
AI summary
A company may authorize a 3rd party to send emails on behalf of the company's domain. The emails are sent by the 3rd party, but the “From” portion of the email header is populated with the company's email address/domain. Methods are disclosed that, in some embodiments, enable email authentication (e.g. SPF record checks and/or DKIM verification) for emails sent by the 3rd party on behalf of a company's domain. In some embodiments, a trusted entity is enlisted to communicate with the 3rd party and the company. The trusted entity has the proper permissions to request changes in the DNS records of the company. The trusted entity receives the request from the 3rd party to add email authentication information to the DNS record. The trusted entity confirms that the 3rd party is authorized by the company and then adds the information to the DNS record.