I will personally always use hard fail. If I need to relay mail then I configure the receiving site to make an exception for the relay. If that isn't possible then I do not relay. In a corporation this requires some level of discipline and knowing what is sending emails and why. Security teams should have a weekly test to see if they can spoof senders in their corporate email both from inside their company and from untrusted external IP's. I have found it too easy to spoof people in legal, security and leadership in most companies.
Adding to this, hard fail should be used with parked domains without exception. If a domain is not used for sending emails then it should have a null MX and hard fail SPF stating not to trust any IP's or domains.
@ 1d in mx 0 .
@ 1din txt "v=spf1 -all"
@ 1d in caa 0 issue ";"
@ 1d in caa 0 issuewild ";"
dmarc 1d in txt "v=DMARC1;p=reject;sp=reject;pct=100;aspf=s;"
_domainkey 1d in txt "v=DKIM1; p="
_bimi 1d in txt "v=BIMI1; l=; a=;"
* 1d in mx 0 .
* 1d in txt "v=spf1 -all"
*._domainkey 1d in txt "v=DKIM1; p="
* 1d in caa 0 issue ";"
* 1d in caa 0 issuewild ";"
> Adding to this, hard fail should be used with parked domains without exception. If a domain is not used for sending emails then it should have a null MX and hard fail SPF stating not to trust any IP's or domains.
This is correct, but this is also mentioned in the article multiple times.
Could be useful, but a successful attack on BIMI would require:
- Getting access to the DNS of the domain (in which case the null record will simply be replaced)
- Obtaining a VMC for the domain, which should not be possible due to the extended validation requirement for a VMC (such as: phone validation)
- Spending ~$800 on a VMC
> especially if one is going to use soft-fail.
As explained in the article, if DMARC is deployed then softfail is equal to (hard) fail. With DMARC anything that is not an SPF pass, is not aligned, thus a fail.
The only exception here would be a very old legacy email system that doesn't support DMARC. But those will also not support BIMI anyway.
> Or maybe a malware symbol.
BIMI should always require a VMC. It should be impossible to obtain a VMC with a 'malware symbol'. Unless of course you are willing to pay a lot to get it registered as your company logo at your trademark office.
I have the same aside from CA related (I don't see the point, if I lose control of a domain TLS is not a priority, and I can't stop rogue CA issuing a certificate as CAA is basically unsupported) - also no bimi as it's a solution looking for a problem and not even in the right place.
As a result, emails from your domain will never reach anyone who has a "forwarding" email address: for example, someone who uses Cloudflare to manage their incoming email for their domains, and forwards it to their real email account.
Hard fail is juggling with running chainsaws. If you do not absolutely have your shit together, you might lose something you really wanted to keep.
Most orgs do not have their shit together. So if you are offering a service in the email space, telling your customers to set hard fail is just going to drive up your complaints and support costs.
It makes total sense that this company is advising soft fail. Most people can’t juggle chainsaws safely.
Keeping perfect track of all the various departments, services, vendors, IP addresses, etc sending on behalf of your domain is very hard in many organizations.
Even if you can keep all that shit running fine for your organization, you can't make any guarantees with regards to these issues for all the other organizations on the planet.
In fact, I would argue that you MUST assume that at least some non-trivial percentage of those other organizations are actually fucked up with regards to one or more of these areas.
So, therefore, you must be even more conservative than you might otherwise have been. Even if everyone on the planet is a CMM-5 level organization, you're still going to lose the odd space shuttle or two. And maybe also some rockets.
The forwarding problem has been with us since Internet e-mail was first created, and I don't see that problem going away. Ever.
All you can do is decide how you're going to handle that for your own accounts where you set up forwarding, which may very well break e-mail coming from domains that don't fully understand the problem.
You see, there's too much normalization of the idea that everyone should be free to do everything. We see too much push to have developers maintain their own infrastructure, which is partly why there's such a big (and artificial) push to put everything in the cloud, and this often ends up costing much more in the long run.
Just like how regular developers shouldn't be able to push work in to a cloud that'll end up costing tens or hundreds of thousands of dollars without deliberate, thought out reasoning, random people in a company should not be able to set up outgoing email using a company's domain without good reasoning.
If a person or a group were responsible for outgoing email, then nobody would be allowed, nor should they be able, to send without going through that person / group. Problem solved!
But if you think it's OK for any random person at an organization to just set up whatever kind of outgoing email they want, well, you get what you expect.
Look I get it on a technical level. But we've just had years of being yelled for anything but a hard fail. It's become a meme that anyone with a bug bounty program and softfail can expect to have it come in as a "vulnerability" no matter how out of scope you make it.
It's valid to question and change strategies, but I don't think it's a good approach that people who've been chastised for years for softfails are suddenly being chasisted for hard fails.
MS can't expect all their users to use DMARC, and blatantly advising their customers to do so can be dangerous. Not every domain is ready for DMARC and enabling it would cause undeliverable email.
It wouldn't surprise me if MS was being harassed by angry 'experts' for not recommending 'hard' fail, because clearly that would be so much more secure (just look al all the comments in this topic).
So I get it, advising to use a strict failure mode, even at the expense of some undeliverable email is acceptable for MS. But for those who have already adopted DMARC, the SPF 'hard' fail only increases the chance of undeliverable mail, while offering zero security benefits.
"One of them is that a relaying SMTP service (sometimes called a 'forwarder') will break SPF. This is known as the relaying problem."
If relaying is happening, and you haven't added the relay to your SPF, then you're wrong. There is no scenario where this is problem with SPF.
"If the email is bounced on the SMTP level due to an SPF 'hard' fail, the receiver may not perform further evaluation of the email, ignoring DKIM and DMARC."
Well, of course. If SPF is configured to disallow email, then further evaluation isn't necessary. Either fix SPF, or don't blame SPF.
These people are basically advocating for being OK with not configuring SPF properly. No. Just configure SPF properly.
If i receive an mail from e.g. paypal@paypal.com to myself@xyz.com that has no real mailbox but forwards the mail to myself2815@gmail.com.
1. paypal SMTP sends mail to myself@xyz.com
2. xyz.com receive mail SPF is valid
3. xyz.com sends the paypal mail to myself2815@gmail.com
4. gmail.com receives mail SPF is invalid
I can't add XYZ.com to Paypal SPF and hardfail would mean email loss in this case.
SPF is broken by design for many cases and should just used with softfail and dkim/dmarc.
No, forwarding is broken by design, it always was. Configure whatever forwarding you use to do it properly, it's certainly doable (or just don't use gmail but a provider capable of handling this very common, if wrong, scenario)
SMTP "forwarding" (sending an email message with a header "To: <originaladdress>", to a different "RCPT TO: <differentaddress>") is "broken by design"?
Sure, it's probably silly. But, SMTP is what it is, and you're not going to change it by complaining
SPF's design just ... forgot about this, which happens all the time for email.
Every MTA -- literally every forwarding MTA -- does this all day long, and every receiving MTA (which looks at the "Return-Path: <originaladdress>" to lookup the SPF TXT record), gets your fancy "v=spf1 ... nothing w/ forwarding MTA in it ... -all" record, and summarily executes the email w/ SPF: FAIL?
It's just wrong. SPF can only serve as one (strong) hint that an email might be correct, if it passes. If it fails, all your MTA can assume is: "well, the email was very likely forwarded"; what else does it have going for it?
If its "DKIM-Signature: ..." header is valid, that it's almost certainly A-OK! So, why do you want all your domain's nicely DKIM-signed emails dropped, just because some recipient decided to use a "forwarding" email address?
Not sure I follow. I've been running public "forwarding" email servers for 20 years, and ... this is exactly what they do. This is exactly what Cloudflare's "forwarding" email solution does (except it has ARC and everyone who wants to support forwarding includes Cloudflare's MTAs in their ARC configuration).
Little guys like me (of course) don't get included in anyone's ARC configuration, to patch over SPF's profound design failure.
If you're describing a "forwarding" solution that doesn't simply do SMTP "RCPT TO" forwarding, then I don't understand what you're describing...
The article explains that the topic is hotly debated, even controversial maybe. But everything that you are pointing out here has been addressed in the article.
> If relaying is happening, and you haven't added the relay to your SPF, then you're wrong. There is no scenario where this is problem with SPF.
That is the problem, you do not control whether your email is being relayed. This does not happen on your side, it happens on the receiver's side. You cannot control that.
> Well, of course. If SPF is configured to disallow email, then further evaluation isn't necessary. Either fix SPF, or don't blame SPF.
That is the whole point we try to explain in the article, SPF can fail beyond your control. Hence you cannot rely on SPF for legitimate email to pass SPF evaluation.
This is why you don't want to rely on SPF, and focus on DKIM instead.
> These people are basically advocating for being OK with not configuring SPF properly. No. Just configure SPF properly.
Without DMARC, SPF offers no security at all. None. This is due the bypass vulnerability.
If you adopt DMARC (which you should!) then 'hard' fail and softfail become equal from a security perspective. With DMARC, anything that is not an aligned SPF pass is a fail. Even if a 'superduperultrafail' would exist, it would do the exact same thing as softfail.
But because SPF is so unreliable, you shouldn't rely on it in the first place. Focus on DKIM and DMARC. Leave SPF on softfail, which does the exact same thing as 'hard' fail, without the deliverability issues.
I don't understand this. First you're talking about forwarding / relaying you don't control, which... you shouldn't care about. If someone else wants to forward / relay, then they need to worry about SPF breakage. You don't, nor should you.
Then, you're talking about something entirely different:
"That is the whole point we try to explain in the article, SPF can fail beyond your control. Hence you cannot rely on SPF for legitimate email to pass SPF evaluation."
Huh? No. If SPF is configured to disallow, then DKIM shouldn't disagree with that. If you expect DKIM to "win", then you're doing it wrong.
Or I'm missing something. Please explain how "SPF can fail beyond your control" in either scenario: one, where you control your own SPF and you're concerned about outgoing email, or two, where you control your policy for enforcing SPF and you decide to block SPF with -all.
Also, your comments about DMARC still don't explain why it's somehow OK to NOT configure SPF properly in the first place.
For DMARC, you need SPF or DKIM to be aligned for the email to be accepted. One of the two is enough for the receiver to accept the email based on DMARC.
This is how DMARC is designed, I can't change that. You can have an SPF fail but aligned DKIM, the email will be accepted. You can have SPF alignment without a DKIM signature, and still be accepted. If you have neither, the email will be rejected.
This was all designed with backwards compatibility in mind. This was back in the days that not every email service was capable of signing with DKIM, so for those you could still use SPF. However, it was already widely accepted back then that SPF was very much broken by design, and you should use DKIM instead (but keep SPF for backwards compatibility).
DKIM is much better in terms of security (it uses actual cryptography) and reliability (much less likely to break beyond your control). If your email services support DKIM, you should use that.
> If SPF is configured to disallow, then DKIM shouldn't disagree with that. If you expect DKIM to "win", then you're doing it wrong.
DKIM is able to disagree with SPF, that's how DMARC is designed. If you an email has a valid signature, but not valid SPF, your email should still be accepted.
> Or I'm missing something. Please explain how "SPF can fail beyond your control" in either scenario: one, where you control your own SPF and you're concerned about outgoing email, or two, where you control your policy for enforcing SPF and you decide to block SPF with -all.
It think you are missing something. You can set a '-all' policy, but then you risk making you own perfectly authentic and DKIM signed email undeliverable. You cannot rely on SPF to pass, even if you have the sender set up correctly in the SPF policy. This has all been fixed with DKIM and DMARC, but setting '-all' may prevent this from working.
> Also, your comments about DMARC still don't explain why it's somehow OK to NOT configure SPF properly in the first place.
Because SPF is broken by design, and DKIM and DMARC have solved this. You are not going to get 'better' security with -all, since SPF does not provide any real security.
To simplify: SPF is broken by design. DMARC is better, but '-all' is not compatible with DMARC. So, the article discusses that the actual proper configuration of SPF is ~all, since you do not want to rely on SPF anyway.
I use hard fail, because all of the problems described in the article are implementation (checking if mail from and from: are on the same domain/subdomain) and idiocy (I've seen people forwarding mail to Google workspace hosted stuff by their own Mx without stripping or rewriting headers) problems.
The second one is really dumb, and results in 99.999% of my dmarc reports rather than actual forged emails.
All of these are solvable by anyone with a basic understanding of mail server operation.
Soft fail is also pointless, if you can't manage SPF records then you have no business emitting mail, pay a competent professional.
(As a side point, there are a lot of inaccuracies in the article but I expect the target audience is not me)
You cannot "strip off and rewrite" headers without destroying the email message's DKIM signature -- which is the primary assurance of authenticity of incoming email!
Also, you are ensuring that emails from your domain can never reach anyone who has a "forwarding" email address (which is anyone managing any significant number of domains). These people use Cloudflare, etc. to manage the MX for these domains, and forwarding incoming email to their central email address (which remains hidden).
You can't get away from email forwarding; its sort of baked into the underlying assumptions of SMTP, which you are unlikely to single-handedly defeat and replace with something better.
In the mean time, email from your domain will appear "broken" to a vast multitude of the world's email-receiving population.
Yes, yes you can, that is exactly what you need to do to avoid DKIM failure, you've already broken the ability to verify anything by rewriting the destination.
Also see: forwarding is broken (purely forwarding mail via SMTP is not the same as what the comment was about)
You don't "rewrite" the destination (the "To: <address>" header); you just forward the email along using another "RCPT TO: <address>".
How do you propose that you "rewrite" headers without breaking DKIM? Any header included in the message's DKIM "h=to:from:... " stanza cannot be changed; they're included in the DKIM signature.
You can simply textually include the entire original email in a completely NEW email message, that is DKIM-signed by your intermediate (forwarding) MTA -- but that's not "forwarding", at all -- that's just "sending an email".
It does, but you can't rely on ARC being implemented by the receiver.
ARC is one of the latest additions to email standards (introduced in 2019), there are a lot of legacy email systems that don't support it. If an SMTP service supports ARC, then it will probably also support DMARC (introduced in 2015) and DKIM (introduced in 2011). So you'll still be better of with using DKIM, as DKIM adds cryptographic proof of authentication and integrity, whereas SPF is just a simple allow list.
The big challenge with email is finding a happy medium between security, and backwards compatibility for legacy systems.
In practice difference between SPF softfail and SPF hardfail is less significant than in theory (where everyone follows RFC7208 to the letter). Many mail system don't reject a message in case of SPF fail - SPF result is used one of many inputs for an anti-spam system. If we have SPF pass we can assume that a message was sent from an infrastructure approved by the domain owner and if domain has good reputation we can take it into account. If we don't have SPF pass then the sender address in the message can be spoofed. Be it SPF softfail or hardfail or even a missing SPF record we cannot trust the sender address. But if otherwise message looks good it still can be accepted.
DMARC makes things a bit more complicated but it is similar - either you have DMARC pass (which is good) or you don't have it and why exactly you don't have DMARC pass is less important.
31 comments
[ 3.0 ms ] story [ 25.2 ms ] threadAdding to this, hard fail should be used with parked domains without exception. If a domain is not used for sending emails then it should have a null MX and hard fail SPF stating not to trust any IP's or domains.
This is correct, but this is also mentioned in the article multiple times.
To add to that, a DMARC record with a "reject" policy is also recommended for domains that are not supposed to send any email, see also: https://www.mailhardener.com/kb/hardening-unused-domains
Could be useful, but a successful attack on BIMI would require: - Getting access to the DNS of the domain (in which case the null record will simply be replaced) - Obtaining a VMC for the domain, which should not be possible due to the extended validation requirement for a VMC (such as: phone validation) - Spending ~$800 on a VMC
> especially if one is going to use soft-fail.
As explained in the article, if DMARC is deployed then softfail is equal to (hard) fail. With DMARC anything that is not an SPF pass, is not aligned, thus a fail.
The only exception here would be a very old legacy email system that doesn't support DMARC. But those will also not support BIMI anyway.
> Or maybe a malware symbol.
BIMI should always require a VMC. It should be impossible to obtain a VMC with a 'malware symbol'. Unless of course you are willing to pay a lot to get it registered as your company logo at your trademark office.
This is a lot of people.
Why are you OK with that?
Most orgs do not have their shit together. So if you are offering a service in the email space, telling your customers to set hard fail is just going to drive up your complaints and support costs.
It makes total sense that this company is advising soft fail. Most people can’t juggle chainsaws safely.
Keeping perfect track of all the various departments, services, vendors, IP addresses, etc sending on behalf of your domain is very hard in many organizations.
In fact, I would argue that you MUST assume that at least some non-trivial percentage of those other organizations are actually fucked up with regards to one or more of these areas.
So, therefore, you must be even more conservative than you might otherwise have been. Even if everyone on the planet is a CMM-5 level organization, you're still going to lose the odd space shuttle or two. And maybe also some rockets.
The forwarding problem has been with us since Internet e-mail was first created, and I don't see that problem going away. Ever.
All you can do is decide how you're going to handle that for your own accounts where you set up forwarding, which may very well break e-mail coming from domains that don't fully understand the problem.
Just like how regular developers shouldn't be able to push work in to a cloud that'll end up costing tens or hundreds of thousands of dollars without deliberate, thought out reasoning, random people in a company should not be able to set up outgoing email using a company's domain without good reasoning.
If a person or a group were responsible for outgoing email, then nobody would be allowed, nor should they be able, to send without going through that person / group. Problem solved!
But if you think it's OK for any random person at an organization to just set up whatever kind of outgoing email they want, well, you get what you expect.
It's valid to question and change strategies, but I don't think it's a good approach that people who've been chastised for years for softfails are suddenly being chasisted for hard fails.
Edit:
Note that users signing up to Office 365 are told to use hardfail: https://learn.microsoft.com/en-us/microsoft-365/security/off...
It wouldn't surprise me if MS was being harassed by angry 'experts' for not recommending 'hard' fail, because clearly that would be so much more secure (just look al all the comments in this topic).
So I get it, advising to use a strict failure mode, even at the expense of some undeliverable email is acceptable for MS. But for those who have already adopted DMARC, the SPF 'hard' fail only increases the chance of undeliverable mail, while offering zero security benefits.
"One of them is that a relaying SMTP service (sometimes called a 'forwarder') will break SPF. This is known as the relaying problem."
If relaying is happening, and you haven't added the relay to your SPF, then you're wrong. There is no scenario where this is problem with SPF.
"If the email is bounced on the SMTP level due to an SPF 'hard' fail, the receiver may not perform further evaluation of the email, ignoring DKIM and DMARC."
Well, of course. If SPF is configured to disallow email, then further evaluation isn't necessary. Either fix SPF, or don't blame SPF.
These people are basically advocating for being OK with not configuring SPF properly. No. Just configure SPF properly.
1. paypal SMTP sends mail to myself@xyz.com 2. xyz.com receive mail SPF is valid 3. xyz.com sends the paypal mail to myself2815@gmail.com 4. gmail.com receives mail SPF is invalid
I can't add XYZ.com to Paypal SPF and hardfail would mean email loss in this case.
SPF is broken by design for many cases and should just used with softfail and dkim/dmarc.
There is arc but it has its own problems.
Sure, it's probably silly. But, SMTP is what it is, and you're not going to change it by complaining
SPF's design just ... forgot about this, which happens all the time for email.
Every MTA -- literally every forwarding MTA -- does this all day long, and every receiving MTA (which looks at the "Return-Path: <originaladdress>" to lookup the SPF TXT record), gets your fancy "v=spf1 ... nothing w/ forwarding MTA in it ... -all" record, and summarily executes the email w/ SPF: FAIL?
It's just wrong. SPF can only serve as one (strong) hint that an email might be correct, if it passes. If it fails, all your MTA can assume is: "well, the email was very likely forwarded"; what else does it have going for it?
If its "DKIM-Signature: ..." header is valid, that it's almost certainly A-OK! So, why do you want all your domain's nicely DKIM-signed emails dropped, just because some recipient decided to use a "forwarding" email address?
That seems silly.
Little guys like me (of course) don't get included in anyone's ARC configuration, to patch over SPF's profound design failure.
If you're describing a "forwarding" solution that doesn't simply do SMTP "RCPT TO" forwarding, then I don't understand what you're describing...
> If relaying is happening, and you haven't added the relay to your SPF, then you're wrong. There is no scenario where this is problem with SPF.
That is the problem, you do not control whether your email is being relayed. This does not happen on your side, it happens on the receiver's side. You cannot control that.
> Well, of course. If SPF is configured to disallow email, then further evaluation isn't necessary. Either fix SPF, or don't blame SPF.
That is the whole point we try to explain in the article, SPF can fail beyond your control. Hence you cannot rely on SPF for legitimate email to pass SPF evaluation.
This is why you don't want to rely on SPF, and focus on DKIM instead.
> These people are basically advocating for being OK with not configuring SPF properly. No. Just configure SPF properly.
Without DMARC, SPF offers no security at all. None. This is due the bypass vulnerability.
If you adopt DMARC (which you should!) then 'hard' fail and softfail become equal from a security perspective. With DMARC, anything that is not an aligned SPF pass is a fail. Even if a 'superduperultrafail' would exist, it would do the exact same thing as softfail.
But because SPF is so unreliable, you shouldn't rely on it in the first place. Focus on DKIM and DMARC. Leave SPF on softfail, which does the exact same thing as 'hard' fail, without the deliverability issues.
Then, you're talking about something entirely different:
"That is the whole point we try to explain in the article, SPF can fail beyond your control. Hence you cannot rely on SPF for legitimate email to pass SPF evaluation."
Huh? No. If SPF is configured to disallow, then DKIM shouldn't disagree with that. If you expect DKIM to "win", then you're doing it wrong.
Or I'm missing something. Please explain how "SPF can fail beyond your control" in either scenario: one, where you control your own SPF and you're concerned about outgoing email, or two, where you control your policy for enforcing SPF and you decide to block SPF with -all.
Also, your comments about DMARC still don't explain why it's somehow OK to NOT configure SPF properly in the first place.
This is how DMARC is designed, I can't change that. You can have an SPF fail but aligned DKIM, the email will be accepted. You can have SPF alignment without a DKIM signature, and still be accepted. If you have neither, the email will be rejected.
This was all designed with backwards compatibility in mind. This was back in the days that not every email service was capable of signing with DKIM, so for those you could still use SPF. However, it was already widely accepted back then that SPF was very much broken by design, and you should use DKIM instead (but keep SPF for backwards compatibility).
DKIM is much better in terms of security (it uses actual cryptography) and reliability (much less likely to break beyond your control). If your email services support DKIM, you should use that.
> If SPF is configured to disallow, then DKIM shouldn't disagree with that. If you expect DKIM to "win", then you're doing it wrong.
DKIM is able to disagree with SPF, that's how DMARC is designed. If you an email has a valid signature, but not valid SPF, your email should still be accepted.
> Or I'm missing something. Please explain how "SPF can fail beyond your control" in either scenario: one, where you control your own SPF and you're concerned about outgoing email, or two, where you control your policy for enforcing SPF and you decide to block SPF with -all.
It think you are missing something. You can set a '-all' policy, but then you risk making you own perfectly authentic and DKIM signed email undeliverable. You cannot rely on SPF to pass, even if you have the sender set up correctly in the SPF policy. This has all been fixed with DKIM and DMARC, but setting '-all' may prevent this from working.
> Also, your comments about DMARC still don't explain why it's somehow OK to NOT configure SPF properly in the first place.
Because SPF is broken by design, and DKIM and DMARC have solved this. You are not going to get 'better' security with -all, since SPF does not provide any real security.
To simplify: SPF is broken by design. DMARC is better, but '-all' is not compatible with DMARC. So, the article discusses that the actual proper configuration of SPF is ~all, since you do not want to rely on SPF anyway.
The second one is really dumb, and results in 99.999% of my dmarc reports rather than actual forged emails.
All of these are solvable by anyone with a basic understanding of mail server operation.
Soft fail is also pointless, if you can't manage SPF records then you have no business emitting mail, pay a competent professional.
(As a side point, there are a lot of inaccuracies in the article but I expect the target audience is not me)
Could you elaborate on those?
Also, you are ensuring that emails from your domain can never reach anyone who has a "forwarding" email address (which is anyone managing any significant number of domains). These people use Cloudflare, etc. to manage the MX for these domains, and forwarding incoming email to their central email address (which remains hidden).
You can't get away from email forwarding; its sort of baked into the underlying assumptions of SMTP, which you are unlikely to single-handedly defeat and replace with something better.
In the mean time, email from your domain will appear "broken" to a vast multitude of the world's email-receiving population.
Your domain, not theirs.
Also see: forwarding is broken (purely forwarding mail via SMTP is not the same as what the comment was about)
How do you propose that you "rewrite" headers without breaking DKIM? Any header included in the message's DKIM "h=to:from:... " stanza cannot be changed; they're included in the DKIM signature.
You can simply textually include the entire original email in a completely NEW email message, that is DKIM-signed by your intermediate (forwarding) MTA -- but that's not "forwarding", at all -- that's just "sending an email".
Is this what you're describing?
https://en.wikipedia.org/wiki/Authenticated_Received_Chain
ARC is one of the latest additions to email standards (introduced in 2019), there are a lot of legacy email systems that don't support it. If an SMTP service supports ARC, then it will probably also support DMARC (introduced in 2015) and DKIM (introduced in 2011). So you'll still be better of with using DKIM, as DKIM adds cryptographic proof of authentication and integrity, whereas SPF is just a simple allow list.
The big challenge with email is finding a happy medium between security, and backwards compatibility for legacy systems.
DMARC makes things a bit more complicated but it is similar - either you have DMARC pass (which is good) or you don't have it and why exactly you don't have DMARC pass is less important.