iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To authenticate SaaS email sent through Resend, add your sending domain in Resend, publish the exact SPF and DKIM records shown for that domain in its authoritative DNS zone, and create a DMARC policy at _dmarc. Then verify the domain and inspect delivered messages for authentication and From-domain alignment. Authentication proves that a message is authorized; it does not by itself guarantee inbox placement.
What SPF, DKIM and DMARC each do
These standards solve different parts of the receiving server’s decision. SPF checks whether the server that delivered a message is authorized by the envelope domain’s DNS policy. DKIM checks a cryptographic signature on the message. DMARC tells receivers what to do when authentication fails and where to send aggregate or forensic reports.
SPF authorizes sending infrastructure
An SPF TXT record lists the services allowed to send mail for one domain. A domain or subdomain can have only one effective SPF policy. If your SaaS also sends through a support desk, billing system or another provider, merge every authorized mechanism into that single policy. Publishing two SPF records creates a permerror rather than authorizing both services.
Recommended Free Tools
An apex-domain policy does not automatically cover a subdomain. If your application sends from mail.example.com, check whether that subdomain needs its own SPF record. The exact include mechanism and other values must come from each provider’s current documentation or dashboard.
DKIM authenticates a signed message
DKIM adds a signature to outgoing mail. The receiving system looks up the public key at the selector and domain named in the signature, then verifies that the signed content was not altered. Providers can use different selectors and may require more than one DNS record. Resend supplies domain-specific DKIM details; use those values rather than an example from a guide.
DMARC applies policy and alignment
DMARC is published as a TXT record at _dmarc for the domain being protected. A message passes DMARC when either SPF or DKIM passes and its authenticated domain aligns with the visible From: domain. DMARC also carries reporting instructions and a policy for mail that fails alignment.
Read the DNS records as an ownership map
The owner name, record type and value all matter. A record at the apex domain is different from one at a sending subdomain, and a DKIM selector creates a more specific owner name than the base domain. DNS control may be split across a registrar, a managed DNS service and infrastructure-as-code; identify the authoritative nameservers before making a change. The provider where you purchased the domain is not necessarily the provider that answers DNS queries.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Many DNS consoles ask for a relative host label and append the zone automatically. If the console expects selector._domainkey, entering the full name can create an unintended duplicate such as selector._domainkey.example.com.example.com. Conversely, omitting a required label can publish the record at the wrong level. Compare the final owner name returned by the authoritative nameserver with the name shown in Resend.
Keep a record inventory for every sending identity: SPF owner, DKIM selector, DMARC owner, return-path subdomain, TTL and responsible team. This makes selector rotation, vendor removal and incident rollback safer than relying on a screenshot of a dashboard.
Before you add anything: choose the sending identity
Decide which domain or subdomain will appear in the From address and which streams it will send. Product notifications, password resets and newsletters can share a domain, but separating streams can make ownership, monitoring and reputation incidents easier to manage. Resend recommends subdomains for purpose-based separation; treat that as operational guidance, not a guarantee that reputation spillover will be prevented.
Rank #2
Separate streams when the trade-off is worthwhile
| Design | Operational isolation | DNS and monitoring effort | When it fits |
|---|---|---|---|
| One domain for every stream | Lowest; a problem in one stream can affect the others | Lowest | Small systems with one consistent sending purpose |
| Separate subdomains by purpose | Clearer ownership and potentially better containment of a stream’s reputation | Higher; each identity needs records, dashboards and report review | Products with distinct transactional and subscription or marketing mail |
| Separate domains | Strongest administrative separation | Highest; each domain needs authentication, alignment and monitoring | Independent brands or teams with genuinely different identities |
Whichever design you choose, keep the visible From identity stable for each stream. Alignment and recipient recognition are harder when addresses change unexpectedly.
Free tools Windows power users keep installed
One-click scans. No signup required.
Step-by-step: authenticate a domain in Resend
- Confirm DNS authority. Identify the DNS provider that is authoritative for the chosen domain. The place where you bought the domain may not be the place hosting its nameservers. Only the authoritative zone can publish records that receivers will use.
- Add the domain in Resend. In the Resend dashboard, open the domains area, add the exact domain or subdomain used by your From address, and submit it for verification. The labels can change, so follow the current dashboard path.
- Copy the account-specific records. Resend displays the record names, types and values for that domain. Copy its SPF and DKIM records exactly, including selector names, hostnames and punctuation. Do not copy values from a tutorial or another Resend account.
- Inspect your existing SPF first. Search the authoritative zone for TXT records at the domain and identify the one beginning with
v=spf1. If another service already sends for the same domain, add Resend’s authorization to that policy according to the provider’s instructions. Do not create a second SPF TXT record. - Publish SPF and DKIM. In your DNS provider, create or edit the records using the hostnames and values Resend supplied. DNS interfaces often append the zone name automatically; entering the full name when the interface expects only a relative label can produce a wrong owner name. Preserve the DKIM selector exactly.
- Create a DMARC record. Add one TXT record with owner name
_dmarc(or the relative label your DNS interface requires). Start with a monitoring policy while you inventory senders and review reports. A clearly marked illustrative form isv=DMARC1; p=none; rua=mailto:dmarc@example.com; replace the reporting address and policy with values appropriate to your domain. This example is not a production record to copy unchanged. - Wait for DNS visibility. DNS caching means Resend may not see a new record immediately. Verification timing depends on your provider’s TTL and resolver caches. If a record remains pending, query the authoritative nameservers and compare the result character-for-character with the Resend dashboard.
- Verify in Resend. Return to the domain page and run its verification action. A successful status confirms that Resend can find the expected records; it does not prove that every message will align or reach the inbox.
- Send a representative message. Use the same From domain and stream that production traffic will use. Inspect the received message’s authentication results for SPF, DKIM and DMARC, and check which domain passed and whether it aligned with the visible From domain.
Use a controlled verification message
Test more than a single dashboard status. Send a password-reset or other representative transactional message to a mailbox you control, then inspect the complete headers. Confirm the envelope or return-path domain used for SPF, the DKIM signing domain and selector, and the visible From domain. A pass on SPF or DKIM is not enough if the authenticated domain differs from the From domain and DMARC therefore fails alignment.
Repeat the test for every configured stream and for any custom return path. Keep the message content, From address and sending path close to production conditions; a test sent from a different subdomain can hide a missing record on the real stream.
How to choose a DMARC policy
DMARC enforcement is a staged decision, not a switch to flip before you know every legitimate sender. The policy controls treatment of messages that fail DMARC alignment; it does not replace SPF or DKIM.
| Policy | Receiver request | Best use | Risk |
|---|---|---|---|
p=none |
Deliver normally while sending reports | Inventorying senders, correcting alignment and establishing a baseline | Unauthenticated spoofed mail is not requested to be filtered |
p=quarantine |
Treat failing mail as suspicious, commonly sending it to spam | Staged enforcement after legitimate sources are understood | Misconfigured legitimate mail may be filtered |
p=reject |
Reject failing mail | Strong enforcement after testing every sender and workflow | Forgotten vendors or legacy systems can lose delivery |
Review aggregate reports from the address in rua and identify every source that sends as the protected domain. Correct SPF scope, DKIM signing and alignment before increasing enforcement. A policy of none can still provide valuable visibility; it is not an authentication substitute.
A practical rollout has three checkpoints. First, publish p=none and collect reports while listing product mail, support tools, billing systems and any legacy application that uses the domain. Second, fix unknown sources, add missing SPF authorization or DKIM signing, and verify that each legitimate source aligns with the From domain. Third, move to quarantine and eventually reject only after report data and representative tests show that expected workflows continue to authenticate. Document who approves each policy change and how to reverse it if a forgotten sender appears.
Gmail requirements for SaaS senders
Google’s sender guidance applies here specifically to mail delivered to personal Gmail accounts. All senders must set up SPF or DKIM. A sender that exceeds 5,000 messages in a day to Gmail accounts must set up both SPF and DKIM and publish DMARC; Google allows the DMARC policy to be p=none. For direct mail from those bulk senders, the domain in the From header must align with either SPF or DKIM.
Bulk marketing and subscribed messages also need one-click unsubscribe and a clearly visible unsubscribe link. Google lists additional requirements, including TLS, valid forward and reverse DNS, correctly formatted messages and a spam-rate target. Gmail Postmaster Tools identifies a 0.3% spam-rate ceiling in its sender guidance. These are receiver requirements, not settings that Resend can switch on for you.
The 5,000-message threshold is per day to Gmail accounts, not a promise that lower-volume traffic is exempt from good sending practice. If your volume approaches that level, inventory Gmail traffic separately, verify the From-domain alignment of direct mail, and implement unsubscribe handling before the threshold is crossed. Keep transactional messages distinct from subscription or marketing mail so that consent and suppression behavior can be audited.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Resend’s role: DNS authentication versus sending code
DNS and domain layer
Resend generates the SPF and DKIM records for the domain you add. You remain responsible for publishing them in the authoritative DNS zone, maintaining a single coherent SPF policy and completing verification. Resend also documents a configurable custom return-path subdomain. That return path can support SPF authentication, DMARC alignment and bounce handling; configure it through the current dashboard or API instructions. A cited changelog described a default of send, but confirm the current default in your account before relying on it.
Application and API layer
After the domain is verified, your application still has to call Resend’s sending API or SDK with a valid From address, recipients, subject and content. The material available for this guide does not establish current SDK method names or API parameters, so use the versioned official Resend API and SDK documentation when implementing code. Authentication records cannot compensate for an invalid request, an incorrect From address or an application that sends to people without permission.
Treat domain verification as a prerequisite in deployment automation. Store the verified From identities and stream ownership in configuration, but do not hard-code DNS values from an old setup. When a domain, selector or return path changes, update DNS, wait for visibility, send a representative test and only then switch application traffic.
Authentication is not inbox placement
SPF, DKIM and DMARC establish authorization and alignment. They do not promise that Gmail or another provider will place a message in the inbox. Recipient engagement, complaint rates, content, sending volume, list hygiene, infrastructure reputation and whether the mail was wanted all influence filtering.
Resend requires opt-in recipients and applies additional conditions to bulk mail. Obtain consent appropriate to the message type, suppress hard bounces and unsubscribes promptly, and avoid importing lists whose recipients did not ask for your messages. For subscription or marketing streams, implement the unsubscribe requirements before scaling volume.
Authentication troubleshooting and placement troubleshooting should therefore be separate work queues. First confirm the headers show the expected SPF or DKIM result and DMARC alignment. If those pass, investigate recipient complaints, sudden volume changes, stale addresses, content expectations and unsubscribe behavior rather than repeatedly editing DNS.
Troubleshooting common verification failures
Resend reports an SPF error
- Confirm there is only one SPF policy at the exact sending domain.
- Merge authorized senders instead of adding a second
v=spf1TXT record. - Check whether the message uses a subdomain whose SPF policy was never published.
- Verify that your DNS provider did not add quotation marks, line breaks or an extra zone name incorrectly.
DKIM is still pending
- Compare the selector and owner name in DNS with the selector Resend displays.
- Query the authoritative nameserver, not only a local cache.
- Check that a CNAME was not entered as a TXT record, or vice versa, when Resend specifies a particular type.
- Allow for TTL and resolver caching before repeatedly changing the record.
DMARC fails even though SPF or DKIM passes
- Read the authenticated domain in the message’s results, not just the word “pass.”
- Compare that domain with the visible From domain. DMARC requires alignment.
- Check whether a custom return path or a DKIM signing domain changed after you configured DNS.
- Review every service that sends with the protected From domain and add or align it before enforcing quarantine or reject.
Mail authenticates but lands in spam
- Separate authentication from placement: a pass result does not override recipient complaints or unwanted mail.
- Check consent, unsubscribe handling, bounce suppression and sudden volume changes.
- Review Gmail Postmaster Tools data when you send at qualifying volume and keep the spam rate below Google’s stated threshold.
- Inspect the actual delivered message, including headers and content, rather than relying only on the Resend domain status.
Operational checklist before production
- The From domain and any return-path domain are documented for each message stream.
- Resend’s current SPF and DKIM values, not copied examples, are published in authoritative DNS.
- There is one SPF policy per domain, containing every legitimate sender.
- DMARC is published at the correct
_dmarcowner name with a monitored reporting address. - At least one real message shows SPF or DKIM passing with alignment to the visible From domain.
- Every sender discovered in DMARC reports has an owner and a documented purpose.
- Transactional and subscription mail follow separate consent, suppression and unsubscribe rules where applicable.
- DNS changes, selector rotations and policy changes are recorded so an incident can be reversed safely.
- Gmail-bound volume is tracked so the 5,000-message daily threshold is visible before it is exceeded.
- Bulk streams have one-click unsubscribe and a clearly visible unsubscribe link where Google’s rules apply.
Answers to the practical setup questions
How do I set up SPF, DKIM and DMARC for my domain?
Add the domain in Resend, publish its account-specific SPF and DKIM records in authoritative DNS, consolidate SPF with your other senders, then add a DMARC TXT record at _dmarc and begin with monitoring while you verify alignment.
How do I verify my domain in Resend?
Use the domain’s verification action in the current Resend dashboard after publishing the displayed records. If it fails, compare DNS at the authoritative nameserver with the exact names and values shown for your account.
Does Resend handle SPF and DKIM?
Resend supplies the domain-specific SPF and DKIM records and checks them, but you must publish and maintain those records in your DNS. Resend does not control your DNS zone.
Do I need DMARC if I use Resend?
DMARC is independent of the provider. It is required for senders exceeding 5,000 daily messages to Gmail accounts and is useful for policy, reporting and alignment at any scale. Using Resend does not publish DMARC for your domain automatically.
Will SPF, DKIM and DMARC keep email out of spam?
No. They provide authentication and alignment, while inbox placement also depends on wanted mail, consent, complaints, bounces, content, volume and receiver-specific requirements.
Frequently Asked Questions
Can I publish two SPF records to support Resend and another provider?
No. Keep one SPF policy for each domain or subdomain and merge every legitimate sending mechanism into it. Two separate v=spf1 records can produce a permerror.
Does an SPF record on my root domain cover a sending subdomain?
Not automatically. A subdomain such as mail.example.com may need its own SPF policy, depending on the envelope domain used by the message and the provider’s instructions.
What should I do if Resend verification stays pending?
Query the authoritative nameservers, compare the owner name, type and value with the current Resend dashboard, check for an accidentally duplicated zone name, and allow for TTL and resolver caching.
Should I start DMARC with quarantine or reject?
Start with p=none while you inventory every legitimate sender and review reports. Move to quarantine and then reject only after SPF, DKIM and From-domain alignment are confirmed for all expected workflows.
What does a custom return path change?
Resend’s configurable return-path subdomain can support SPF authentication, DMARC alignment and bounce handling. Follow the current dashboard or API instructions and verify the actual return-path domain in a delivered message.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWhat extra steps apply to bulk Gmail mail?
Senders exceeding 5,000 messages per day to Gmail accounts need SPF, DKIM and DMARC, with the From domain aligned to SPF or DKIM for direct mail. Marketing and subscribed mail also need one-click unsubscribe and a visible unsubscribe link.
The Bottom Line
Use Resend to obtain account-specific SPF and DKIM records, publish them in the authoritative DNS zone, and add DMARC at _dmarc with a staged policy. Verify real message headers and From-domain alignment, then manage consent, unsubscribe handling, bounces and volume separately from DNS authentication. This combination meets the foundation of Gmail’s sender expectations without promising inbox placement.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
