Fully customizable verification emails
Currently, Azure AD B2C sends verification codes via emails to end users during sign-up and password reset flows. These emails have limited customization. Add support for full customization of the email body & content.
We continue evaluating several alternatives to provide full email customization. We are actively working on an alternative.
Unfortunately we do no yet have an ETA.
It's not just a branding problem. For loads of our clients the verification emails are marked as spam by their company's email system so never get through. We've had to disable the email verification entirely in order for it to work for our clients, and we're now dealing with the issues this brings.
We are in development, but when production comes in a couple months, this will be crucial from brand identity
Leandro Rossa commented
And also you guys have a really difficult sign up page. When clicking Send Verification Code, no feedback is given. When inputting the code, no feedback given. Sorry for the bad words, but you guys are not giving a single s**t for the users or the brands which pay high amounts of money for the service. Is it secure enough to justify the bad UX? I don't know. Users just want things that work and don't make them think. – Words from a UX Designer with a user perspective.
Leandro Rossa commented
That's just terrible for branding and user experience. Why is Microsoft sending emails "On behalf of" my brand? Why it says it's from "an unmonitored email address". Why can't it have my brand colors and fonts? Users would think "is it a real email or a fake one?". Sorry Microsoft, you just did a really bad job with this.
Alok Singh commented
Any further update on this?
Jose Alfredo commented
Anything on this ?
Hi AD Team, could you please provide an update? We need to decide to stay with the solution or not ...
Brent Landry commented
This was under review two months ago. Can we get an update on that?
Coding Panda commented
Very important feature. Is this on the road map yet?
Geir Fuhre Pettersen commented
Dan: They are probably using custom policies.
You should watch this for inspiration and examples of what can be done with custom policies, and other videos in the same channel:
Good luck! (You will need it to, to keep track of all the lines of config in many files which is part of a policy :-)
How does realmadrid send from firstname.lastname@example.org for verification?
We are looking at implementing this for a large organisation with thousands of public-facing users. This is a serious branding issue that needs to be resolved asap. Please implement this feature (including supporting B2C on customer domains)
Would it be possible for Microsoft to hire someone just to deliver this small feature please
Hello it´s a very important feature for Big companies
It is also important that these email can be sent from the customers domain, rather than from email@example.com. There is a separate backlog item started to support B2C on Customer Domains. Perhaps this efforts can be combined?
Jeremy Kong commented
I vote for it as well. I am looking for the ability to customize the format of the verification code and to extend the validity period of the verification code.
Granville Schmidt commented
We're using AAD B2C for our product and are currently whitelabeling it. We need this feature yesterday. Any update as to when this will be ready?
Damien Zwillinger commented
Ping! Microsoft B2C Team?
Fred C commented
Companies today are fighting the battle of email spoofing and phishing campaigns. These malware emails result in lost productivity and sales and decrease customer confidence when they see an email come from someone different that our company. We need to have the ability to modify the from (sender) email domain as our own. Yes...its true, folks out there will ignore or interpret an email coming from ***.onmicrosoft.com as 'phishing'.
Gyorgy Hingyi commented
Even more importantly than just the email subject and template, we need to be able to specify a custom sender address.
Ideally this would work by configuring SPF/DKIM for a domain that we own, but it is also fine to require SMTP connection details for a relay cluster we manage.