Hi all, I have a question: the SPF authentication and alignment is related only to Envelope Address or also to From address visible to end user?
For example I have an email message with this parameters:
From: <info@mycompany. xyz>
Envelope Address (mailfrom): <xxx@bounce.somemailprovider. xyz>
Return Path: <xxx@bounce.somemailprovider. xyz>
DKIM signature: configured for mycompany. xyz
Assuming that I have configured this for my domain (mycompany. xyz):
DMARC policy: quarantine 100% and relaxed mode
SPF: I have only an include for my MX server (Google Workspace for example) and in strict mode ("-all")
Itâs necessary to add also the include for âsomemailprovider. xyzâ IP addresses or not? I think that it is necessary the SPF include only in DNS zone of the vendor. Itâs correct?
Thank you in advance.
Regards.
Note: sorry for the blank space before TLD extension, but I have a limit to posting link on forum
SPF only evaluates the domain of the envelope sender, sometimes referred to as the return-path.
For a passing SPF test result to be considered for DMARC compliance, it must meet the alignment criteria.
This means that the return-path of evil-spammer@example.net, could (and often does) pass the raw SPF test. Since there is no alignment with your RFC5322 sender of nice-folks@example.com, DMARC will fail.
This holds true even in more benign scenarios, such as one of your ESPs who uses their own domain in the return-path. You cannot pass DMARC using SPF in that scenario, not even if you include their SPF in yours. There is no point in including their SPF in yours in that situation. Your domain is not in the envelope sender, so your SPF records will not be consulted.
Thank you for your feedback, I understand it.
So, you can confirm that the lookup for the vendor server in my SPF record Itâs not necessary if the envelope sender Itâs the vendor bounce domain.
For example in a message with sender mark@example. com, envelope domain (return path) mailservice.example. com, and finally DKIM signature example. com.
For passing SPF, where are necessary to publish the SPF record? In the DNS zone of example. com or only in DNS zone of mailservice.example. com?
You said âSince there is no alignment with your RFC5322 sender of nice-folks@example.com, DMARC will fail.â but if we have also DKIM aligned with sender domain (those visible to user), the DMARC pass (thanks to DKIM alignment) in this way? Correct?
You arenât likely running a dedicated DNS zone for mailservice.example. com, so all of your SPF would go in the example.com zone, though each subdomain sending email will need its own record. You certainly can publish a different SPF for mailservice.example. com and example.com, but you do not have to as long as you have room for all of the sources in both records. If you want mailservice.example.com domain to be covered by the example.com SPF you can either use âinclude:example.comâ or duplicate the example.com policy verbatim. It is best to keep your SPF sources as strict as possible, though.
As long as the DKIM signature is valid and has alignment (relaxed or strict, depending on how you configured your DKIM records and DMARC policy) DMARC should pass.
Update: edited to correct misinformation on non-existent inheritance characteristic of SPF records.
Ok, but for reducing lookup in my main domain example .com, I can use the envelope subdomain mailservice.example .com and have only SPF for this IP in this subdomain and not also in main domain?
So, If I donât publish the SPF for subdomain this is inherited from main domain?
I am wrong. SPF does not have inheritance. I have never not set an explicit SPF record on any of my email enabled sub-domains, and I suspect that I just erroneously granted non-existent properties to SPF.
To clarify, if you want a subdomain to have the same SPF as a parent, either use an include statement or just duplicate the parent domain SPF verbatim. I am going to update my previous post to correct that misinformation.
In your case, you will be fine creating an SPF for the subdomain that only has data related to your ESP, assuming that you donât intend to send email from any other source with that subdomain. If you do, simply update its SPF record.
