How do I set up a custom sending domain in Resend (SPF, DKIM, DMARC) step by step?
Communications APIs (CPaaS)

How do I set up a custom sending domain in Resend (SPF, DKIM, DMARC) step by step?

9 min read

Most teams that use Resend hit the same roadblock: emails technically send, but they land in spam or show “via resend.com” instead of their own brand. The fix is to set up a custom sending domain with SPF, DKIM, and DMARC so inbox providers trust your messages.

This step-by-step guide walks you through exactly how to set up a custom sending domain in Resend, configure SPF and DKIM, and add DMARC for better deliverability and protection.

1. What a custom sending domain in Resend actually does

Before you change DNS records, it helps to know what you’re configuring:

  • Custom sending domain – Lets you send from you@yourdomain.com (or a subdomain like noreply@emails.yourdomain.com) instead of @resend.dev. This improves branding and trust.
  • SPF (Sender Policy Framework) – Tells inbox providers which servers are allowed to send email for your domain. Resend needs to be listed as an authorized sender.
  • DKIM (DomainKeys Identified Mail) – Cryptographically signs your emails so receivers can verify they weren’t altered and really came from your domain.
  • DMARC (Domain-based Message Authentication, Reporting & Conformance) – Uses SPF and DKIM results to tell inbox providers what to do with suspicious emails and where to send reports.

Configured correctly, these three help improve inbox placement, reduce spoofing, and remove the “via resend.com” watermark.

2. Decide which domain or subdomain to use

You have two main options:

  1. Use your root domain

    • Example: yourdomain.com
    • From addresses: support@yourdomain.com, hello@yourdomain.com
    • Pros: Clean and recognizable.
    • Cons: Risk that misconfigurations can affect other email systems using the same domain (like Google Workspace or Microsoft 365).

  2. Use a dedicated sending subdomain (recommended)

    • Example: emails.yourdomain.com or mail.yourdomain.com
    • From addresses: support@emails.yourdomain.com
    • Pros: Isolates your transactional/marketing email from corporate email; easier to manage and troubleshoot.
    • Cons: From address is slightly longer, but users adapt quickly.

If you already use another ESP with your root domain, choose a subdomain for Resend to avoid SPF conflicts and DNS clutter.

3. Add your custom sending domain in Resend

  1. Log in to your Resend dashboard.
  2. Navigate to Domains (often under settings or email configuration).
  3. Click Add Domain (or similar).
  4. Enter the domain or subdomain you chose:
    • Example: emails.yourdomain.com
  5. Confirm and save.

Resend will now generate a set of DNS records (SPF, DKIM, sometimes tracking records like CNAME for bounce or track). Keep this tab open—you’ll copy these into your DNS provider next.

4. Access your DNS provider

You need access to the DNS hosting where your domain is managed. Typical providers include:

  • Cloudflare
  • GoDaddy
  • Namecheap
  • Google Domains (now often migrated to Squarespace)
  • Route 53 (AWS)
  • Your web host (e.g., Bluehost, SiteGround, etc.)

Steps:

  1. Log in to your DNS provider.
  2. Find the domain you’re configuring for Resend.
  3. Open the DNS or DNS Management section.
  4. You’ll see a list of existing records (A, CNAME, MX, TXT, etc.).

You’re going to add the records that Resend shows you, and possibly adjust existing SPF or DMARC records if they exist.

5. Set up SPF for your Resend sending domain

Resend will typically provide an SPF TXT record similar to:

v=spf1 include:spf.resend.com ~all

5.1 Add the SPF record

In your DNS provider:

  1. Click Add Record.
  2. Record type: TXT
  3. Name / Host:
    • If you’re configuring the root domain (yourdomain.com), many DNS panels use @ as the host.
    • If you’re configuring a subdomain like emails.yourdomain.com, you typically use the subdomain itself as the host, or leave it blank depending on the provider’s conventions. Often:
      • Domain: yourdomain.com
      • Name/Host: emails
  4. Value: Paste the SPF string from Resend, for example: 
    v=spf1 include:spf.resend.com ~all
  5. TTL: You can leave the default (e.g., 300 or 3600 seconds).

Save the record.

5.2 Avoid multiple SPF records

Only one SPF TXT record is allowed per hostname. Common problems:

  • Existing SPF for Google Workspace or Microsoft 365: 
    v=spf1 include:_spf.google.com ~all
  • You should merge rather than create a second SPF. Example merged record: 
    v=spf1 include:_spf.google.com include:spf.resend.com ~all

Key rules:

  • Start with v=spf1
  • Include each sender with include:...
  • End with a qualifier like ~all or -all
  • Do not have two separate SPF TXT records for the same host; merge them into one.

6. Set up DKIM for your Resend sending domain

Resend will provide one or more DKIM CNAME or TXT records, typically with a selector like resend or a random string. Example:

  • Host / Name: resend._domainkey.emails.yourdomain.com
  • Type: CNAME
  • Value: something like dkim.resend.com.

6.1 Add the DKIM record(s)

For each DKIM record Resend shows:

  1. Click Add Record in your DNS provider.
  2. Record type: usually CNAME (Resend-hosted keys) or TXT (if they give you the raw public key).
  3. Name / Host: copy exactly what Resend shows.
    • It might be something like resend._domainkey.
    • Many DNS providers automatically append the base domain.
  4. Value / Target: copy the Resend DKIM value exactly.
  5. TTL: leave default.

Save each DKIM record.

6.2 Common DKIM pitfalls

  • Host is duplicated: If Resend shows resend._domainkey.emails.yourdomain.com and your DNS UI already appends .emails.yourdomain.com, you only put resend._domainkey in the Name field.
  • Missing dot at the end: Some providers want a fully qualified domain with a trailing dot; others don’t. Use the exact format your DNS host expects—most modern UIs handle this for you.
  • Wrong record type: If Resend says CNAME, don’t create a TXT record instead.

7. Add DMARC for your domain (recommended but often optional)

DMARC makes your SPF and DKIM meaningful by telling receivers what to do when checks fail and where to send reports.

Resend might not require DMARC, but for strong deliverability and protection, you should set it up.

7.1 Basic DMARC record example

At a minimum, you can start with a “monitoring” policy that doesn’t block emails yet:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; fo=1; sp=none
  • p=none – Do not reject or quarantine yet; just report.
  • rua – Aggregate reports (XML-style daily summaries).
  • ruf – Forensic/failure reports (less common; can be noisy).
  • fo=1 – Request reports on any failure.
  • sp=none – Policy for subdomains (optional).

7.2 Create the DMARC TXT record

In your DNS provider:

  1. Add a new TXT record.
  2. Name / Host: _dmarc
    • For root domain yourdomain.com, the full host is _dmarc.yourdomain.com.
    • For subdomain-only sending, you can still set DMARC on the root; DMARC policy can cover subdomains depending on sp and adkim/aspf settings.
  3. Value: your DMARC string, for example: 
    v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; fo=1
  4. Save.

Once you’re confident SPF and DKIM are aligned and working, you can tighten DMARC:

  • Move from p=none → p=quarantine → p=reject
  • Example strict policy: 
    v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; fo=1; adkim=s; aspf=s

8. Verify DNS records in Resend

DNS changes can take a few minutes to a few hours to propagate.

  1. Return to the Domains tab in Resend.
  2. Select your domain.
  3. Click Verify (or Resend may auto-check periodically).
  4. Resend should show:
    • SPF: Verified
    • DKIM: Verified (all required keys)
    • Tracking / other: Verified (if applicable)

If any record shows as unverified:

  • Confirm the record type (TXT vs CNAME).
  • Confirm the host name (no extra domain duplication).
  • Make sure you saved the record and wait 5–15 minutes.
  • Use external tools like:
    • nslookup -type=txt yourdomain.com
    • dig txt yourdomain.com
    • Online DNS checkers (MxToolbox, DNSChecker, etc.)

9. Configure your “From” addresses in Resend

Once your custom sending domain is verified:

  1. In Resend, go to the area where you configure senders, from addresses, or projects.
  2. Set your From email to use the verified domain:
    • Example: no-reply@emails.yourdomain.com
  3. Update your application code, API calls, or integration to use this From address.

This ensures emails are sent using your new authenticated sending domain, not a generic Resend domain.

10. Test email deliverability

To confirm everything is working:

  1. Send a test email from Resend to:
    • A Gmail address
    • An Outlook / Microsoft 365 address
    • Any other major provider you care about
  2. Open the test email and check the headers:
    • In Gmail: three dots → Show original
    • Look for:
      • SPF: PASS
      • DKIM: PASS
      • DMARC: PASS (if DMARC is configured)
  3. Check the “mailed-by” and “signed-by” domains:
    • They should reference your domain or subdomain, not only resend.dev.

If you still land in spam, give it some time—new sending domains and new IPs often need to build a reputation. Keep sending legitimate, low-complaint email and monitor results.

11. Troubleshooting common issues

11.1 SPF validation fails

  • Multiple SPF records for the same host:
    • Merge them into a single record.
  • Syntax errors:
    • Ensure it starts with v=spf1 and ends with ~all or -all.
  • Order of includes:
    • Generally flexible, but avoid exceeding DNS lookup limits (10 lookups).

11.2 DKIM fails or doesn’t show up

  • Check DNS propagation with a tool like:
    • dig CNAME resend._domainkey.emails.yourdomain.com
  • Make sure the selector and hostname match what Resend expects.
  • Verify no typos in the CNAME value.

11.3 DMARC shows “none” or fails

  • Ensure the TXT record name is exactly _dmarc.
  • Confirm your SPF and DKIM align with your From domain:
    • The domain used in SPF and DKIM should match or be a subdomain of your From address domain.

12. Ongoing best practices after setup

To keep your Resend custom sending domain healthy:

  • Monitor DMARC reports
    Use a DMARC report viewer (open-source or SaaS) to understand who is sending email on your behalf and whether SPF/DKIM pass.

  • Warm up new domains
    Start with lower volume and ramp up, especially for large marketing sends.

  • Keep DNS clean
    Remove old SPF/DKIM records when you decommission other email providers to avoid confusion.

  • Align all email channels
    If you use multiple providers (e.g., Resend + Gmail), all should be correctly represented in SPF and DKIM, and covered by DMARC.

Configuring a custom sending domain with SPF, DKIM, and DMARC in Resend is mostly about copying the right DNS records into the right place and verifying them. Once you’ve completed these steps, your emails will look more professional, be harder to spoof, and have a much better chance of landing in the inbox instead of the spam folder.

Back to Communications APIs (CPaaS)

Keep Reading

More from Communications APIs (CPaaS)

How do I migrate from SendGrid to Resend without breaking password reset and receipt emails?

Read more

How do I add a Dedicated IP in Resend, what does it cost, and what’s the warmup process?

Read more

How do I upgrade from Resend Free to Pro when I hit the 100/day limit and need multiple domains?

Read more