You added a support tool because answering customers from Gmail was getting messy.

It asked for a sender address, so you typed support@example.com. The test message reached your own inbox. Done.

Then a customer writes that your reply never came. Another found it in spam. A third is disputing a payment because they think you ignored them.

Your wording is fine. The tool is sending mail that claims to be from your domain, and your DNS (the public settings file for your domain) may say nothing about that tool being allowed to.

What inboxes check

When a service sends mail as your domain, the receiving inbox runs three checks:

  • SPF: is the sending server on your domain’s list of allowed senders?
  • DKIM: does the message carry a digital signature that matches a public key in your DNS?
  • DMARC: your published instruction for what receivers should do with mail that fails. Receivers make the final call, but a failing message is far more likely to land in spam.

The rule that matters is easy to miss. DMARC does not need SPF and DKIM both to pass. It needs one of them to pass and to match your From domain (RFC 9989, section 5.3.5). “Match” is called alignment. We explain it in SPF passes, DMARC fails: the alignment trap.

Support tools trip over this. Many send with their own return address behind the scenes (the “bounce domain”, where failed deliveries go back to), so SPF can pass for the provider’s domain, not yours. That pass does not count toward your DMARC. A DKIM signature for your own domain does count, which makes it the dependable path.

A green “connected” badge in the support tool’s dashboard does not prove any of this.

Step 1: List every tool that sends as you

Write down every place a customer can get mail from you:

  • signup confirmation and password reset
  • invoices, receipts, failed-payment notices
  • support replies and chatbot follow-ups
  • newsletter or product updates
  • booking confirmations and feedback surveys

If an AI assistant built your app and you do not know where email is configured, search the project for words like these:

EMAIL
SMTP
FROM_EMAIL
SUPPORT_EMAIL
RESEND
POSTMARK
SENDGRID
SES

Check automation tools too. A workflow you built two months ago may still send from your domain.

Step 2: Write down the From address for each

App password reset: no-reply@example.com
Billing receipts:   billing@example.com
Support replies:    support@example.com
Newsletter:         hello@example.com

Every tool that sends from @example.com needs DNS records. A tool that sends from its own address, such as reply@provider.example.net, does not touch your domain’s authentication. Leave it alone until you are ready to add the records.

Step 3: Edit your SPF record, never add a second one

SPF is one TXT record on your domain. A TXT record is a line of text stored in your DNS; in many DNS panels its name is @, which means your domain itself. It looks like this:

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

include:_spf.google.com is the real value for Google Workspace. Your other senders each have their own include: value.

Your support tool will tell you to “add SPF”. Do not create another TXT record that starts with v=spf1. Two SPF records make SPF return a permanent error, and then SPF fails for all your mail, not only the new tool (RFC 7208, section 4.5).

Add the new piece to the existing record instead:

v=spf1 include:_spf.google.com include:<value-your-provider-gives-you> ~all

Copy the exact value from your support tool’s setup screen. Take a screenshot of the old record first, so you can paste it back.

Each include: also counts toward SPF’s limit of 10 lookups (separate DNS queries a receiver makes while checking the list). Past that, SPF breaks too. Adding one SaaS tool broke your SPF record shows how to count and what to do.

Step 4: Add the tool’s DKIM records

The setup screen gives you one or more DNS records. Each is a TXT record (a line of text) or a CNAME record (an alias that points to the provider). Their names usually contain _domainkey.

Copy them exactly. Do not rename them. Do not delete older DKIM records unless you are sure that sender is gone. Old records sitting in DNS do no harm. A deleted record that a live sender still uses breaks receipts or password emails that worked yesterday.

For the basics, see SPF + DKIM + DMARC: the bootstrap for startups.

Step 5: Do not tighten DMARC while you connect the tool

A starter DMARC record asks for reports and blocks nothing:

v=DMARC1; p=none; rua=mailto:<your-report-address>

rua= is the address where receivers send their daily summary reports.

Your domain gets one DMARC record. If you already have one, edit it. A second record makes receivers ignore both. If you already use p=quarantine (send failures to spam) or p=reject (refuse them), leave it as it is, connect the tool’s SPF and DKIM first, then test real messages.

Step 6: Test a real reply, not “hello world”

  1. Open a ticket in the support tool from a test customer address.
  2. Reply from the tool to a Gmail address you control.
  3. In Gmail, open the reply, click the three dots, and choose Show original.
  4. Find the line DMARC: PASS.

That line is the one that counts. Next to it, check the DKIM line. You want PASS with domain example.com, your domain. If DMARC shows FAIL, the tool is not yet authenticated as you, and replies are at risk. Repeat the test for password resets and receipts, because each one can go through a different sender.

See who actually sends as you

After DMARC reports start arriving, the domain’s Senders tab in DMARC Guardian lists each sending service from the last 30 days with its status, volume, and pass rate, and by default shows only the ones that need your attention. A new support tool that fails shows up there as its own row. The report address for your rua= is shown in the app.

Checklist

  • List every tool that sends from @example.com
  • Write down the From address for each
  • Add the new include: to your one SPF record
  • Add the tool’s DKIM records exactly as shown
  • Keep old DKIM records
  • Send a real reply to Gmail and confirm DMARC: PASS
  • Check the DKIM line shows your own domain

Check your domain’s SPF, DKIM, and DMARC records before the next reply goes to spam →