DMARC: Having both and identical RFC 5322 From address and RFC 5321 From address

Hi guys,

As explained on this website:

The purpose of DMARC is authenticate the domain of the email shown to the recipient. This is the RFC 5322 From address, or the message body from address. There is another ‘from address’ in every email. It is the RFC 5321 From address and is more commonly known as the envelope sender or return-path. It is not normally visible to the recipient of the email.

There are two methods that DMARC can use to authenticate the (RFC 5322) sender domain: SPF and DKIM.

DKIM creates a cryptographic signature based on parts of the email which can be checked against the published DKIM record. If the math checks out, it passes. There is more to it than that, but that should sufficient explanation for your current situation.

SPF checks the relay IP to see if it is listed in the RFC 5321 sending domain’s SPF records. Assuming that it is included, in order for a successful SPF test to be useful in verifying the RFC 5322 domain, alignment must be present. The short explanation of alignment is that the RFC 5321 and RFC 5322 domains need to match.

Here is an example of a failed Amazon SES SPF on the policy evaluating level, which passed on the auth_results level, which I couldn’t understand the reason for its failure:

<record>
	<row>
		<source_ip>54.240.8.13</source_ip>
		<count>1</count>
		<policy_evaluated>
			<disposition>none</disposition>
			<dkim>pass</dkim>
			<spf>fail</spf>
		</policy_evaluated>
	</row>
	<identifiers>
		<envelope_from>amazonses.com</envelope_from>
		<header_from>example.com</header_from>
	</identifiers>
	<auth_results>
		<dkim>
			<domain>amazonses.com</domain>
			<result>pass</result>
		</dkim>
		<dkim>
			<domain>example.com</domain>
			<result>pass</result>
		</dkim>
		<spf>
			<domain>amazonses.com</domain>
			<result>pass</result>
		</spf>
	</auth_results>
</record>

My SPF DNS shows:

mail.example.com.		TXT	v=spf1 ip4:54.240.8.0/21 ip4:<my_ip1> ip4:<my_ip2> ip4:<my_ip3> ip4:3.96.210.40 ip4:<my_ip4> +a +mx +a:example.com include:amazonses.com ~all

Notes:

1. The relevant IP ‘54.240.8.13‘ should both resolved to the included “include:amazonses.com”, and is also manually listed, as part of: ‘ip4:54.240.8.0/21‘
2. I do suspect a previously misused by me syntax, on the DKIM policy could have been related to the issue. I have just fixed it, after the above report.
3. Also, it’ possible this is an Outlook local machine generated email, that is sent using AWS WorkMail, although I guess oulook is well configured (is that so?), and my manual generated emails, using Excel and VB, do make sure the FORM ADDRESS and REPLY to are identical.

On another record, that did PASS SPF check on all levels, I can see that the FROM DOMAIN checked was mail.example.com sub-domain which is associated to “Custom MAIL FROM domain” on AWS SES configuration. and NOT the main domain example.com.

<record>
	<row>
		<source_ip>54.240.11.78</source_ip>
		<count>1</count>
		<policy_evaluated>
			<disposition>none</disposition>
			<dkim>pass</dkim>
			<spf>pass</spf>
		</policy_evaluated>
	</row>
	<identifiers>
		<envelope_from>mail.example.com</envelope_from>
		<header_from>example.com</header_from>
	</identifiers>
	<auth_results>
		<dkim>
			<domain>amazonses.com</domain>
			<result>pass</result>
		</dkim>
		<dkim>
			<domain>example.com</domain>
			<result>pass</result>
		</dkim>
		<spf>
			<domain>mail.example.com</domain>
			<result>pass</result>
		</spf>
	</auth_results>
</record>

Thus, may I ask:

1. in regards to passing DMARC/SPF, do you add both, and identical RFC 5322 From address and RFC 5321 From address, to the generated by your plugin email’s header?
2. Do you pass the “MAIL FROM” information with emails your plugins generates, and if so, how can I configure that var’s value to be “mail.example.com”?

Regards, Ziegel

• This topic was modified 1 year, 5 months ago by ziegel.
• This topic was modified 1 year, 5 months ago by ziegel.
• This topic was modified 1 year, 5 months ago by ziegel.
• This topic was modified 1 year, 5 months ago by ziegel.
• This topic was modified 1 year, 5 months ago by ziegel.