yodai Academy Domain and email

Academy › Publishing › Domain and email

Why you can't use the same signature for everything you send

You'll know how to identify every service that sends email on your behalf, give each one its own signature without touching the others, and keep a single SPF record that brings them all together.

By Yodai · Published on September 6, 2026 · Updated on October 12, 2026

5 min read

The fact that your SPF gives permission to your booking confirmations and your invoices doesn't decide who signs each email. You set up your domain so emails from your regular inbox would land fine, and it works: the estimate you send through Gmail doesn't end up in spam. Months later you connect a booking system that sends appointment confirmations in your name, and those get lost half the time. You check the domain settings and nothing looks off. The problem isn't in what you see: it's that you let the booking system ride on the same signature you already had active for your regular email, assuming one signature was enough for everything leaving your domain.

Something similar happens with SPF permissions: the one that works for your website's contact form doesn't cover your invoicing tool. With the signature, the rule is even stricter: every tool that sends email in your name needs its own signature, not someone else's.

Each sender signs with its own key

Signing an email with DKIM is like stamping a seal inside the message that only the key holder can add, and every tool that sends email has its own key, not yours. When you turn on DKIM for your regular inbox, that inbox gets a private key nobody else knows, and you leave the public half in your domain so anyone can check that the seal is genuine.

If a booking system later sends an email claiming to come from your domain but signs it with a key whose public half you never added to your domain, whoever receives the email checks the seal and it doesn't match. It's not a connection glitch or a content issue: that particular sender was simply never authorized to sign in your name.

Share the signature or turn on one per service
Copying or sharing another service's signature
  • It seems faster: no need to go back into the DNS
  • It works as long as only the first service is sending
  • As soon as the second service sends something, the key doesn't match and it gets penalized
  • If you stop using one, you don't know what to touch without risking the others
Turn on your own signature for each service
  • Ten extra minutes the first time you add each one
  • Each service goes in and out of the DNS without touching the others
  • If something breaks, you know exactly which record to check
  • You can remove just one the day you stop using it, without touching the rest

Which one do I pick: Turn on a separate signature whenever the sender is different. Only two sends can share a signature if they come literally from the same engine, for example two different templates within the same transactional email provider.

Every time you add a new sender
  1. 1Make a list of who sends email on your behalf
    Your regular inbox, your website's contact form, your booking system, your invoicing software. Anything that sends an email with your domain in the sender field counts.
  2. 2Look for "authenticate domain" in that specific service, not another one
    Each service has its own screen where it hands you the records it needs. The ones from your booking system won't work for your invoicing tool.
  3. 3Paste that service's records, not another one's
    They're usually two or three lines with a name that looks like a code. They go into your DNS exactly as that specific service gives them to you.
  4. 4Add it to your SPF, don't replace it
    Add its name inside the single SPF record you already have active. Don't create a new one or delete the one you had.
  5. 5Send a test and read it sender by sender
    A test email to one of your own accounts tells you whether that specific sender passes DKIM and SPF. Check them one at a time, not all at once.
Copying the record to save time
The costliest mistake is taking the DKIM record the first service gave you and pasting it in for the second one too, thinking "the domain's already authenticated." The signature doesn't authenticate the domain overall, it authenticates that specific sender. The second service signs with a key that doesn't match what you pasted, gets flagged as suspicious, and ends up in spam or gets rejected outright. Since the first service keeps working fine, it can take weeks to notice the second one is the one failing.

One SPF, not a list of SPFs

SPF works differently: it's not a signature per message, it's a list of who's allowed to send email with your domain in the sender field. That list lives in a single record on your domain, and there can only be one. If you ever add a second SPF record thinking that's how you add the new service, whoever receives the email sees two conflicting lists and disregards both: the first service, which had been working fine for months, stops passing too.

That's why, every time you add a sender, you don't touch the other services' DKIM signatures, but you do touch that SPF record: you add the new service's name inside the same line, with the word include in front of it.

What an SPF with multiple senders looks like
v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org ~all, that's where your regular email (Google), your booking system (SendGrid), and your invoicing (Mailgun) all coexist, in the same record, one after another.
What you walk away with
  • You have the list of everything that sends email on your behalf: inbox, website, bookings, invoicing
  • Each of those services has its own DKIM signature turned on, without copying anyone else's
  • Your domain has a single SPF record with all of them tucked inside as includes
  • The next time you add a new service, you know to repeat this same step, not reuse someone else's
  • Next in the course: the rule that's better to wait on, not turn on day one
NextDon't switch to reject on day one: watch first, decide later