Add a New Email Sender to SPF and DKIM Without Breaking Email

You have connected a newsletter or transactional email tool to your domain, and now you have to edit DNS. This guide is for owners and the people who manage their domain. It shows how to add a new sender without breaking the email that already works, and without pushing SPF over its lookup limit.

In short: Add the DKIM records first. Touch your SPF record only if the provider's instructions require it, and keep it as one record under SPF's ten-lookup limit. Then test mail from the new sender and from every existing sender before you call it done.

Know the three "from" addresses

An email carries more than one sender identity, and mixing them up causes most of the confusion.

• Visible From: the address your customer sees. DMARC checks that the other two line up with this.
• Envelope sender (also called smtp.mailfrom or Return-Path): used between mail servers. SPF checks this, not the visible From.
• DKIM signing domain (d=): the domain whose published key signed the message.

DMARC passes when at least one of SPF or DKIM passes and its domain aligns with the visible From domain. So a message can show SPF pass and still fail DMARC, because the envelope sender was the provider's domain, not yours.

If you want the basics first, read SPF, DKIM and DMARC explained. The standards are RFC 7208 (SPF), RFC 6376 (DKIM) and RFC 9989 (DMARC), which replaces the older RFC 7489.

Do you need to change SPF at all?

Often, no. Many providers send with their own envelope sender domain, so their SPF record covers the mail. Your DKIM signature then gives the aligned DMARC pass.

You only need to edit your root SPF when the provider is set up to use your domain as the envelope sender, for example with a custom return-path or MAIL FROM setting. Services such as Mailchimp, Brevo, SendGrid and Amazon SES generally ask you to publish DKIM records, and some also offer a custom return-path or an SPF include. The exact names and values are generated for your account and can change, so copy them from the provider's current domain-authentication help page, not from an article.

Step 1: List what already sends as your domain

Before you edit anything, write down:

1. Every service that sends as your domain: mailbox provider, website contact forms, shop receipts, booking tools, CRM, helpdesk, invoicing, newsletters.
2. For each, the visible From, envelope sender and DKIM d= domain. Read these from the authentication results in the headers of a real message.
3. Your current SPF record (the TXT record starting v=spf1) and any existing DKIM records.
4. Who hosts your DNS. This is often not your registrar.

Copy the current values somewhere safe so you can roll back.

Step 2: Add DKIM first

New DKIM selectors normally sit alongside existing ones without trouble, so this is the low-risk step.

1. Open the domain authentication section in the sending service.
2. Copy the record names, types (TXT or CNAME) and values exactly as generated for your account.
3. Check how your DNS host handles names. Some add your domain automatically; if you also type it in full, you get selector._domainkey.yourbusiness.com.yourbusiness.com, a common cause of "not verified".
4. Make sure the selector name is not already in use by another sender.
5. Publish, then use the service's verify button. DNS changes can take time to appear, so retry later if it fails first time.

Watch out: Reusing a selector name, or adding a CNAME where a TXT record of the same name already exists, can break a sender that works today. Check before you save.

Step 3: Edit SPF carefully

Suppose your record is:

v=spf1 include:_spf.google.com ~all

and your provider tells you to add include:spf.provider.example (their real value will differ). The result is:

v=spf1 include:_spf.google.com include:spf.provider.example ~all

Before publishing, check these three things:

• One SPF record per name. Two v=spf1 records on the same name is an error. Merge them into one.
• Lookup count. Test the proposed record in an SPF checker and read the count.
• Ending. Keep whatever you have, ~all or -all. Don't tighten it in the same change.

-all gives fail for unlisted senders and ~all gives softfail. Receivers decide what to do with either, and an aligned DKIM pass can still satisfy DMARC. That is why DKIM goes in first.

The ten-lookup limit

SPF allows at most ten DNS-querying terms in a single evaluation. These are include, a, mx, ptr, exists and the redirect modifier, and terms inside nested includes count too. The terms ip4, ip6 and all cost nothing.

Go over ten and the result is permerror, which receivers may treat as an SPF failure. You can reach the limit without noticing, because one include: can pull in several more.

Step 4: If you are near the limit

Remove senders you no longer use

Every dead include: still costs a lookup. Confirm a service is truly retired before you remove it. Cutting a service that still uses your domain as its envelope sender can make its mail fail SPF, and DMARC then depends on whether it also signs with aligned DKIM.

Give the new stream a subdomain

If the provider supports it, send newsletters from a subdomain such as news.yourbusiness.com, with the visible From on that subdomain so DMARC aligns. The subdomain gets its own SPF record and its own ten-lookup budget. A root SPF record does not cover subdomains, so each name needs its own.

Your root domain's DMARC policy also applies to subdomains unless a subdomain has its own DMARC record or your root record has an sp tag that says otherwise (RFC 9989). With the default relaxed alignment, a DKIM signature from news.yourbusiness.com can also align with a From address on yourbusiness.com.

Treat flattening with caution

Some DNS tools replace include: chains with fixed IP ranges to cut the lookup count. Providers change their IPs, so a stale flattened record can start failing real mail. Use it only if the tool refreshes automatically, and check it now and then.

Step 5: Test from the receiver's side

Send a real message from the new service to a mailbox you control. Open its original source or "show original" view, find the Authentication-Results line and check:

• SPF: pass, with smtp.mailfrom on a domain you expect.
• DKIM: pass, with d= set to your domain or subdomain, not the provider's shared domain.
• DMARC: pass.

Check: Now send a test from each existing sender and confirm nothing has changed. Breaking old mail is the usual way this job goes wrong.

Forwarding can break SPF, because the forwarder's IP isn't in your record. Aligned DKIM is what usually keeps DMARC passing in that case. If you receive DMARC aggregate reports, the new sender should appear in them over the following days; see DMARC reports: moving safely from p=none to p=reject.

A sensible layout for a small business

This is an illustration. Your providers' documentation decides the real names and whether SPF changes are needed.

If you use Google Workspace for everyday mail, SPF, DKIM and DMARC Setup for Google Workspace covers that part. To see what your domain publishes right now, the free DMARC & SPF checker at lordevo.com/tools shows your current records before you change anything.

Key takeaways

• List every sender, and save your current DNS values, before you edit.
• Add DKIM first; check the selector name isn't already taken.
• Edit SPF only if the provider requires it, and keep to one v=spf1 record under ten lookups.
• Don't change ~all to -all in the same edit as adding a sender.
• Test the new sender and every existing sender, and read the headers.

FAQ

Do SPF, DKIM and DMARC get my newsletters into the inbox?

No. They help receivers verify that mail really comes from you. Inbox placement also depends on content, list quality and sending reputation.

Can I have two SPF records if I have two services?

No. Combine them into a single v=spf1 record.

Why does DMARC fail when SPF says pass?

SPF passed for a different domain from the visible From, so it isn't aligned. Fix this with aligned DKIM, or a custom envelope sender on your domain if the provider offers it.