Welcome to the "Build and Test Your Application" section of the Twilio SendGrid Onboarding Guide. When you complete this milestone, you'll be able to communicate with your customers whenever you need and at whatever scale you require. We encourage you to complete all the steps presented here. In the evolving world of email, a careful roll-out will help you avoid costly and time-consuming remediation.
In this Onboarding Guide section, your team will:
We designed these steps to facilitate a team implementation process, including both developers and non-developers. Each step and its associated action(s) is marked as required, recommended, or optional to help you navigate this guide efficiently while providing all the information needed to develop a solid email program.
You'll perform many of the following steps in the Twilio SendGrid user interface (UI). However, some steps are more technical than others, and we've noted when you may benefit from having a developer available.
Twilio SendGrid offers three paid plans: Essentials, Pro, and Premier. Each plan provides a set of features and a range of sending capacities. In this step, you'll choose an upgraded plan (if you haven't already) that will give you the capability to send up to a certain volume of monthly messages.
Some of the following optional steps and actions such as managing Subusers and adding dedicated IP addresses will require a Pro or Premier plan.
Next, you'll build your parent account and ensure that your key team members have the right level of access to that parent account. Finally, you'll add any additional IP addresses needed to send at your initially anticipated volume. These tactical building blocks will lay the groundwork for everything else you are about to do.
Navigate to the linked documentation and resources below to complete the actions in this step.
Action | Requirement Level |
---|---|
Create a new account or login to your account. | Required |
Enable Two-Factor Authentication. | Required |
Upgrade your plan to ensure that you can send at the volume you need. | Required |
Assign Teammates to collaborate with and set their permissions. | Recommended |
Add additional IP addresses. | Optional |
Subusers help you segregate your email sending and statistics. You can assign permissions and credit limits to a Subuser, and dividing your sending across Subusers allows you to get separate statistics and separate reputations for each Subuser.
For most customers, we recommend creating Subusers for each of the different types of email you send (e.g. Marketing Email vs. Transactional Email). In this case, the Subuser can be thought of less as a user and more as a type of email. For independent software vendors (ISVs), we recommend creating Subusers for your different clients (e.g. Client A Subuser, Client B Subuser).
In step one of this section, you could have optionally created Teammates, which are different from Subusers. Teammates are people who have permissions to access either a parent account, a Subuser, or both. Subusers are child accounts of the parent account.
You can think of Subusers like subaccounts. Each Subuser account is its own email ecosystem with isolated contacts, templates, suppressions, and data. Subusers feed off their parent account email credits, and all billing rolls up to the parent account. Subusers can have their own Teammates who can access only the Subuser accounts to which they are assigned.
Navigate to the linked documentation and resources below to complete the actions in this step.
Action | Requirement Level |
---|---|
Create one or more Subusers. | Recommended |
Sender authentication shows email providers that Twilio SendGrid has your permission to send emails on your behalf. The sender authentication process is composed of three steps: domain authentication, link branding, and reverse DNS (rDNS).
To complete domain authentication, you must be able to add DNS records to your DNS host.
To designate Twilio SendGrid as an allowed sender on your domain, you will add DNS records provided by Twilio SendGrid to your DNS entries using your DNS provider (e.g. GoDaddy, Rackspace, Cloudflare, Route53, etc.). These entries are known as SPF and DKIM records. To better understand how these records work, see our SPF and DKIM documentation.
To complete link branding, you must be able to add DNS records to your DNS host.
Link branding allows your click-tracked links and open-tracked images to appear as though they come from your domain rather than sendgrid.net. To complete link branding, you will add CNAME records to your domain that point back to Twilio SendGrid. This means your links appear from your domain, but the click and open data is routed back to Twilio SendGrid where you can manage it.
To complete reverse DNS, you must be able to add DNS records to your DNS host. rDNS is necessary only for accounts using dedicated IP addresses.
Reverse DNS (rDNS) associates your dedicated Twilio SendGrid IP address(es) with your authenticated domain. To complete rDNS, you will place an A record on your domain for the IP address provided by Twilio SendGrid. When a mailbox provider looks up your A Record on your sending domain, they will see your Twilio SendGrid IP address. When they look at your IP address, they will see the rDNS matching your A Record. This circular check tells email service providers (ESPs) and email recipients that your email is legitimate and trustworthy.
Navigate to the linked documentation and resources below to complete the actions in this step.
Action | Requirement Level |
---|---|
Set up domain authentication. | Required |
Assign Subusers to an authenticated domain. | Required when using Subusers |
Set up link branding. | Recommended |
Enable reverse DNS. | Required when using dedicated IP addresses |
The set of actions in this step pertain primarily to using the Twilio SendGrid Email API. You will benefit by having a developer available for this step.
API keys and the Twilio SendGrid Event Webhook are both powerful parts of the Twilio SendGrid API. API keys allow you to quickly control who has access to what in your email application. Our Event Webhook provides the data necessary to understand how users are engaging with your communications.
Proactively managing your global and group unsubscribes will improve your reputation with ESPs because you'll be automatically emailing users who are more likely to engage with your content. Each of these settings is key to the optimal functioning of your application.
Navigate to the linked documentation and resources below to complete the actions in this step.
Action | Requirement Level |
---|---|
Manage Twilio SendGrid API keys. | Required |
Set up the Twilio SendGrid Event Webhook. | Recommended |
Configure the signed Event Webhook. | Optional |
Review the Event Webhook reference. | Optional |
Review suppressions and unsubscribe concepts. | Recommended |
Enable global unsubscribes. | Optional |
Enable group unsubscribes. | Optional |
Review the Design & Code Editor for substitution tags. | Optional |
It's time to integrate the Mail Send API and test your application. Having a developer available will be beneficial.
When sending email with Twilio SendGrid, you can use either the Email API, which sends mail over HTTP and provides a modern developer experience, or route mail through our SMTP service.
When using the Email API, you also have access to Twilio SendGrid's helper libraries, allowing you to quickly integrate with the API using C#, Go, Java, Node.js, PHP, Python, or Ruby.
You can also use our Dynamic Template system to send visually appealing email designs that are easy to customize both for your brand and to the individual recipients receiving them.
Navigate to the linked documentation and resources below to complete the actions in this step.
Action | Requirement Level |
---|---|
Prepare to send using the Email API Quickstart with your preferred language. | Recommended |
Prepare to send with SMTP. | Optional |
Design a test email. | Required |
Send a test email. | Required |
In the early stages of your email application, your new IP address will be what the industry calls "cold." Internet services providers (ISPs) scrutinize cold IP addresses more closely. If you start sending large volumes of email too quickly from a cold IP, your email may be filtered at higher volumes, causing your IP's reputation to drop considerably. When this occurs, you'll lose time rebuilding that reputation. Instead, we strongly recommend that you plan and execute a steady IP warm-up, slowly building to your desired volume. This will allow you to test and correct your email performance in smaller batches, gradually developing the reputation of your IP. It can be tempting to skip an IP warm-up, but our experience shows time and again that you'll reach peak performance faster if you complete this step.
Navigate to the linked documentation and resources below to complete the actions in this step.
Action | Requirement Level |
---|---|
Review how an IP warm-up works. | Recommended |
Use these guidelines to create your warm-up schedule and start sending. | Recommended |
When you complete the steps above, you'll have a working email application. You will have an IP with a strong reputation, and your emails will be landing in your recipients' inboxes with minimal filtering.
Your email application should now have:
Your email application may also have: