Hi @DigitalStartupUK. Thank you for your report.
To help us process this issue please make sure that you provided the following information:

• Summary of the issue
• Information on your environment
• Steps to reproduce
• Expected and actual results

Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:

@magento give me 2.4-develop instance - upcoming 2.4.x release

For more details, please, review the Magento Contributor Assistant documentation.

Please, add a comment to assign the issue: @magento I am working on this

• Join Magento Community Engineering Slack and ask your questions in #github channel.

⚠️ According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.

🕙 You can find the schedule on the Magento Community Calendar page.

📞 The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, please join the Community Contributions Triage session to discuss the appropriate ticket.

🎥 You can find the recording of the previous Community Contributions Triage on the Magento Youtube Channel

✏️ Feel free to post questions/proposals/feedback related to the Community Contributions Triage process to the corresponding Slack Channel

It's not directly related as this issue talks that smtp should be a documented requirement but current workaround for dev environments (that don't need to have smtp set up) is simply to disable 2fa

bin/magento mo:di Magento_TwoFactorAuth

But at some point, 2FA needs to be enabled during Development/Production. And there is probably an argument that states "well, surely in a Development/Production environment you would have an SMTP enabled server." But speaking from experience, myself and many others use 3rd party SMTP providers - Which are normally configured in the Admin Backend. It just seems like a really overlooked part of the installation/setup process. What's the point of enforcing 2FA on installation to only immediately disable it?

I'd simply prefer a simple CLI config:set command to generate the same URL that gets sent in the Email. Or even better, have the URL output with the Admin Backend URL notification that you see on successful install.

Post installation file permissions check...
For security, remove write permissions from these directories: '/var/www/html/magento2/app/etc'
[Progress: 274 / 274]
[SUCCESS]: Magento installation complete.
[SUCCESS]: Admin Panel URI: /admin_puu71q
[SUCCESS]: Complete Admin 2FA URI: http://example.com/tfa/example...

I'm trying not to sound negative and whiny, but this lack of clarity is frustrating.

Hi, i'am exactly on the same point ... same error, same step ... i will try another solution

Hi,
What is another solution?

What a nightmare. Same issue here. This is the first time I encountered a 2fa setup situation that requires email. Usually you log into admin, enable 2fa and then set up the token logged into admin.

In case anyone needs a temporary workaround to get this working without having SMTP set up:

1. navigate to /admin and log in
2. you should see the 2FA screen now
3. add var_dump($url);die; on line 86 in vendor/magento/module-two-factor-auth/Model/EmailUserNotifier.php
4. refresh /admin
5. copy the URL that is displayed
6. remove the var_dump
7. use the URL copied earlier to navigate to the 2FA setup

A great Magento MX developer has created a module to disable double authentication.
This is the repo Module_EnableDisableTFA.
You can also install it from composer composer require wolfsellers/module-enabledisabletfa

by @Rus0

Temporary solution to kick start your development, just disable Magento_TwoFactorAuth module. It worked for me.

bin/magento module:disable Magento_TwoFactorAuth

Great security feature added for that administration login section of Magento however I have also ran into another weird issue that personally has stopped me from being able to set up 2FA on a fresh install. My issue is that magento does not use the domain name set for the outgoing email when sending the email out to set up 2FA on a fresh install instead it sends the email from owner@example.com. I know normally that might not be a big issue but when sending emails from a server on a more security conscious Enterprise network that email may never actually go to the intended target because of the email domain of @example.com.

I have now disabled the Magento_TwoFactorAuth module as described above and have managed to login to the admin interface but I am now in the process of figuring out how to reenable/set up 2FA.

Did you get it to work?

I see the same problem. I cannot get 2FA to work, since the mail is sent from owner@example.com
Since I'm working with a more secure mailserver, I cannot sent mails from example.com domain.
I suggest to add a parameter during installation to set the owners E-Mail adress.

Speechless @magento-admin ...

Same issue with me while following Installation quick reference (tutorial) from Magento

for now I have disabled module (until I setup SMTP), as suggested by @speedupmate
bin/magento mo:di Magento_TwoFactorAuth

Dropping this here for anyone having trouble configuring their mail in order to activate the 2FA.
To clarify, you do this on your Magento2 host, not your mail server.
Once finished just log out of Magento2 WebUI, then log back, you should receive the email.
Be sure to replace all occurrences of YourDomain.com with your domain name.

===============================================================================
configure postfix to be able to send mail
===============================================================================
sudo apt install -y mailutils
  (after this first line, sudo is active, can paste entire block below)

echo "${HOSTNAME}.YourDomain.com" | sudo tee /etc/mailname
echo "/.+/ admin@YourDomain.com" | sudo tee /etc/postfix/sender_canonical
echo "/.+/ admin@YourDomain.com" | sudo tee /etc/postfix/recipient_canonical
#echo "/.*root.*/ admin@YourDomain.com" | sudo tee --append /etc/postfix/recipient_canonical
#echo "/.*user2.*/ admin@YourDomain.com" | sudo tee --append /etc/postfix/recipient_canonical
echo "myhostname = ${HOSTNAME}.YourDomain.com" | sudo tee /etc/postfix/main.cf
echo "mydestination = localhost.YourDomain.com, localhost, ${HOSTNAME}" | sudo tee --append /etc/postfix/main.cf
echo "masquerade_domains = YourDomain.com" | sudo tee --append /etc/postfix/main.cf
echo "smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)" | sudo tee --append /etc/postfix/main.cf
echo "sender_canonical_maps = regexp:/etc/postfix/sender_canonical" | sudo tee --append /etc/postfix/main.cf
echo "recipient_canonical_maps = regexp:/etc/postfix/recipient_canonical" | sudo tee --append /etc/postfix/main.cf
echo "biff = no" | sudo tee --append /etc/postfix/main.cf
echo "append_dot_mydomain = no" | sudo tee --append /etc/postfix/main.cf
echo "alias_maps = hash:/etc/aliases" | sudo tee --append /etc/postfix/main.cf
echo "alias_database = hash:/etc/aliases" | sudo tee --append /etc/postfix/main.cf
echo "relayhost =" | sudo tee --append /etc/postfix/main.cf
echo "mynetworks = 127.0.0.0/8" | sudo tee --append /etc/postfix/main.cf
echo "inet_interfaces = loopback-only" | sudo tee --append /etc/postfix/main.cf
echo "recipient_delimiter = +" | sudo tee --append /etc/postfix/main.cf
echo "compatibility_level = 2" | sudo tee --append /etc/postfix/main.cf
echo "myorigin = /etc/mailname" | sudo tee --append /etc/postfix/main.cf
echo "mailbox_size_limit = 0" | sudo tee --append /etc/postfix/main.cf
echo "inet_protocols = ipv4" | sudo tee --append /etc/postfix/main.cf
sudo postmap /etc/postfix/recipient_canonical
sudo postmap /etc/postfix/sender_canonical
sudo systemctl restart postfix
echo "${HOSTNAME} postfix test" | sudo mail -s "${HOSTNAME} Testing postfix configuration" YourName@YourDomain.com
sudo rm -rf /var/mail/root
sleep 1 && sudo postqueue -p

  if it broke, read the error then delete it:
sudo postsuper -d ALL

sudo cat /etc/hosts

In the above block you will see two lines commented out, they are relevant to what is discussed below:
-------------------------------------------
The Regex in /etc/postfix/recipient_canonical can be adjusted
This line takes any and all destinations and changes them to goto admin@YourDomain.com,
mail delivery is guaranteed to work but you cannot send mail to other recipients
Perfectly Fine for Standalone services that ONLY need to mail one address.
-------------------------------------------
/.+/ admin@YourDomain.com

-------------------------------------------
It can be customized to only catch certain recipients such as root, etc:
-------------------------------------------
/.*root.*/ admin@YourDomain.com

For Magento2, you can just comment out the line for recipient_canonical_maps in your /etc/postfix/main.cf after you have 2FA configured.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 14 days if no further activity occurs. Is this issue still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? Thank you for your contributions!

Other workaround (https://devdocs.magento.com/guides/v2.4/security/two-factor-authentication.html):
bin/magento config:set twofactorauth/general/force_providers google
bin/magento config:set twofactorauth/google/otp_window 60
bin/magento security:tfa:google:set-secret <admin_user> <Base32-encoded_string_for_the_shared_secret_value>

Base32: https://emn178.github.io/online-tools/base32_encode.html

Other workaround (https://devdocs.magento.com/guides/v2.4/security/two-factor-authentication.html): bin/magento config:set twofactorauth/general/force_providers google bin/magento config:set twofactorauth/google/otp_window 60 bin/magento security:tfa:google:set-secret <admin_user> <Base32-encoded_string_for_the_shared_secret_value>

Base32: https://emn178.github.io/online-tools/base32_encode.html

What mean ? <Base32-encoded_string_for_the_shared_secret_value>
Is this mean "encoded_string of <admin_user>" ?

@hgati no, the admin username (<admin_user>) is before the shared secret (see the linked Magento doc).
The <Base32-encoded_string_for_the_shared_secret_value> must be the encoded string of a chosen key you create manually in Google Authenticator.