SPF, DKIM, and DMARC setup for your email domain

You spun up a new domain, pointed the MX records, and sent your first test email. Gmail flagged it. Outlook bounced it. Yahoo quietly dropped it into nowhere.

The problem isn't your email content or your sending volume. It's authentication. Three DNS records tell receiving servers whether an email actually came from your domain: SPF, DKIM, and DMARC. Without all three in place, most providers will treat your messages as suspicious. Google and Yahoo tightened enforcement in early 2024, and the rules have only gotten stricter since. In 2026, unauthenticated mail from custom domains is essentially dead on arrival.

Here's what each record does, how to set them up, and where AI agents sending email tend to get tripped up. If you'd rather skip the DNS work and let your agent self-provision an inbox with authentication already handled, there's a faster path. But if you want to understand how email authentication works, keep reading.

What each record actually does#

These three records serve different roles, but they work as a system.

SPF (Sender Policy Framework) publishes a list of IP addresses authorized to send email from your domain. When a server receives a message claiming to be from yourdomain.com, it checks the SPF record to see if the sending IP is on the list.

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every outgoing email. The receiving server verifies this signature against a public key stored in your DNS. If the signature matches, the email hasn't been tampered with in transit.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together with a policy. It tells receiving servers what to do when authentication fails: do nothing, quarantine the message, or reject it outright. It also sends you reports showing who's sending email as your domain.

Think of it in layers. SPF says "these servers can send for us." DKIM says "this message really came from us." DMARC says "if a message fails both checks, here's what to do."

Setting up SPF#

SPF is the simplest of the three. You add a single TXT record to your domain's DNS zone:

v=spf1 include:_spf.google.com include:mail.yoursendingservice.com -all

Each include: directive authorizes a sending service. The -all at the end tells receivers to reject anything not covered by the listed sources. During initial testing, you can use ~all (softfail) instead, which marks failures rather than blocking them. Switch to -all once you've confirmed legitimate mail is passing.

SPF has a 10-DNS-lookup limit per evaluation. Each include: triggers at least one lookup, and nested includes count too. If you use Google Workspace plus a newsletter tool plus a transactional sender, you can hit this limit fast. Exceeding it causes SPF to return permerror, which most receivers treat as a fail. Flattening your SPF record or consolidating sending services helps keep the count manageable.

You can only publish one SPF TXT record per domain. If you need multiple include: directives, combine them into a single record. Publishing two separate SPF records is invalid and will cause unpredictable results.

Subdomains don't inherit SPF from the parent domain either. If you send from notifications.yourdomain.com, that subdomain needs its own SPF record.

Setting up DKIM#

DKIM requires coordination between your email provider and your DNS. The provider generates a cryptographic key pair, and you publish the public key as a TXT record.

The steps vary by provider. In Google Workspace, navigate to Admin > Apps > Gmail > Authenticate Email, generate the key, and copy the resulting DNS record. Most transactional email services (Postmark, Mailgun, SendGrid) surface the DKIM record during their onboarding flow.

The DNS record typically looks like this:

selector._domainkey.yourdomain.com  TXT  v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4...

The selector is a label your provider assigns (like google or s1). The p= value is the base64-encoded public key.

After publishing the record, send a test email and inspect the raw headers. You're looking for dkim=pass in the Authentication-Results header. If it shows dkim=fail or dkim=neutral, common causes include trailing whitespace in the DNS record, an incorrect selector name, or the key not matching what your provider generated.

One thing people miss: if you switch email providers, you need to update or add a new DKIM record for the new provider's selector. The old provider's key won't validate messages signed by the new one.

Setting up DMARC#

With SPF and DKIM in place, add your DMARC policy. This is a TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Start with p=none. This tells receivers to deliver messages normally regardless of authentication results, but send aggregate reports to the address you specify. These reports (delivered as XML files) show you which IPs are sending email as your domain and whether they're passing SPF and DKIM.

After two to four weeks of monitoring, tighten the policy:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com

The pct=25 applies the quarantine policy to 25% of failing messages. Increase it gradually (50%, 75%, 100%) as you verify legitimate mail isn't getting caught. The end goal is p=reject at full coverage, which blocks all unauthenticated messages entirely.

Don't skip the monitoring phase. I've seen setups where a forgotten marketing tool or a partner integration was sending legitimate email that hadn't been added to SPF. Jumping straight to p=reject killed those messages overnight.

Where agents run into trouble#

For a human developer, configuring these records is a one-time task. Set it up, verify it works, move on. For AI agents that need to send email autonomously, the picture changes.

Agents that self-provision email addresses need authentication to work from the first message. They can't wait weeks for DMARC reports, can't manually debug a DKIM selector mismatch, and can't log into a DNS dashboard to add TXT records.

The failure modes are predictable:

1. Agents spin up a new domain or subdomain and start sending before any DNS records exist. The domain's reputation collapses within days. Recovery takes much longer than setup would have. We covered this pattern in 5 agent email setup mistakes that tank your deliverability.
2. An agent integrating with multiple services stacks up include: directives past the 10-lookup limit. Every outbound message silently fails SPF validation from that point on, and there's no error loud enough for the agent to notice.
3. DMARC gets set to p=none during initial setup and stays there permanently because no one reviews the reports. The domain gets zero protection from spoofing.
4. DKIM keys that should be rotated every 6 to 12 months go unchanged for years. If a key is compromised, there's no automatic rotation to limit the damage.

If your agent triggers a 550 denied by policy response, missing or misconfigured authentication records are often the root cause.

Skipping DNS setup entirely#

If your agent needs a working inbox and you don't want to manage DNS records, managed email infrastructure handles this for you. LobsterMail, for example, ships with SPF, DKIM, and DMARC pre-configured on the @lobstermail.ai domain. Your agent pinches its own inbox and sends authenticated email from the first message, no DNS work required.

For agents that need a custom sending domain, the custom domains guide covers which records to add. But for prototyping, testing, or agents that don't need branded addresses, the default domain works out of the box.

When to set up your own records#

Managed infrastructure isn't always the right fit. If you're sending from your company domain (newsletters, transactional email, customer communication), you need to own those authentication records yourself. Same if you have specific compliance obligations or you're running high-volume campaigns where sender reputation requires careful management.

The deciding factor is usually who's sending. If a human team manages the email program from yourcompany.com, configure SPF, DKIM, and DMARC yourself. If an AI agent needs a working email address in under a minute, the overhead of manual DNS configuration for every new inbox is hard to justify.

Verification checklist#

After configuring all three records, verify the setup before sending real traffic:

1. Send a test email to a Gmail address. Open the message, click the three-dot menu, select "Show original." Look for spf=pass, dkim=pass, and dmarc=pass in the Authentication-Results header.
2. Use MXToolbox or dmarcian to validate your DNS records from the outside. These tools will flag issues like exceeding the SPF lookup limit or malformed DKIM keys.
3. Allow 24 to 48 hours for DNS propagation before assuming something is broken. Checking five minutes after publishing a record will usually show stale results.
4. Review your first batch of DMARC aggregate reports after about a week. If you see authentication failures from legitimate sending sources, update your SPF record to include them before tightening the policy.

If you add a new sending service or switch providers, update your SPF and DKIM records that same day. Even a brief gap in authentication can trigger spam filters, and recovering from a deliverability hit takes far longer than preventing one.