Double DKIM - Revision history

Sebastian at 14:13, 7 October 2024

2024-10-07T14:13:46Z

← Older revision		Revision as of 16:13, 7 October 2024
Line 2:		Line 2:
	[[Category:Deliverability]]		[[Category:Deliverability]]
	[[Category:E-Mail_analysis]]		[[Category:E-Mail_analysis]]
			[[Category:Reporting]]
	[[Category:Authentication]]		[[Category:Authentication]]
	It commonly is best practice to [[Alignment\|align]] your domains when sending emails, such as your envelope-from domain ([[RFC5321.MailFrom]]), Header-From domain ([[RFC5322.From]]), [[Domain_Alignment#Hostname_/_HELO/EHLO\|hostname]], [[DomainKeys_Identified_Mail_(DKIM)#Public_and_private_key\|DKIM signing domain]] and [[Domain_Alignment#Link-_and_imagedomains_/_Sender_domains\|imagelink and link tracking domain]], meaning that ideally all these should be on the same [[Responsible domain\|responsible domain]] name.		It commonly is best practice to [[Alignment\|align]] your domains when sending emails, such as your envelope-from domain ([[RFC5321.MailFrom]]), Header-From domain ([[RFC5322.From]]), [[Domain_Alignment#Hostname_/_HELO/EHLO\|hostname]], [[DomainKeys_Identified_Mail_(DKIM)#Public_and_private_key\|DKIM signing domain]] and [[Domain_Alignment#Link-_and_imagedomains_/_Sender_domains\|imagelink and link tracking domain]], meaning that ideally all these should be on the same [[Responsible domain\|responsible domain]] name.

Sebastian at 16:50, 3 September 2023

2023-09-03T16:50:08Z

← Older revision		Revision as of 18:50, 3 September 2023
Line 1:		Line 1:
	[[Category:InboxSys]]		[[Category:InboxSys]]
	[[Category:Deliverability]]		[[Category:Deliverability]]
	~~[[Category:Reputation]]~~
	[[Category:E-Mail_analysis]]		[[Category:E-Mail_analysis]]
	[[Category:Authentication]]		[[Category:Authentication]]

Sebastian at 16:49, 3 September 2023

2023-09-03T16:49:11Z

← Older revision		Revision as of 18:49, 3 September 2023
Line 1:		Line 1:
	[[Category:InboxSys]]		[[Category:InboxSys]]
	[[Category:Deliverability]]		[[Category:Deliverability]]
			[[Category:Reputation]]
	[[Category:E-Mail_analysis]]		[[Category:E-Mail_analysis]]
	[[Category:Authentication]]		[[Category:Authentication]]

Sebastian at 16:33, 3 September 2023

2023-09-03T16:33:57Z

← Older revision		Revision as of 18:33, 3 September 2023
Line 1:		Line 1:
	[[Category:InboxSys]]		[[Category:InboxSys]]
			[[Category:Deliverability]]
	[[Category:E-Mail_analysis]]		[[Category:E-Mail_analysis]]
	[[Category:Authentication]]		[[Category:Authentication]]

Sebastian at 14:16, 3 September 2023

2023-09-03T14:16:12Z

← Older revision		Revision as of 16:16, 3 September 2023
Line 2:		Line 2:
	[[Category:E-Mail_analysis]]		[[Category:E-Mail_analysis]]
	[[Category:Authentication]]		[[Category:Authentication]]
	It commonly is best practice to [[Alignment\|align]] your domains when sending emails, such as your envelope-from domain ([[RFC5321.MailFrom]]), Header-From domain ([[RFC5322.From]]), [[Domain_Alignment#Hostname_/_HELO/EHLO\|hostname]], [[DomainKeys_Identified_Mail_(DKIM)#Public_and_private_key\|DKIM signing domain]] and [[Link-_and_imagedomains_/_Sender_domains:imagelink and link tracking domain]], meaning that ideally all these should be on the same [[Responsible domain\|responsible domain]] name.		It commonly is best practice to [[Alignment\|align]] your domains when sending emails, such as your envelope-from domain ([[RFC5321.MailFrom]]), Header-From domain ([[RFC5322.From]]), [[Domain_Alignment#Hostname_/_HELO/EHLO\|hostname]], [[DomainKeys_Identified_Mail_(DKIM)#Public_and_private_key\|DKIM signing domain]] and [[Domain_Alignment#Link-_and_imagedomains_/_Sender_domains\|imagelink and link tracking domain]], meaning that ideally all these should be on the same [[Responsible domain\|responsible domain]] name.

	Although this is best practice, this is an unrealistic point of view. In reality, often Email Service Providers require you to use their domain for your bounces, for example because that makes processing bounces and [[feedbackloop]] data easier. In cases where you can use your own domain for RFC5321.MailFrom and RFC5322.From, HELO/EHLO and hostnames are often still ESP-owned - and thus different - domains. This is where double DKIM comes in.		Although this is best practice, this is an unrealistic point of view. In reality, often Email Service Providers require you to use their domain for your bounces, for example because that makes processing bounces and [[feedbackloop]] data easier. In cases where you can use your own domain for RFC5321.MailFrom and RFC5322.From, HELO/EHLO and hostnames are often still ESP-owned - and thus different - domains. This is where double DKIM comes in.
Line 8:		Line 8:
	=Functionality=		=Functionality=

	In the common [[DKIM]] standard ([https://www.rfc-editor.org/rfc/rfc6376.html\|RFC 6376]) it's recommended to sign at least with the Header:-From domain as DKIM signing domain~~, but it's not required~~. Messages can also be signed with - for example - the envelope-from domain or the hostname. In fact, as long as you own a domain, you can use it as DKIM signing domain. RFC 6376 also doesn't mention how often you can sign a single E-Mail with different signing domains. One good example of a use case is when you would like to DKIM sign your message with ed25519 keys, but you want a fallback for hosts that only understand RSA. In that case, it's ~~good~~ possible to sign the message twice with the same signing domain, but ~~obviously~~ with different keys.		In the common [[DKIM]] standard ([https://www.rfc-editor.org/rfc/rfc6376.html\|RFC 6376]) there is no mentioning of which domain to use as signing domain, but taking [[DMARC]] and alignment into consideration, it is recommended to sign at least with the Header:-From domain as DKIM signing domain. Messages can also be signed with - for example - the envelope-from domain or the hostname. In fact, as long as you own a domain, you can use it as DKIM signing domain.

			RFC 6376 also doesn't mention how often you can sign a single E-Mail with different signing domains. It's possible to sign a single message multiple times with the same domain, or with a different domain. One good example of a use case is when you would like to DKIM sign your message with ed25519 keys, but you want a fallback for hosts that only understand RSA. In that case, it's possible to sign the message twice with the same signing domain, but with the two different type of keys.

	If the hostname and the sender domains, or the sender domains and link domains, are completely different domains, the message should be DKIM signed once for each domain used, with different signing domains and in the best case, also different keys and [[DomainKeys_Identified_Mail_(DKIM)#Selector\|selectors]].		If the hostname and the sender domains, or the sender domains and link domains, are completely different domains, the message should be DKIM signed once for each domain used, with different signing domains and in the best case, also different keys and [[DomainKeys_Identified_Mail_(DKIM)#Selector\|selectors]].
Line 32:		Line 34:
	=Double DKIM in InboxSys=		=Double DKIM in InboxSys=

	InboxSys checks for Double DKIM in the [[:Category:E-Mail_analysis]] section.		InboxSys checks for Double DKIM in the [[:Category:E-Mail_analysis\|E-Mail analysis]] section.

	* Messages with a single DKIM record are yellow		* Messages with a single DKIM record are yellow

Sebastian at 13:58, 3 September 2023

2023-09-03T13:58:06Z

← Older revision		Revision as of 15:58, 3 September 2023
Line 2:		Line 2:
	[[Category:E-Mail_analysis]]		[[Category:E-Mail_analysis]]
	[[Category:Authentication]]		[[Category:Authentication]]
	[[~~File:Double~~-~~dkim~~.~~png~~\|~~thumb~~\|~~Typical double~~ DKIM ~~warning~~]]		It commonly is best practice to [[Alignment\|align]] your domains when sending emails, such as your envelope-from domain ([[RFC5321.MailFrom]]), Header-From domain ([[RFC5322.From]]), [[Domain_Alignment#Hostname_/_HELO/EHLO\|hostname]], [[DomainKeys_Identified_Mail_(DKIM)#Public_and_private_key\|DKIM signing domain]] and [[Link-_and_imagedomains_/_Sender_domains:imagelink and link tracking domain]], meaning that ideally all these should be on the same [[Responsible domain\|responsible domain]] name.
	[[:~~Category:InboxSys~~\|~~InboxSys~~]] ~~rolls out Double~~ DKIM ~~testing feature!~~
			Although this is best practice, this is an unrealistic point of view. In reality, often Email Service Providers require you to use their domain for your bounces, for example because that makes processing bounces and [[feedbackloop]] data easier. In cases where you can use your own domain for RFC5321.MailFrom and RFC5322.From, HELO/EHLO and hostnames are often still ESP-owned - and thus different - domains. This is where double DKIM comes in.

	~~If you see additional [[DKIM]] warnings in your InboxSys account, here is why.~~		=Functionality=

	~~As you may or may not know it’s best practice to~~ [[~~Alignment~~\|~~align~~]~~] your domains when sending emails~~, ~~such as your~~ envelope-from domain, ~~Header-From~~ domain, ~~hostname, imagelink and link tracking~~ domain, ~~meaning~~ that ~~ideally all these should be on~~ the same domain ~~name~~.		In the common [[DKIM]] standard ([https://www.rfc-editor.org/rfc/rfc6376.html\|RFC 6376]) it's recommended to sign at least with the Header:-From domain as DKIM signing domain, but it's not required. Messages can also be signed with - for example - the envelope-from domain or the hostname. In fact, as long as you own a domain, you can use it as DKIM signing domain. RFC 6376 also doesn't mention how often you can sign a single E-Mail with different signing domains. One good example of a use case is when you would like to DKIM sign your message with ed25519 keys, but you want a fallback for hosts that only understand RSA. In that case, it's good possible to sign the message twice with the same signing domain, but obviously with different keys.

	~~Although this is best practice~~, ~~this is an unrealistic point of view. In reality~~, ~~often Email Service Providers require you to use their own domain~~ for ~~your bounce~~ domain, ~~for various reasons such as processing bounces~~ and [[~~feedbackloop~~]] ~~data. This is where double DKIM comes in~~.		If the hostname and the sender domains, or the sender domains and link domains, are completely different domains, the message should be DKIM signed once for each domain used, with different signing domains and in the best case, also different keys and [[DomainKeys_Identified_Mail_(DKIM)#Selector\|selectors]].

	~~Double DKIM is about ensuring~~ each domain ~~you use in your message~~ headers ~~are signed~~. ~~This can be read about in https://tools.ietf.org/html/rfc6376~~.		Senders who sign with multiple signing domains and want ed25519 ''plus'' RSA-fallback for each domain quickly produce headers full of DKIM signatures. It's recommended not to create more than 4 DKIM signatures per message.

	<strong>So, is it, and why is it, ~~necessary~~ to sign Double with DKIM, even if all your domains align perfectly?</strong>		<strong>So, is it, and why is it, recommended to sign Double with DKIM, even if all your domains align perfectly?</strong>

	Apart from declaring which domains may be used in this message, the ~~secondary~~ DKIM signature ~~([[ESP]] signature)~~ is also meant as a fallback. If there is a fault on the ~~sender's~~ [[DNS]], the message still has a valid DKIM signature.		Apart from declaring which domains may be used in this message, the second DKIM signature is also meant as a fallback. If - for example - there is a fault on the [[DNS]] for one signing domain, the message still has a valid DKIM signature on the other, even if [[Domain_Alignment#DKIM_alignment\|DKIM doesn't align anymore]] in this case.

	Understanding the importance of Double DKIM is the first step, beyond that there is a preferred way of signing your DKIM signatures.		Understanding the importance of Double DKIM is the first step, beyond that there is a preferred way of signing your DKIM signatures.

	# For multiple domains, use separate ~~’selectors’~~		# For multiple domains, use separate selectors.
	# Use different ~~Keys~~ when using multiple domains		# Use different keys when using multiple domains.
	# The ~~Minimum~~ recommended length for DKIM keys is 2048 bit.		# The minimum recommended length for DKIM keys is 2048 bit.
			# [[DKIM key rotation‏‎\|Rotate keys regularly]].

	==Summary==		==Summary==

	The key ~~takeaways~~ from this is to remember when using multiple domains, take into consideration Double DKIM. By doing this you shall be better aligned and your configuration will be looked upon ~~favourably~~ by some filters & ISPs, which could mean improved Deliverability rates.		[[File:Double-dkim.png\|thumb\|Typical double DKIM warning]]
			The key takeaway from this is to remember, especially when using multiple domains in your E-Mails, to take into consideration Double DKIM. By doing this you shall be better aligned and your configuration will be looked upon favorably by some filters & ISPs, which could mean improved Deliverability rates.

			=Double DKIM in InboxSys=

			InboxSys checks for Double DKIM in the [[:Category:E-Mail_analysis]] section.

			* Messages with a single DKIM record are yellow
			* Messages with a double DKIM record are green if
			** both signatures pass the check,
			** keys are different and
			** selectors are different.

Sebastian at 22:44, 2 September 2023

2023-09-02T22:44:01Z

← Older revision		Revision as of 00:44, 3 September 2023
Line 15:		Line 15:
	<strong>So, is it, and why is it, necessary to sign Double with DKIM, even if all your domains align perfectly?</strong>		<strong>So, is it, and why is it, necessary to sign Double with DKIM, even if all your domains align perfectly?</strong>

	Apart from declaring which domains may be used in this message, the secondary DKIM signature ([[ESP]] signature) is also meant as a fallback. If there is a fault on the sender's [[~~Domain Name System (DNS)\|~~DNS]], the message still has a valid DKIM signature.		Apart from declaring which domains may be used in this message, the secondary DKIM signature ([[ESP]] signature) is also meant as a fallback. If there is a fault on the sender's [[DNS]], the message still has a valid DKIM signature.

	Understanding the importance of Double DKIM is the first step, beyond that there is a preferred way of signing your DKIM signatures.		Understanding the importance of Double DKIM is the first step, beyond that there is a preferred way of signing your DKIM signatures.

Sebastian at 22:18, 2 September 2023

2023-09-02T22:18:51Z

← Older revision		Revision as of 00:18, 3 September 2023
Line 15:		Line 15:
	<strong>So, is it, and why is it, necessary to sign Double with DKIM, even if all your domains align perfectly?</strong>		<strong>So, is it, and why is it, necessary to sign Double with DKIM, even if all your domains align perfectly?</strong>

	Apart from declaring which domains may be used in this message, the secondary DKIM signature ([[ESP]] signature) is also meant as a fallback. If there is a fault on the sender's [[DNS]], the message still has a valid DKIM signature.		Apart from declaring which domains may be used in this message, the secondary DKIM signature ([[ESP]] signature) is also meant as a fallback. If there is a fault on the sender's [[Domain Name System (DNS)\|DNS]], the message still has a valid DKIM signature.

	Understanding the importance of Double DKIM is the first step, beyond that there is a preferred way of signing your DKIM signatures.		Understanding the importance of Double DKIM is the first step, beyond that there is a preferred way of signing your DKIM signatures.

Sebastian at 17:34, 31 August 2023

2023-08-31T17:34:44Z

← Older revision		Revision as of 19:34, 31 August 2023
Line 7:		Line 7:
	If you see additional [[DKIM]] warnings in your InboxSys account, here is why.		If you see additional [[DKIM]] warnings in your InboxSys account, here is why.

	As you may or may not know it’s best practice to align your domains when sending emails, such as your ~~bounce~~ domain, ~~sender from~~ domain, hostname, ~~image hosting~~ and link tracking domain, meaning that ideally all these should be on the same domain name.		As you may or may not know it’s best practice to [[Alignment\|align]] your domains when sending emails, such as your envelope-from domain, Header-From domain, hostname, imagelink and link tracking domain, meaning that ideally all these should be on the same domain name.

	Although this is best practice, this is an unrealistic point of view. In reality, often Email Service Providers require you to use their own domain for your bounce domain, for various reasons such as processing bounces and [[feedbackloop]] data. This is where double DKIM comes in.		Although this is best practice, this is an unrealistic point of view. In reality, often Email Service Providers require you to use their own domain for your bounce domain, for various reasons such as processing bounces and [[feedbackloop]] data. This is where double DKIM comes in.

Sebastian at 22:49, 30 August 2023

2023-08-30T22:49:30Z

← Older revision		Revision as of 00:49, 31 August 2023
Line 5:		Line 5:
	[[:Category:InboxSys\|InboxSys]] rolls out Double DKIM testing feature!		[[:Category:InboxSys\|InboxSys]] rolls out Double DKIM testing feature!

	If you see additional [[~~DomainKeys Identified Mail (DKIM)\|~~DKIM]] warnings in your InboxSys account, here is why.		If you see additional [[DKIM]] warnings in your InboxSys account, here is why.

	As you may or may not know it’s best practice to align your domains when sending emails, such as your bounce domain, sender from domain, hostname, image hosting and link tracking domain, meaning that ideally all these should be on the same domain name.		As you may or may not know it’s best practice to align your domains when sending emails, such as your bounce domain, sender from domain, hostname, image hosting and link tracking domain, meaning that ideally all these should be on the same domain name.