2

We have a primary domain name example.com that has both adkim=s and aspf=s defined in its DMARC policy. Now, we have multiple subdomain names for this primary domain, such as postman.example.com. The subdomain has SPF, DKIM and DMARC TXT records in place.

However, when sending from @postman.example.com to any or most remote mail servers such as @gmail.com, SPF and DKIM checks pass, however, they fail their alignments. I have read up on some articles that I need to set my adkim and aspf from strict to relaxed to address this. And this I have successfully done, but @gmail.com still bounces with a DMARC error:

message": "5.7.26 Unauthenticated email from example.com is not accepted due to\n5.7.26 domain's DMARC policy. Please contact the administrator of\n5.7.26 example.com domain if this was a legitimate mail. Please visit\n5.7.26 https://support.google.com/mail/answer/2451690 to learn about the\n5.7.26 DMARC initiative. t5-20020a5d5345000000b0021f10931e69si5563740wrv.234 - gsmtp",

This seems to be affecting all *.example.com subdomains. And I have no idea what else is supposed to happen for this to be fixed.

2 Answers2

3

The security-centric goal of DMARC is to ensure that the domain in the From address reflects the same domain that is sending the email.

At a very high level, if you have either of the below two conditions met, DMARC will almost definitely pass:

• SPF alignment  (‘Header From’ domain matches sender (SPF) domain)

• DKIM alignment (‘Header From’ domain matches DKIM signing domain)

If the email is DKIM signed and there is DKIM alignment i.e. ‘Header From’ is the same as the DKIM signing domain, DMARC will pass even if there is no SPF or SPF alignment.

Note: I’ve deliberately avoided ‘relaxed’ and ‘strict’ alignments discussion here.

You'll need to analyze the email headers and any DMARC reports you've received to correctly identify exactly why DMARC is failing.

Edit: See the three examples here discussing SPF alignment: https://mxtoolbox.com/dmarc/spf/spf-alignment

1

After numerous research, I finally found the solution to my own problem. Looking over the sending logs for the domain, postman.example.com I found that the Sending Domain and From Address Domain did not match:

  • Sending Domain: postman.example.com
  • From Address Domain: noreply@example.com

The messages were being rejected because of the DMARC policy that is set up for the root domain, example.com. Below is an example of a message from my sending logs:

Date: Aug 16, 2022 @ 20:42:25.578 UTC
Event: failed
---> Sending Domain: postman.example.com <---
---> From Address: Example <noreply@example.com> <---
Recipient: example@gmail.com
Subject: Test Email / #552840 - 2022-08-16T22:42:20+02:00
Message-id: 04b2f3e2e10ff16c2283a2be1fc30650@example.com

delivery-status.message: Unauthenticated email from example.com is not accepted due to domain's DMARC policy. Please contact the administrator of example.com domain if this was a legitimate mail. Please visit https://support.google.com/mail/answer/2451690 to learn about the DMARC initiative. t3-20020a7bc3c3000000b003a2d84a7c17si7921717wmj.14 - gsmtp

The security-centric goal of DMARC is to ensure that the domain in the From address reflects the same domain that is sending the email. As more email service providers adopt DMARC, messages that have a domain in the From address that differs from the sending domain will be quarantined, marked as spam, or rejected completely. Current email best practices are clear that the domain of the From address and sending domain should match.