SendGrid MX Records: How to Set Up Inbound Parse for Receiving Email
Learn how to configure SendGrid MX records to receive inbound email with Inbound Parse, set up webhooks, and verify your setup with a free MX record checker.
SendGrid is best known as a sending service: transactional emails, marketing campaigns, password resets. But it also has a feature called Inbound Parse that lets you receive email through SendGrid and process it programmatically. If you want to capture incoming messages and route them to your application, a helpdesk, or an automation workflow, Inbound Parse is how you do it.
This guide walks you through setting up the MX records and webhook configuration required to receive email through SendGrid.
What Inbound Parse Actually Does
Normally, when someone sends email to your domain, it goes to a mail server where it sits in a mailbox. Inbound Parse works differently. Instead of storing the email in a traditional inbox, SendGrid receives the message, parses it into its components (sender, subject, body, attachments), and forwards that data as an HTTP POST request to a URL you specify.
This is useful for businesses that want to automate email processing: routing support tickets, capturing form submissions sent by email, triggering workflows when a specific type of message arrives, or archiving inbound correspondence in a database.
Inbound Parse is not a replacement for a regular email inbox. If your team needs to read and reply to email in Outlook or Gmail, use a standard email provider like Google Workspace or Microsoft 365 for that. Inbound Parse is for programmatic processing.
What You Need Before You Start
To set up SendGrid Inbound Parse, you need:
- A SendGrid account (the free tier supports Inbound Parse)
- A domain or subdomain you want to receive email on
- Access to your domain's DNS settings at your registrar or DNS provider
- A publicly accessible webhook URL where SendGrid will POST parsed email data
If you plan to use Inbound Parse alongside a regular email provider, set it up on a subdomain (like parse.yourdomain.com or inbound.yourdomain.com) so it does not interfere with your primary email routing.
SendGrid's MX Record Value
SendGrid uses a single MX record for Inbound Parse:
Host: @ (or your subdomain, e.g. parse)
Value: mx.sendgrid.net
Priority: 10
Unlike some email providers that give you two or more MX records for redundancy, SendGrid uses one. This is standard for programmatic email services. The infrastructure behind mx.sendgrid.net handles redundancy internally.
Step 1: Add the MX Record at Your DNS Provider
Log into your domain registrar or DNS provider (Cloudflare, GoDaddy, Namecheap, Route 53, or wherever you manage DNS) and add a new MX record.
For root domain email (you@yourdomain.com):
- Type: MX
- Host / Name:
@(or leave blank depending on your provider) - Mail Server / Value:
mx.sendgrid.net - Priority:
10 - TTL:
3600(or the default)
For subdomain email (you@parse.yourdomain.com):
- Type: MX
- Host / Name:
parse(or whatever subdomain you chose) - Mail Server / Value:
mx.sendgrid.net - Priority:
10 - TTL:
3600
If there are existing MX records for the same host (root domain or subdomain), you need to remove them first. Having competing MX records from different providers causes unpredictable delivery, with some messages going to SendGrid and others to the old provider.
Save the record and allow time for DNS propagation. This typically takes a few minutes to a few hours.
Step 2: Verify the MX Record Is Live
Before configuring the webhook, confirm that your MX record is publishing correctly. Go to mxrecordchecker.com and enter your domain (or subdomain). You should see mx.sendgrid.net listed with priority 10.
If the record does not appear yet, wait 15-30 minutes and check again. If it still does not show up after an hour, go back to your DNS provider and verify the record was saved correctly.
Step 3: Configure Inbound Parse in SendGrid
With the MX record live, you need to tell SendGrid what to do with email it receives.
- Log into your SendGrid account at app.sendgrid.com
- Navigate to Settings > Inbound Parse
- Click Add Host & URL
- Enter your domain (or subdomain). This must match the domain where you added the MX record
- Enter your Destination URL, the webhook endpoint where SendGrid will POST parsed email data
- Optionally check Check incoming emails for spam if you want SendGrid to include spam scoring
- Optionally check Send raw if you want the full raw MIME message instead of parsed fields
- Click Add
The Destination URL must be a publicly accessible HTTPS endpoint. SendGrid will send an HTTP POST request to this URL every time an email arrives at your domain. The POST body contains the parsed email fields: from, to, subject, text body, HTML body, and any attachments.
What SendGrid Sends to Your Webhook
When an email arrives, SendGrid POSTs multipart form data to your webhook URL. The key fields include:
- from: the sender's email address
- to: the recipient address at your domain
- subject: the email subject line
- text: the plain text body
- html: the HTML body (if present)
- attachments: the number of attachments
- attachment1, attachment2, etc.: the actual attachment files
Your application receives this data and can process it however you need: create a support ticket, trigger an automation, store the email in a database, or forward the parsed content to another service.
Using Inbound Parse With a Separate Email Provider
Most businesses that use SendGrid Inbound Parse also have a regular email provider (Google Workspace, Microsoft 365) for their team's day-to-day email. The cleanest setup is to use a subdomain for Inbound Parse.
For example:
yourdomain.comMX records point to Google Workspace (for regular team email)parse.yourdomain.comMX record points tomx.sendgrid.net(for programmatic processing)
This way, email to support@yourdomain.com goes to your team's inbox, while email to intake@parse.yourdomain.com gets processed by your application through the webhook.
SPF Record for SendGrid
If you are also sending email through SendGrid (not just receiving), make sure your SPF record includes SendGrid. Add include:sendgrid.net to your existing SPF TXT record:
v=spf1 include:_spf.google.com include:sendgrid.net ~all
SPF is about outbound sending authorization. It does not affect Inbound Parse, but if you use SendGrid for both sending and receiving, you need both the MX record (for inbound) and the SPF include (for outbound).
Check your SPF record at spfrecordcheck.com to make sure it is valid and includes all your sending services.
Common Mistakes to Avoid
Forgetting to remove old MX records. If you are adding the SendGrid MX record to your root domain and there are existing MX records from another provider, email delivery becomes unpredictable. Remove old records before adding new ones, unless you are intentionally using a subdomain.
Webhook URL is not publicly accessible. Your Destination URL must be reachable from the internet. If it is behind a firewall, on localhost, or requires authentication, SendGrid cannot deliver the parsed email. Test your endpoint independently before configuring Inbound Parse.
Not setting up the webhook at all. Adding the MX record without configuring Inbound Parse in SendGrid means email arrives at SendGrid's servers but has nowhere to go. It will be silently discarded. Always complete both the DNS step and the SendGrid configuration step.
Using Inbound Parse as a regular inbox. Inbound Parse is designed for programmatic processing, not for reading email. There is no inbox interface. If your team needs to read and respond to email, use Google Workspace, Microsoft 365, or another traditional email provider.
Not handling webhook failures. If your webhook endpoint goes down, SendGrid will retry delivery for a limited time. But if the endpoint stays down, emails are lost. Build reliability into your webhook: use a queue, log incoming requests, and monitor for failures.
Troubleshooting Inbound Parse
If email sent to your domain is not triggering your webhook, start with the basics:
- Check MX records at mxrecordchecker.com. If
mx.sendgrid.netdoes not appear, you have a DNS issue to fix first. - Check Inbound Parse settings in SendGrid. Make sure the domain matches exactly and the webhook URL is correct.
- Check your webhook endpoint directly by sending a test POST request to it. If it does not respond with a 200 status, SendGrid treats the delivery as failed.
- Check SendGrid's Activity Feed for any error messages related to inbound email processing.
If the MX record is correct and the Inbound Parse settings look right, the problem is almost always with the webhook endpoint: either it is unreachable, returning errors, or timing out.