You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a MailOps/DeliverabilityOps professional, I want to ensure that all mail leaving my environment is DMARC compliant, in order to adhere to the new guidelines provided by Google/Yahoo and no doubt also in place at various other MBPs.
To this end, I need to ensure that all messages sent via KumoMTA have a configured level of compliance. This could include requiring SPF, DKIM, and DMARC records to be present, requiring SPF and/or DKIM to pass, or requiring DMARC strict or relaxed alignment.
To do this we will need to complete work on SPF checking (#83), as well as determine the external IP addresses of all egress sources in the MTA (#29). We likely also need to complete the DMARC support (#84) to be able to implement this.
We may need to have this selectively turned off for certain egress sources. For example, if the message is relayed through an egress source that sends the message on to a provider like MailGun then we won't know enough about the future path of the message to check things like SPF. We may also just downgrade for that use case, instead checking that the appropriate DNS records are in place for the friendly from domain but not validating against them.
The text was updated successfully, but these errors were encountered:
As a MailOps/DeliverabilityOps professional, I want to ensure that all mail leaving my environment is DMARC compliant, in order to adhere to the new guidelines provided by Google/Yahoo and no doubt also in place at various other MBPs.
To this end, I need to ensure that all messages sent via KumoMTA have a configured level of compliance. This could include requiring SPF, DKIM, and DMARC records to be present, requiring SPF and/or DKIM to pass, or requiring DMARC strict or relaxed alignment.
To do this we will need to complete work on SPF checking (#83), as well as determine the external IP addresses of all egress sources in the MTA (#29). We likely also need to complete the DMARC support (#84) to be able to implement this.
We may need to have this selectively turned off for certain egress sources. For example, if the message is relayed through an egress source that sends the message on to a provider like MailGun then we won't know enough about the future path of the message to check things like SPF. We may also just downgrade for that use case, instead checking that the appropriate DNS records are in place for the friendly from domain but not validating against them.
The text was updated successfully, but these errors were encountered: