For Azure, I'm assuming this is supposed to be server(s) you have hosted in the Azure cloud that sends mail directly out? This could just be an ip4 mechanism reference in your SPF record, which avoids a DNS lookup.
Right now, with just this lineup (excluding Verint as I couldn't find any documentation on them) we're at 5 lookups with this example SPF record below. Depending on which of these services are customer-mailing, or if they're only sending to your own users, you can make the decision to convert some of them to using a sub-domain to alleviate your root record lookups.
v=spf1 ip4:<AzureIP(s)> include:spf.protection.outlook.com include:amazonses.com include:spf.mailjet.com include:eu.rp.oracleemaildelivery.com ?all
All of this being said, keep in mind, it's not necessary to have SPF authenticate for everything you send. DMARC will still pass as long as the sending infrastructure signs with an aligned and valid DKIM signature on the emails. Authenticate what you can with SPF - the critical business services, and rely on DKIM alone for the rest if necessary. Plenty of big senders today use this philosophy with nary an issue, just look at Mailchimp.
This is also partly why it's considered a deliverability best practice to use ~all (softfail) on your sending domains (M3AAWG best practices <https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf> section 4). This practice is widely used for sending domains that have an enforced DMARC policy to avoid issues with SPF failure where some MTAs are configured to reject -all before processing DMARC policy and DKIM. (DMARC RFC7489 10.1 <https://datatracker.ietf.org/doc/html/rfc7489#section-10.1>)
- Mark Alley On 1/11/2023 7:52 AM, Simon Burke via mailop wrote:
What makes you think you'd go over the limit if you haven't done the discovery?This would be because the ones that we are aware of, are the likes of AmazonSES, Sendgrid, Mailchimp, Azure, OracleCloud, Mailjet, KANA/Verint, just to name a few on top of our O365 instance and locally transported mail.We know the major ones, but it's all the little ones that one department somewhere setup without contacting central IT. This happens a lot due to internal politics (it's a UK University, where there's no obligation for colleges to use IT services).Theres a lot of internal politics involved, but the thought popped into our heads, to use a intentionally vague record as a fudge until we are able to determine what it should look like. Or push external things onto sub-domains so we can have a simple SPF for the primary domain.Thanks.On Wed, 11 Jan 2023 at 13:32, Mark Alley via mailop <[email protected]> wrote:What makes you think you'd go over the limit if you haven't done the discovery? You might be surprised that you may not exceed the lookup count, as with optimization/analysis and proper SPF design (even without flattening), the lookup count can be quite easily managed. This sounds like a prime candidate for your mail source discovery with DMARC reporting <https://dmarcvendors.com>. Using ?all (neutral) might be best for deliverability's sake while you build out this SPF record during discovery. This would have the same effect as your current scenario of having no SPF record, while still allowing for positive matches of your legitimate known mail-flow until you get to a point you move to ~all. - Mark Alley On 1/11/2023 7:08 AM, Simon Burke via mailop wrote:All, This is an odd scenario, but sadly one I find myself in. Work is a large organisation, and currently does not have an SPF record. The reason is that there are a large (and unknown) number of internal and external parties that send mail on our domain, as well as sub-domains. So, even if we do determine who sends email on the domain, we would then have an issue with max lookups and record length. I know we can use an SPF flattening service. However that either has a cost. Or, although we can develop something in house, there's a 'bought not built' ethos being pushed by management. As an out the box idea, what would the potential impact be of having an SPF record stating just: "V=spf1 a mx +all" How bad of an idea would this be? If we also had a DMARC record set to either quarantine or reject. Regards, Simon _______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop_______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop _______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
OpenPGP_0xE37A23C4D04F0409.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
