SPF, DKIM and DMARC for support email, explained in plain English

When a customer’s email provider decides whether your support reply goes to the inbox or to spam, three DNS records do most of the talking: SPF, DKIM and DMARC. They have intimidating names and terse syntax, but each one answers a simple question. This guide explains them without jargon, shows how they fit together, and ends with the setup a support domain needs.

The problem they solve

Email was designed with no way to prove who sent a message. Anyone can put any address in the From line, the same way anyone can write any return address on an envelope. SPF, DKIM and DMARC add that proof after the fact, using records you publish in your domain’s DNS. Receivers look those records up for every message they get.

SPF: the list of approved senders

SPF (Sender Policy Framework) is a list of the servers allowed to send mail for your domain. Think of a building’s guest list at the front desk: if the server delivering the message isn’t on it, the receiver knows something’s off.

It’s a single TXT record at the root of your domain, for example:

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

Each include: adds a service’s servers to the list, and the ending (~all or -all) says what to think of everyone else. Two rules catch people out, both from the standard itself (RFC 7208):

• Only one SPF record per domain. With two, receivers return an error and SPF fails for every message.
• At most 10 DNS lookups. Every include can contain more includes, and the total across all of them can’t pass 10.

SPF has a blind spot: it checks the hidden envelope sender (the Return-Path), not the From address your customer sees. It also tends to fail when mail is forwarded, because the forwarding server isn’t on your list.

DKIM: a tamper-evident seal

DKIM (DomainKeys Identified Mail) works like a wax seal. Your mail provider signs each outgoing message with a private key and adds the signature to the message headers. You publish the matching public key in DNS, at a name like selector._domainkey.yourdomain (RFC 6376). The receiver fetches the key and checks two things: the message really was signed by that domain, and the signed parts weren’t changed in transit.

Because the signature travels inside the message, DKIM usually survives forwarding, where SPF doesn’t. Key size matters: the standard now requires at least 1024-bit RSA keys and recommends 2048 (RFC 8301), and Google recommends 2048 as well.

Each service that sends as your domain needs its own DKIM key, published under its own selector. If your helpdesk sends your replies, it needs to sign them with your domain, not its own.

DMARC: matching the name you see, plus instructions

SPF and DKIM prove things about servers and signatures, but neither checks the From address on the screen. DMARC does. It asks the receiver to confirm that the domain which passed SPF or DKIM matches the From domain. That matching is called alignment. Then it says what to do when nothing aligns, and asks for reports.

It’s one TXT record at _dmarc.yourdomain:

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

• p=none means “monitor only”, p=quarantine means “treat failures as suspicious” (usually the spam folder), and p=reject means “refuse them”.
• rua= is where receivers send aggregate reports: regular summaries of who sent mail claiming to be you, and whether it passed.

The current DMARC standard is RFC 9989, published in May 2026. It replaced the original specification and removed the old pct tag, so if you see pct= in a guide, it’s out of date.

How the three fit together

A message passes DMARC if either SPF or DKIM passes and aligns with the From domain. Having both gives you a backup: when forwarding breaks SPF, an aligned DKIM signature still carries the message through. Then your DMARC policy decides what happens to mail that fails both, which is mostly forgeries.

Why support email in particular

Support replies go to whatever provider your customers use, and the large ones now set rules:

• Gmail requires every sender to use SPF or DKIM. Senders of more than 5,000 messages a day to personal Gmail accounts also need both, plus DMARC and alignment (Gmail sender guidelines).
• Yahoo asks all senders for SPF or DKIM, and bulk senders for both plus a passing DMARC policy of at least p=none (Yahoo Sender Hub).
• Outlook.com requires domains sending more than 5,000 messages a day to pass SPF and DKIM and to publish DMARC, and sends mail that doesn’t comply to Junk (Microsoft).

Your support inbox alone probably sends nowhere near 5,000 messages a day. But volume is counted per domain, and the domain is shared with your receipts, password resets and product emails. There’s also a trust reason. People act on email from support (reset this, pay that), so a support address is worth protecting from impersonation. An enforced DMARC policy is what stops someone else sending as it.

The setup a support domain needs

1. One SPF record that includes every service sending as the domain: your mailbox provider, your helpdesk or support inbox, your billing tool. Keep it under 10 lookups, and end it with ~all or -all.
2. A DKIM key for each of those services, ideally 2048-bit, signing with your domain rather than theirs.
3. A DMARC record starting at p=none with a rua address you’ll actually read.
4. A few weeks of reports. Find every service sending as you, and fix any that fail.
5. Tighten the policy to p=quarantine, then p=reject. RFC 9989 suggests spending at least a month at each stage before moving to reject.

Common mistakes

• Adding a second SPF record for a new tool instead of adding its include to the existing one.
• Turning on a new service and forgetting DNS entirely. Its mail goes out unauthenticated as your domain.
• DKIM published but never switched on in the provider’s settings.
• DMARC left at p=none forever. Monitoring is a phase, not a destination.
• Copying records from an old guide, including removed DMARC tags like pct.

Check your domain in a minute

You don’t need to read raw DNS to know where you stand. These free tools read your records and explain them in plain English, with a corrected record to copy when something’s wrong:

• Support email checker: MX, SPF, DKIM and DMARC at once, with one verdict.
• SPF checker: syntax, duplicates and the 10-lookup limit, counted through every include.
• DKIM checker: finds your key by selector and reports its strength.
• DMARC checker: explains each tag and flags weak or outdated settings.

InboxNest sets up DKIM and a custom Return-Path for every domain you connect, so replies from your support inbox are authenticated as your brand from the start. You still own your domain’s SPF and DMARC records, and the checkers above show whether they’re right.