Understanding DNS records
This reference explains how DNS records function within Braze across three primary email service providers (ESPs): SparkPost, SendGrid, and Amazon Simple Email Service (SES). Proper DNS configuration is essential for email authentication (SPF, DKIM, DMARC) and brand alignment, and directly impacts deliverability.
For more information, see Email authentication.
Core email authentication fundamentals
Before you review provider-specific structures, understand what these records do and how Braze uses them to achieve proper alignment.
Sender Policy Framework (SPF)
SPF is a DNS record on a domain that specifies which IP addresses are authorized to send email on behalf of that domain.
Braze does not ask you to modify or append SPF records on your corporate root domain (like, example.com). Instead, Braze isolates delivery by using a dedicated, custom Return-Path domain (also known as the bounce domain, MAIL FROM domain, or envelope From domain), such as bounce.mail.example.com.
Because receiving mailbox providers validate SPF against this Return-Path domain rather than the visible From: header domain, the SPF configuration lives entirely on the subdomain level. Depending on the underlying ESP, Braze handles this validation in one of two ways:
- CNAME delegation (SendGrid and SparkPost): Create a
CNAMEpointing your subdomain back to the ESP. The ESP hosts and updates the SPF policies on their infrastructure, passing the SPF check automatically. - Explicit TXT record (Amazon SES): Publish a hardcoded
TXTrecord directly on the bounce subdomain containing an explicit authorization string (for example,v=spf1 include:amazonses.com ~all), giving AWS permission to mail from that zone.
Domain Keys Identified Mail (DKIM)
DKIM adds a cryptographic digital signature to the email header. The receiving server uses the sender’s public key (published in DNS) to verify that the email originated from the domain owner and was not altered in transit.
Braze requires public DKIM keys to be published through TXT or CNAME records so that receiving ISPs can validate the cryptographic signatures generated by your ESP.
DMARC alignment
For an email to pass DMARC, the domain in the user-visible From: header must match (align) with the domain validated by either SPF (the Return-Path) or DKIM. Because Braze setups achieve alignment through both SPF and DKIM, your DMARC policies are safely satisfied.
Braze handles baseline SPF and DKIM authentication by default, but you still need to add a DMARC record to your sending domain. DMARC is an essential authentication tool required by almost all major inbox providers. It proves your emails are legitimate, builds up your domain reputation, and keeps your deliverability healthy over time.
Since this requires access to your company’s domain registry, you or your network administrator need to add this record at your root domain level. If you’re getting started, a basic policy like p=none satisfies the minimum inbox requirements. For more information about DMARC, see DMARC.org. For Braze-specific DMARC guidance, see Email authentication.
ESP-specific DNS architecture
Different ESP architectures handle DNS delegation differently. When provisioning your environment, use the exact records mapped to your specific ESP cluster.
SparkPost architecture
SparkPost uses a hybrid setup. It uses explicit CNAME records to point tracking and Return-Path infrastructure back to SparkPost while using a raw TXT record for DKIM authentication.
- SPF and Return-Path configuration: SparkPost requests a subdomain designated for bounces (for example,
mail.example.com). ACNAMErecord points this subdomain to SparkPost’s inbound bounce processors. This routes bounce traffic correctly and validates SPF automatically because SparkPost’s destination server manages the protocol. - DKIM configuration: SparkPost requires a
TXTrecord containing the exact public key string mapped to a specific selector. - Click and open tracking: Configure a tracking subdomain with a
CNAMEpointing to SparkPost tracking endpoints (or a CDN proxy if SSL tracking is requested).
Example SparkPost DNS table
The following table shows example DNS records for a SparkPost setup.
| Record type | Host/Name | Value/Target | Purpose |
|---|---|---|---|
| CNAME | mail.example.com | smtp.sparkpostmail.com | Return-Path / SPF alignment |
| TXT | scph1226._domainkey.mail.example.com | v=DKIM1; k=rsa; p=… | Cryptographic DKIM authentication |
| CNAME | click.mail.example.com | spgo.io (or CDN endpoint) | Click and open tracking |
SendGrid architecture
SendGrid relies on an automated infrastructure known as Domain Authentication. Instead of providing raw TXT keys, SendGrid provides a series of CNAME records that point directly to SendGrid-managed servers.
- SPF and Return-Path configuration: SendGrid uses a specific
CNAME(often prefixed withem) mapping your sending subdomain touXXXXXX.wl.sendgrid.net. SendGrid hosts and dynamically updates the SPF record on that endpoint. - DKIM configuration: SendGrid generates two separate
CNAMErecords for DKIM (often using selectors likes1ands2). These point back to SendGrid’s keys. - SendGrid provides two DKIM
CNAMErecords so it can rotate cryptographic keys automatically without requiring you to update your DNS manually.
Example SendGrid DNS table
The following table shows example DNS records for a SendGrid setup.
| Record type | Host/Name | Value/Target | Purpose |
|---|---|---|---|
| CNAME | em.mail.example.com | u123456.wl.sendgrid.net | Return-Path / dynamic SPF |
| CNAME | s1._domainkey.mail.example.com | s1.domainkey.u123456.wl.sendgrid.net | Primary DKIM key (rotational) |
| CNAME | s2._domainkey.mail.example.com | s2.domainkey.u123456.wl.sendgrid.net | Secondary DKIM key (rotational) |
| CNAME | email.mail.example.com | sendgrid.net (or CDN endpoint) | Click and open tracking |
Amazon SES architecture
Amazon SES uses Easy DKIM with CNAME records alongside explicit MX and TXT routing for customized bounce tracking.
- DKIM configuration: Amazon SES uses Easy DKIM, providing three
CNAMErecords. These point to AWS-managed subdomains containing the public keys. SES automatically rotates these keys transparently to maintain security compliance. - SPF and custom MAIL FROM configuration: SendGrid and SparkPost manage bounce domain routing through a
CNAME. Amazon SES requires an explicitMXrecord and aTXTrecord placed directly on the designated MAIL FROM subdomain. TheMXrecord ensures bounce notices return to Amazon’s servers, and theTXTrecord contains the authorized hardcoded SPF string.
For more information, see Amazon SES setup.
Example Amazon SES DNS table
The following table shows example DNS records for an Amazon SES setup.
| Record type | Host/Name | Value/Target | Purpose |
|---|---|---|---|
| CNAME | sel1._domainkey.mail.example.com | sel1.dkim.amazonses.com | Easy DKIM key 1 (rotational) |
| CNAME | sel2._domainkey.mail.example.com | sel2.dkim.amazonses.com | Easy DKIM key 2 (rotational) |
| CNAME | sel3._domainkey.mail.example.com | sel3.dkim.amazonses.com | Easy DKIM key 3 (rotational) |
| MX | bounce.mail.example.com | 10 feedback-smtp.us-east-1.amazonses.com | Routes bounce processing to AWS |
| TXT | bounce.mail.example.com | v=spf1 include:amazonses.com ~all | Explicit SPF authorization |
| CNAME | track.mail.example.com | r.us-east-1.awstrack.me (or CDN) | Click and open tracking |
Advanced DNS considerations
TXT DKIM record string splitting
When deploying SparkPost or manual DKIM setups, you may encounter long cryptographic keys (2048-bit DKIM keys).
The core DNS specification (RFC 1035) limits any single character string within a TXT record to a maximum of 255 characters. A 2048-bit public key routinely exceeds 400 characters, causing domain registries to reject the single string or truncate it, invalidating the signature.
String splitting solves this problem. Break the character string into chunks of fewer than 255 characters. Enclose each chunk in straight quotation marks, separated by a space, within the same TXT record.
When you use DNS providers like Cloudflare or AWS Route 53, these interfaces automatically handle the splitting when you paste a long string. Legacy systems (such as GoDaddy or Network Solutions) require you to manually format the split using the double-quotes technique.
Use dedicated subdomains
A common error during onboarding is requesting to use a top-level organizational domain (like example.com) directly in Braze as a sending domain. Braze requires the use of a dedicated subdomain (for example, mail.example.com or engage.example.com).
Using the parent domain can break corporate infrastructure in the following ways:
MX record conflicts
A domain can only support one set of primary routing MX records. If you map your parent domain (example.com) to Braze’s ESP infrastructure, the custom MX records required for bounces overwrite your corporate email records. This can disrupt corporate internal messaging platforms like Google Workspace or Microsoft 365.
SPF include bloat and the 10-lookup limit
The SPF specification (RFC 7208) limits receiving mail servers to a maximum of 10 DNS lookups when validating an SPF record.
- If a parent domain adds Braze’s ESP mechanisms (
include:sparkpostmail.comorinclude:amazonses.com), it counts heavily against that limit. - If the limit is exceeded, it triggers a permanent SPF PermError, causing all corporate emails to fail authentication.
IP and domain reputation isolation
If marketing campaigns, transactional receipts, and internal employee emails share an identical root domain space, a sudden spike in marketing spam complaints can damage the reputation of the parent domain. This risks routing critical corporate communications into spam folders. Using a distinct subdomain isolates the reputation of your marketing outreach.
Implementation workflow
To ensure a smooth handoff and implementation, follow this sequence:
- Provide the structured records to your IT or network administrator to add to your hosting platform (Cloudflare, Route 53, and so on).
- Set a low Time-To-Live (TTL) value (for example, 300 seconds or five minutes) for initial testing. This supports rapid recovery if a typo is made during entry.
- Run a DNS lookup (for example,
dig CNAME mail.example.com) or use a validation tool to confirm the records resolve correctly before passing to the warming phase.
DNS provider documentation
Every DNS provider has a unique interface. Share these specifications with your network administrator or refer to your specific provider’s documentation to map entries correctly into your zone file.
The following table lists official documentation for commonly used DNS providers.
| DNS provider | Resources |
|---|---|
| Cloudflare | Manage DNS records |
| Amazon Route 53 | Creating resource record sets |
| GoDaddy | Manage DNS records |
| Google Cloud DNS | Set up DNS records for a domain name |
| Microsoft Azure DNS | Manage DNS records using the Azure portal |
For additional domain provider resources, see Set up IPs and domains.