Update goentri.com.sendmarc.json #412
Conversation
goentri.com.sendmarc.json
Outdated
| @@ -23,7 +23,7 @@ | |||
| "type": "SPFM", | |||
| "host": "@", | |||
| "groupId": "a2", | |||
| "spfRules": "include:%thirdPartyDomain%" | |||
| "spfRules": "redirect=%thirdPartyDomain%" | |||
There was a problem hiding this comment.
redirect rules are not currently supported by SPFM, as those cannot be reliably merged with the other rules.
If this is what is needed (even though I would not encourage), the only option for now would be a regular TXT record with txtConflictMatchingPrefix configuration to avoid duplicate SPF.
The provider would be responsible for the merge of the record with existing service in this case. Any further service may also break the configuration - this is something to be aware of.
There was a problem hiding this comment.
Hi @pawel-kow, thank you for warning me about that.
What would be the right configuration for the following SPF?
{
"value": "v=spf1 redirect=_sokiruvgn.sdmarc.net",
"host": "@",
"ttl": 3600,
"type": "TXT"
}
There was a problem hiding this comment.
Sth like:
{
"data": "v=spf1 redirect=%thirdPartyDomain%",
"host": "@",
"ttl": 3600,
"type": "TXT",
"txtConflictMatchingMode": "Prefix",
"txtConflictMatchingPrefix": "v=spf1",
"essential": "OnApply"
}
There was a problem hiding this comment.
thank you
There was a problem hiding this comment.
... and bump the version number
There was a problem hiding this comment.
@pawel-kow considering Google Domains don't support "txtConflictMatchingMode": "Prefix","txtConflictMatchingPrefix": "v=spf1", "essential": "OnApply
Is there a different way to configure that record?
There was a problem hiding this comment.
txtConflictMatchingMode, txtConflictMatchingPrefix and essential have a semantic meaning which will make this alternative method secure to use.
Without txtConflictMatching* setting it will be possible to set up 2nd SPF, which will basically void it.
"essential" setting is only important for providers tracking the template usage and removing whole templates. So Google likely can tell if they are affected. If this setting is not there it would mean the template dropped if SPF is modified or deleted. Normally not a wanted behavior.
Functionally Google could onboard the template without these parameters and it would work for most of the cases.
Alternative is to convince the provider to use include instead of redirect, and keep using SPFM.
There was a problem hiding this comment.
txtConflictMatchingMode, txtConflictMatchingPrefix and essential have a semantic meaning which will make this alternative method secure to use.
Without txtConflictMatching* setting it will be possible to set up 2nd SPF, which will basically void it.
"essential" setting is only important for providers tracking the template usage and removing whole templates. So Google likely can tell if they are affected. If this setting is not there it would mean the template dropped if SPF is modified or deleted. Normally not a wanted behavior.
Functionally Google could onboard the template without these parameters and it would work for most of the cases.
Alternative is to convince the provider to use include instead of redirect, and keep using SPFM.
No description provided.