Resend SPF, DKIM & DMARC Setup: Stop Email Spoofing

Setting up SPF, DKIM, and DMARC for Resend takes three DNS records to get verified, and a fourth one that Resend does not add for you. When you verify a domain, Resend confirms you are passing SPF and DKIM [1]. It does not publish a DMARC record, and DMARC is the record that actually tells the world's mail servers to reject mail that forges your domain. Skip it and anyone can send email as you.

That gap is the whole point of this guide. Getting the green "Verified" badge in the Resend dashboard is deliverability. Publishing DMARC, rolling it from monitoring to enforcement, and protecting your root domain (not just your sending subdomain) is security. Most tutorials stop at the badge. This one keeps going.

TL;DR:

• A verified Resend domain means you already pass SPF and DKIM [1]. Resend does not set DMARC for you, so a fresh verified domain is still spoofable until you publish a DMARC record at _dmarc.
• Add DMARC as a TXT record and start with p=none; to monitor before enforcing, then move to quarantine and reject [1]. Rushing straight to reject can silently bounce your own legitimate mail.
• Publishing DMARC only on your send subdomain leaves your root domain and every other subdomain open. Set policy on the organizational domain and use the sp= tag to cover subdomains [6].
• Gmail and Yahoo now require SPF, DKIM, and a DMARC record (policy may be none) for bulk senders, plus From-header alignment [4]. Authentication is table stakes, not a nice-to-have.

Table of contents

• What do SPF, DKIM, and DMARC actually do?
• Which DNS records does Resend need?
• Why isn't a verified Resend domain enough?
• How do you roll out DMARC without breaking your email?
• Why protect your root domain, not just the send subdomain?
• What do Gmail and Yahoo require in 2026?
• Wire authentication in before your first send
• Common questions about Resend email authentication

What do SPF, DKIM, and DMARC actually do?

The three records answer three different questions. SPF says which servers are allowed to send mail for your domain. DKIM cryptographically signs each message so a receiver can confirm it was not altered and came from you. DMARC is the policy layer: it tells receivers what to do when a message fails both checks, and it ties the result back to the visible From address [5].

Think of them as a chain, not a menu. You do not pick one:

• SPF (Sender Policy Framework) is a DNS TXT record listing the servers permitted to send for your domain. A receiver checks the sending server's IP against that list.
• DKIM (DomainKeys Identified Mail) publishes a public key in DNS. Resend signs each outgoing message with the matching private key, and receivers verify the signature to confirm the body and headers were not tampered with.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email authentication protocol that instructs mail servers what to do if an email message fails SPF and DKIM, preventing email spoofing [1].

The critical detail is alignment. DMARC does not just ask "did SPF or DKIM pass." It asks whether the domain that passed matches the domain in the From header your recipient actually sees. A message must pass either SPF or DKIM (not necessarily both) to be DMARC-compliant, and it fails DMARC only when both fail [1]. That alignment check is what makes DMARC a real anti-spoofing control instead of a rubber stamp.

Which DNS records does Resend need?

Resend needs three records to verify a domain: an MX record and an SPF TXT record on your sending subdomain, plus a DKIM TXT record. Add them at your DNS provider, wait for propagation, and the domain flips to Verified. At that point you are passing SPF and DKIM [1]. The exact values are shown in your dashboard; copy them from there rather than hardcoding what you read in a guide.

Here is the shape of what Resend asks for (values differ by region and account, so treat this as the pattern, not gospel):

Type   Name                  Value                                   Priority
MX     send                  feedback-smtp.us-east-1.amazonses.com   10
TXT    send                  v=spf1 include:amazonses.com ~all
TXT    resend._domainkey     p=<your DKIM public key>

Three things worth understanding rather than pasting blindly:

• The MX record on send is not for receiving mail. It exists so recipients can send bounce and complaint feedback back to your domain [2]. That feedback loop is how your sender reputation stays measurable.
• The SPF record lives on a subdomain. Resend recommends sending from a subdomain like updates.example.com instead of your root domain, to isolate your sending reputation and clearly communicate your intent to recipients [2]. If a campaign ever tanks your reputation, it burns the subdomain, not your primary domain.
• DKIM uses the resend._domainkey selector. The selector is just the DNS label where the public key lives, which lets you rotate keys without disturbing other records.

One thing is conspicuously absent from that list: there is no DMARC record. Resend does not add one, and that is exactly where the security work starts.

Why isn't a verified Resend domain enough?

Because a verified domain proves your mail is authenticated, not that forged mail gets blocked. Passing SPF and DKIM tells a receiver "this message is genuinely from a server you authorized." It says nothing about what to do with a message that fails. Without a DMARC record, receivers have no published instruction, so spoofed mail claiming to be your domain often sails through to the inbox.

This is the difference between deliverability and security, and it is easy to conflate them. SPF and DKIM are largely about getting your real mail delivered. DMARC is about stopping mail that pretends to be you. A phisher does not need your Resend account to send billing@yourdomain.com password-reset lookalikes. They just need your domain to have no enforced DMARC policy, which by default it does not.

Resend is explicit that verification covers SPF and DKIM, and DMARC is a separate step you add through a TXT record at _dmarc [1]. That is not an oversight. DMARC enforcement can bounce legitimate mail if you turn it on before you understand every service sending as your domain (your CRM, your invoicing tool, your support desk). Resend leaves the policy call to you because only you know your full sending footprint. Publishing DMARC yourself is the deliberate, security-first step, and it is the same reason SecureStartKit ships the Resend client and a config.email.from address but cannot publish your DNS records for you: this lives in your registrar, not your codebase.

The related guide to sending emails in Next.js with React Email and Resend covers the sending side in full. This post is the authentication half that has to sit underneath it.

How do you roll out DMARC without breaking your email?

Roll it out in stages: publish p=none; first to monitor, read the reports, then tighten to quarantine and finally reject. Resend recommends starting with a policy of p=none; before moving to a stricter policy, so you do not accidentally introduce breaking changes to your email sending [1]. The none policy changes nothing about delivery. It just turns on reporting so you can see who is sending as your domain before you start blocking.

DMARC is a single TXT record at _dmarc.yourdomain.com. The three enforcement levels do exactly what their names suggest [1]:

• p=none; allows all email through and monitors for DMARC failures. This is your listening phase.
• p=quarantine; sends messages that fail DMARC to the spam folder.
• p=reject; bounces delivery of emails that fail DMARC outright.

Start here, at _dmarc, with a reporting address you actually monitor:

Type   Name      Value
TXT    _dmarc    v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

The rua tag is the reporting URI for aggregate reports: provide a valid address that can receive email [1]. You will get a daily XML file listing the IP sources sending as your domain and whether each passed SPF or DKIM [1]. Leave p=none running for a week or two, read those reports, and confirm every legitimate sender (Resend included) shows up passing alignment. Only once the reports are clean do you move to p=quarantine, watch for a few days, then p=reject. Rushing to reject on day one is the classic self-inflicted outage: you discover a forgotten sender by having its mail bounce in production.

Why protect your root domain, not just the send subdomain?

Because a DMARC record on your send subdomain protects only that subdomain. If you publish DMARC at _dmarc.send.yourdomain.com and nowhere else, an attacker can still spoof yourdomain.com itself, or billing.yourdomain.com, or any subdomain without its own record. The organizational domain is where the policy has to live, and the sp= tag is how you extend it downward.

DMARC has a subdomain policy tag, sp, defined as the policy for subdomains of the organizational domain [5]. RFC 7489 spells out the inheritance rule: the sp tag "applies only to subdomains of the domain queried and not to the domain itself," and "If absent, the policy specified by the 'p' tag MUST be applied for subdomains" [6]. In plain terms, a receiver evaluating mail from an unprotected subdomain falls back to your root domain's DMARC record. So the record you publish at _dmarc.yourdomain.com governs every subdomain that has not published its own.

That inheritance is a gift if you use it and a hole if you ignore it. Put your enforced policy on the root:

Type   Name      Value
TXT    _dmarc    v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@yourdomain.com

With p=reject; sp=reject, both your primary domain and every subdomain reject forged mail, whether or not each subdomain has its own record. If you deliberately want a looser policy on your sending subdomain during rollout, publish a dedicated DMARC record there, because the most specific record wins. But the default posture for a security-first setup is: enforce at the root, cover subdomains with sp, and open exceptions consciously rather than leaving them open by accident. Locking down your domain like this belongs on the same checklist as your other launch controls, which is exactly what the pre-launch security audit walks through.

What do Gmail and Yahoo require in 2026?

They require authenticated, aligned mail from anyone sending at volume. As of the bulk-sender rules that took effect in February 2024 and tightened since, senders of roughly 5,000 or more messages a day to Gmail accounts must set up SPF and DKIM, publish a DMARC record (the policy can be none), and pass From-header alignment [4]. Authentication moved from best practice to hard requirement.

Google's own sender guidelines are direct about the bar for bulk senders [4]:

• "Set up SPF and DKIM email authentication for your domain."
• "Set up DMARC email authentication for your sending domain. Your DMARC enforcement policy can be set to none."
• "For direct email, the domain in the sender's From: header must be aligned with either the SPF domain or the DKIM domain."
• "Keep spam rates reported in Postmaster Tools below 0.30%" (Google recommends staying under 0.10%).
• "Marketing messages and subscribed messages must support one-click unsubscribe, and include a clearly visible unsubscribe link in the message body."

Two takeaways for a Resend setup. First, even the minimum is a real DMARC record, so the _dmarc step is not optional even at p=none. Second, alignment is the requirement that catches people: SPF or DKIM passing is not enough on its own, the passing domain has to align with your visible From address. Sending from a properly verified Resend subdomain gives you aligned DKIM by default, which is why the subdomain-based setup above is the right foundation rather than a shortcut. If your app is below 5,000 messages a day today, you still want all of this in place before you cross that line, not scrambling after Gmail starts deferring your transactional mail.

Wire authentication in before your first send

The full setup is four records, not three: the MX, SPF, and DKIM that Resend verifies for you, plus the DMARC record that only you can publish. Get the domain verified so your real mail authenticates, then publish DMARC at your root domain, roll it from none to reject while reading the aggregate reports, and use sp= so no subdomain is left spoofable. That sequence is the difference between "our email lands" and "nobody can send email as us."

Do it before your first production send, not after a phishing report. Retrofitting DMARC enforcement on a live domain means discovering forgotten senders by watching their mail bounce, which is the worst possible time to learn your sending footprint. The same discipline runs through the rest of the stack: guard the credential that sends this mail with the zero-downtime API key rotation runbook, and if you would rather start from a codebase where the Resend client, validated inputs, and backend-only data access are already wired, that is the foundation the SecureStartKit template is built on.

Common questions about Resend email authentication

Does Resend set up DMARC for me? No. When you verify a domain, Resend confirms you are passing SPF and DKIM [1], but it does not publish a DMARC record. You add DMARC yourself as a TXT record at _dmarc [1]. This is deliberate: DMARC enforcement can bounce legitimate mail from other services sending as your domain, so the policy decision stays with you.

Do I need DMARC if I only send transactional email? Yes. Without a DMARC policy, anyone can spoof your domain in phishing mail, and transactional domains (password resets, receipts) are prime targets precisely because recipients trust them. Gmail and Yahoo also require a DMARC record for bulk senders, with the policy allowed to be none at minimum [4]. Even low-volume senders should publish it before scaling.

What DMARC policy should I start with? Start with p=none;. Resend recommends beginning with p=none; before moving to a stricter policy so you do not introduce breaking changes to your email sending [1]. Monitor the aggregate reports sent to your rua address [1], confirm all legitimate senders pass alignment, then move to quarantine and finally reject.

Should DMARC go on my domain or my sending subdomain? On your organizational (root) domain. Under RFC 7489, subdomains without their own DMARC record inherit the root domain's policy, and the sp tag lets you set the subdomain policy explicitly [6]. A record only on your send subdomain leaves the root domain and other subdomains spoofable.