Re: [mailop] Intentionally vague SPF records.

[Mark Alley via mailop]

+1 to Laura's statement about Macros - and just wanted to add there is 
also an open source solution that allows for self-hosted SPF macros on 
github as well.


https://github.com/smck83/expurgate


On 1/11/2023 9:00 AM, Laura Atkins via mailop wrote:



On 11 Jan 2023, at 13:08, 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.


Most bulk services use either a custom subdomain in the customer’s 
domain space for the 5321.from or their own string in the 5321.from. 
This is primarily to deal with bounces - as anything that fails to 
deliver should go back to the sending service not to the original 
sender. A lot of places (SES, Mailchimp, Constant Contact) use their 
own 5321.from addresses by default and there’s no need to add the 
include: record at all. If your user base is using custom 5321.from 
you’re going to need to set up DNS records for those (CNAMEs are common).


Do you have a lot of users with 1 to 1 email through external relays?

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 find, generally, this happens but in most cases it doesn’t have to. 
Despite what a lot of people think, they don’t need to add an include 
for every service they’re using in the spf record for their 
organizational domain.


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.


Sparkpost uses macros, would that be possible?

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.


Anecdotally, that would be a bad idea. What I’ve heard is this is 
actually something done for botnet sending and is treated as a bad 
reputation indicator. I don’t ever recommend this.


laura

--
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com

Email Delivery Blog: http://wordtothewise.com/blog







___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


OpenPGP_0xE37A23C4D04F0409.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Intentionally vague SPF records.

[Laura Atkins via mailop]

> On 11 Jan 2023, at 13:08, 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. 

Most bulk services use either a custom subdomain in the customer’s domain space 
for the 5321.from or their own string in the 5321.from. This is primarily to 
deal with bounces - as anything that fails to deliver should go back to the 
sending service not to the original sender. A lot of places (SES, Mailchimp, 
Constant Contact) use their own 5321.from addresses by default and there’s no 
need to add the include: record at all. If your user base is using custom 
5321.from you’re going to need to set up DNS records for those (CNAMEs are 
common). 

Do you have a lot of users with 1 to 1 email through external relays? 

> 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 find, generally, this happens but in most cases it doesn’t have to. Despite 
what a lot of people think, they don’t need to add an include for every service 
they’re using in the spf record for their organizational domain. 

> 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. 

Sparkpost uses macros, would that be possible?

> 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.

Anecdotally, that would be a bad idea. What I’ve heard is this is actually 
something done for botnet sending and is treated as a bad reputation indicator. 
I don’t ever recommend this. 

laura

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog  






___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Intentionally vague SPF records.

[Jaroslaw Rafa via mailop]

Dnia 11.01.2023 o godz. 08:55:19 Matt Vernhout via mailop pisze:
> 
> You may need to update systems, or change some domains to use subdomains,
> or a different MailFrom: etc... but If massive global corporations like
> Disney, HP, and Oracle, can figure it out you can too.

Those massive global corporations have much simpler and easier to manage
setup (with regard to SPF). They have a large internal network that connects
to the Internet only in several well-defined points (that are all under
central control of the IT department, there is no freedom for branch offices
to choose their ISP etc.), and for mail, there is usually one (or two, or
three, to provide redundancy - but no more) outgoing server that sends mail
to the outside world. So to set up a SPF record is quite easy.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Intentionally vague SPF records.

[Mark Alley via mailop]

Of those vendors you listed, Mailchimp doesn't send SPF aligned mail in 
the RFC5321.mailfrom (return-path), and Sendgrid custom domain 
authentication uses subdomain CNAMEs by default for the same, so you can 
count those off your list of ones you need to worry about on your 
organizational domain.


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: 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 
 
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 
)



- 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 
 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 .

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
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

___
mailop mailing list

Re: [mailop] Intentionally vague SPF records.

[Duncan Brannen via mailop]

I’ll +1 to Jethro’s comments.  NCSC will give you free DMARC reporting.  We’ve 
done as Strathclyde and pushed services out into subdomains.  The top level 
domain is just us and specific suppliers used for official comms. It wasn’t too 
painful in the end but we spent a lot of time in report only mode working out 
who we’d be cutting off.

Cheers,
Duncan

--
The University of St Andrews is a charity registered in Scotland : No SC013532
From: mailop  On Behalf Of Jethro Binks via mailop
Sent: 11 January 2023 14:25
To: mailop@mailop.org
Subject: Re: [mailop] Intentionally vague SPF records.

> +1 to Mark's comments... Without discovery you'll never know if you're over 
> the limits or not.

That's not the point though.  It might be fine today.  But at any time any one 
of those providers could change a record you are including from them, and take 
you over the limit, effectively a DoS on your email which is totally out of 
your hands.

Don't allow yourself to be placed in that situation.  Get some DMARC reporting 
set up, and start working through the data to get a better idea of the scale of 
the issue, and work on the senders to get them to change.  In our case, we tend 
to shuffle them into subdomains for the specific purpose.  But yeah it can be a 
lot of work over a long time, but that time won't get any shorter until you 
start it .

> (it's a UK University, where there's no obligation for colleges to use IT 
> services).

Your top-level Uni email domain is a central University IT resource not a 
college one, so you get to define the conditions by which it is used, over time 
(yes, easier said than done!).

Jethro.


.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .

Jethro R Binks, Network Manager,

Information Services Directorate, University Of Strathclyde, Glasgow, UK



The University of Strathclyde is a charitable body, registered in Scotland, 
number SC015263.


From: mailop mailto:mailop-boun...@mailop.org>> on 
behalf of Matt Vernhout via mailop mailto:mailop@mailop.org>>
Sent: 11 January 2023 13:55
To: mailop@mailop.org<mailto:mailop@mailop.org> 
mailto:mailop@mailop.org>>
Subject: Re: [mailop] Intentionally vague SPF records.

+1 to Mark's comments... Without discovery you'll never know if you're over the 
limits or not.

Setup a p=none policy, and see where the mail is coming from.

You may need to update systems, or change some domains to use subdomains, or a 
different MailFrom: etc... but If massive global corporations like Disney, HP, 
and Oracle, can figure it out you can too.

A lot of DMARC reporting services will likely offer some kind of SPF flattening 
as part of their services without extra cost.

~ MV


On Wed, Jan 11, 2023 at 8:29 AM Mark Alley via mailop 
mailto:mailop@mailop.org>> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdmarcvendors.com%2F=05%7C01%7Cdbb%40st-andrews.ac.uk%7Cf0936f95f76e47a48a2e08daf3e014b7%7Cf85626cb0da849d3aa5864ef678ef01a%7C0%7C0%7C638090440997031636%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=%2BJxhWYGwJ222nE0LFkNbzMlN7VK7NgxVtBtQOjHwV44%3D=0>.

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

mailop@mailop.org<mailto:mailop@mailo

Re: [mailop] Intentionally vague SPF records.

[Jethro Binks via mailop]

> +1 to Mark's comments... Without discovery you'll never know if you're over 
> the limits or not.

That's not the point though.  It might be fine today.  But at any time any one 
of those providers could change a record you are including from them, and take 
you over the limit, effectively a DoS on your email which is totally out of 
your hands.

Don't allow yourself to be placed in that situation.  Get some DMARC reporting 
set up, and start working through the data to get a better idea of the scale of 
the issue, and work on the senders to get them to change.  In our case, we tend 
to shuffle them into subdomains for the specific purpose.  But yeah it can be a 
lot of work over a long time, but that time won't get any shorter until you 
start it .

> (it's a UK University, where there's no obligation for colleges to use IT 
> services).

Your top-level Uni email domain is a central University IT resource not a 
college one, so you get to define the conditions by which it is used, over time 
(yes, easier said than done!).

Jethro.


.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .

Jethro R Binks, Network Manager,

Information Services Directorate, University Of Strathclyde, Glasgow, UK


The University of Strathclyde is a charitable body, registered in Scotland, 
number SC015263.


From: mailop  on behalf of Matt Vernhout via mailop 

Sent: 11 January 2023 13:55
To: mailop@mailop.org 
Subject: Re: [mailop] Intentionally vague SPF records.

+1 to Mark's comments... Without discovery you'll never know if you're over the 
limits or not.

Setup a p=none policy, and see where the mail is coming from.

You may need to update systems, or change some domains to use subdomains, or a 
different MailFrom: etc... but If massive global corporations like Disney, HP, 
and Oracle, can figure it out you can too.

A lot of DMARC reporting services will likely offer some kind of SPF flattening 
as part of their services without extra cost.

~ MV


On Wed, Jan 11, 2023 at 8:29 AM Mark Alley via mailop 
mailto:mailop@mailop.org>> 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
mailop@mailop.org<mailto:mailop@mailop.org>
https://list.mailop.org/listinfo/mailop


___
mailop mailing list
mailop@mailop.org<mailto:mailop@mailop.org>
https://list.mailop.org/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Intentionally vague SPF records.

[Matt Vernhout via mailop]

+1 to Mark's comments... Without discovery you'll never know if you're over
the limits or not.

Setup a p=none policy, and see where the mail is coming from.

You may need to update systems, or change some domains to use subdomains,
or a different MailFrom: etc... but If massive global corporations like
Disney, HP, and Oracle, can figure it out you can too.

A lot of DMARC reporting services will likely offer some kind of SPF
flattening as part of their services without extra cost.

~ MV


On Wed, Jan 11, 2023 at 8:29 AM Mark Alley via mailop 
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
> .
>
> 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 listmailop@mailop.orghttps://list.mailop.org/listinfo/mailop
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Intentionally vague SPF records.

[Simon Burke via mailop]

>
> 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 
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
> .
>
> 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 listmailop@mailop.orghttps://list.mailop.org/listinfo/mailop
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Intentionally vague SPF records.

[Mark Alley via mailop]

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 .


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
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


OpenPGP_0xE37A23C4D04F0409.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Intentionally vague SPF records.

[Simon Burke via mailop]

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
mailop@mailop.org
https://list.mailop.org/listinfo/mailop