Send authentication emails from your own domain
Add and verify a sending domain so sign-in, verification and reset emails show your brand and address.
Out of the box, authentication emails are sent from PGB's address. If you add your own domain, people see your name and an address such as [email protected]. If anything goes wrong with your domain, emails still arrive from PGB's address, so users are never locked out.
Add a domain
- Open Authentication > Settings > Sender domain.
- In Domain, enter a root domain or subdomain you own, for example
yourdomain.com. - In Send from, enter the part before the
@. The default isauth. A line under the field, Delivers as, shows the final address. - Choose Add domain.
The domain card lists the DNS records to create. Add them at your DNS provider. Some providers can be connected so that the records are created for you, where the page offers it.
Verify it
When the records are in place, choose Check DNS on the domain card. The status changes:
| Status | Meaning |
|---|---|
| Waiting for DNS | Records not seen. DNS changes take time to spread, so check again later. |
| Verified | Sign-in emails now send from your address. |
| Not verified | The check ran but the records do not match. |
| Paused by PGB | Sending from the domain is stopped, and emails go out from PGB's address while it is paused. Contact support to resolve it. |
Manage domains
- Change sender edits the part before the
@for a verified domain. - Remove stops using the domain. Emails go back to PGB's address.
- Use for PGB Mail (needs approval) copies a verified domain to your project's transactional mail, where you add its extra DNS records. It is only available once your project has mail access.
Good to know
- You can use up to 5 domains on your account in total (pending and verified). The Console tells you how many you are using, and asks you to remove one before adding another.
- A domain can only be used for one purpose at a time, and a domain already registered by another account is refused.
- Automatic pausing exists to protect your reputation: if a domain's bounces or complaints get too high, it is paused until the cause is fixed.
- For a refresher on SPF, DKIM and DMARC, see MX, SPF, DKIM and DMARC records explained.
More guides in Console: authentication
Authentication in your project: users, settings and the Playground
What built-in authentication gives your app, and a tour of the Authentication page in the Console.
Choose sign-in methods and password rules
Turn sign-in methods on or off, set password rules and session lifetimes, and decide whether email must be verified.
Email verification and password reset
How confirmation emails and password resets work, and how to wire the links into your app.
Customize the emails your users receive
Edit the subject, wording, sender name and button colour of sign-in, verification and reset emails, with a live preview.
Add social login with Google or GitHub
Register your app with a provider, paste its credentials into the Console, and let people sign in with an account they already have.
Two-factor sign-in for your app's users
How your users can protect their accounts with an authenticator app, and how you test and reset it.