SPF, DKIM and DMARC: Set Up Email Authentication Without Breaking Mail

Your business uses one domain for everything: a contact form, invoices, password resets and the occasional newsletter. Most messages arrive, but some land in spam. A colleague recommends adding “those three email DNS records”. Which records, and how do you know they work?

The safe answer: identify every system that sends mail for your domain, configure SPF and DKIM with each provider, verify that at least one passing authentication result aligns with the address people see in From, and start DMARC in monitoring mode. Move to a stricter policy only after you understand the reports and the effect on legitimate mail.

SPF, DKIM and DMARC are complementary, not interchangeable. This guide explains the DNS records, the part many tutorials miss (alignment), and how to test a real message. It follows the DMARC standard published in May 2026, RFC 9989 , rather than relying on older examples alone.

SPF vs DKIM vs DMARC: the difference in one table

These checks are defined in SPF's RFC 7208 , DKIM's RFC 6376 and DMARC's RFC 9989 . You can pass SPF and DKIM independently and still fail DMARC if neither passing identity aligns.

Why alignment matters more than three green ticks

An email has more than one sender identity. The familiar From: address is what the recipient sees. The SMTP envelope sender (often exposed as Return-Path) can belong to a mail service instead. A DKIM signature identifies its signing domain through d=.

Imagine a receipt is visibly sent from [email protected]:

• The sending server passes SPF for mailer.example.net, the provider's envelope domain.
• The message passes DKIM for example.com (d=example.com).
• DMARC passes because DKIM passes and its signing domain aligns with the visible From domain. SPF does not need to align in this particular message.

Now change the DKIM signing domain to mailer.example.net, with no other aligned signature. Both SPF and DKIM could still pass their own checks, but DMARC would fail: neither authenticated domain is aligned with example.com.

Under DMARC's default relaxed alignment, subdomains can align when they share the same organisational domain. Under strict alignment, the domains must match exactly. For example, news.example.com and example.com can align in relaxed mode, whereas example.net and example.com do not. The exact organisational-domain discovery rules are more involved; RFC 9989, section 4.4 explains them.

This is also why copying another organisation's SPF record does not solve your setup. What matters is the domains and services in your own sending path.

Step 1: list every service that sends as your domain

Before touching DNS, make a short inventory. Include employee mailboxes, website contact forms, password-reset and account emails, invoices, helpdesk replies, marketing platforms, CRM messages and any legacy servers or forwarding services.

For each service, record which visible From domain it uses, which SMTP envelope domain it sends with, whether it can sign with your domain using DKIM, and where its official DNS instructions live. You may find, for example, that a newsletter system already DKIM-signs correctly while a contact-form plugin sends with an unrelated provider identity.

Do not turn on a blocking DMARC policy before checking all legitimate senders. The 2026 DMARC specification's deployment guidance expressly recommends using aggregate reports to find forgotten sending systems.

Step 2: publish one SPF policy for the relevant envelope domain

SPF uses a DNS TXT record beginning with v=spf1. The policy tells receivers which IP addresses or other SPF-defined mechanisms can authorise the domain used for the SPF check.

For a deliberately fictional example, suppose the only permitted sending host uses the reserved documentation address 192.0.2.10:

example.com.  TXT  "v=spf1 ip4:192.0.2.10 -all"

This is not a working configuration for your company: 192.0.2.10 is an example address, not your mail provider. Use the exact SPF mechanism or include: value supplied by your provider, and account for all authorised senders. An SPF record at your main domain will not automatically fix a provider that authenticates a different SMTP envelope domain.

Two common mistakes deserve special attention:

1. Publishing separate SPF records for separate providers. SPF permits only one selected v=spf1 policy per DNS owner name. More than one causes a permanent evaluation error (permerror). Combine authorised senders in a single valid policy instead.
2. Exceeding the lookup limit. During one evaluation, SPF allows up to 10 DNS-lookup-causing terms, including nested include, a, mx, exists, ptr and redirect evaluations. It is not a simple limit of ten text fragments or ten IP addresses. Exceeding it also produces permerror.

-all declares a hard fail for senders not matched by earlier mechanisms; ~all expresses a soft fail. Choose a policy consistent with the inventory and your provider's instructions. A hard fail is not a substitute for DMARC alignment. These behaviour and limit rules come from RFC 7208, sections 4 and 5 .

Step 3: enable DKIM signing in each email service

DKIM is based on a key pair. The sending service signs selected message headers and the body with its private key; receivers look up a corresponding public key in DNS. The signature identifies a selector (s=) and signing domain (d=).

A selector such as s1 for a signing domain of example.com normally leads to a DNS name like:

s1._domainkey.example.com

What you publish there depends on the provider. Some providers give you a TXT record containing the public key. Microsoft 365's custom-domain setup uses CNAME selector records pointing at its managed DKIM keys. Follow the provider's current values exactly; do not invent a public key or manually guess a CNAME destination. Microsoft's DKIM configuration guide documents this distinction.

After DNS resolves, enable signing in the provider's control panel if that is a separate step. Then send an actual test email and check that its DKIM result is pass with an aligned d= domain. Merely seeing a public key in DNS does not prove outgoing messages are being signed.

Keep the private signing key private. Only the public key (or a provider-specified CNAME) belongs in DNS. For your own signing infrastructure, use appropriately strong supported keys and a rotation process; hosted providers often manage rotation for you.

Step 4: create a DMARC monitoring record

DMARC is another TXT record, published under _dmarc for the relevant domain. A sensible initial policy looks like this:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

Here, v=DMARC1 identifies the protocol; p=none asks for monitoring rather than a particular failure disposition; and rua requests aggregate reports at a mailbox you control and actually monitor. The reporting mailbox must exist (or be handled by an authorised report-processing service). These reports are often compressed XML, not friendly summaries.

The example address uses a reserved domain and is illustrative. Replace it with your real reporting destination. If the mailbox is on a different organisation's domain, DMARC has additional external reporting authorisation rules; do not send reporting data to an arbitrary third-party address. See RFC 9990 .

If your DNS host has a dedicated email-authentication screen, use that or its ordinary DNS record editor. On Cloudflare DNS, for instance, DMARC Management can help review sender reports; enabling a dashboard alone does not replace checking real mail authentication.

Step 5: confirm that the records are visible in public DNS

After saving, query DNS instead of relying only on a green indicator in your domain dashboard. On Linux, macOS or a system with dig installed:

dig +short TXT example.com
dig +short TXT s1._domainkey.example.com
dig +short CNAME s1._domainkey.example.com
dig +short TXT _dmarc.example.com

On Windows PowerShell, you can use:

Resolve-DnsName -Name example.com -Type TXT
Resolve-DnsName -Name s1._domainkey.example.com -Type TXT
Resolve-DnsName -Name s1._domainkey.example.com -Type CNAME
Resolve-DnsName -Name _dmarc.example.com -Type TXT

Replace the sample domain and DKIM selector with your real ones. A DKIM selector may be a TXT record or a CNAME, so an empty result for one type does not necessarily mean a broken setup. Some DNS control panels append the zone name automatically; check that you did not accidentally create s1._domainkey.example.com.example.com.

DNS visibility alone is not end-to-end validation. Caches and receiver behaviour vary, and a valid record cannot prove that a service actually signed or aligned your outgoing messages. Microsoft's Resolve-DnsName reference documents the Windows commands.

Step 6: send a real message and inspect the results

Send one message from each distinct sending system to a separate mailbox that lets you inspect the full original message. In Gmail on desktop, open the message, choose More beside Reply, then Show original. Google's header inspection guide documents the menu.

Look at the authentication summary and the receiving system's Authentication-Results header. Find these values, including the domains attached to them:

spf=pass    smtp.mailfrom=mailer.example.net
dkim=pass   header.d=example.com
dmarc=pass  header.from=example.com

Illustrative result only; not an observed test on Jitsumi or a real domain.

That example passes DMARC through DKIM, even though the SPF-authenticated envelope domain is different. If you see spf=pass, dkim=pass, but dmarc=fail, compare smtp.mailfrom, header.d and header.from. Authentication success is not the same as alignment.

Repeat with a password reset, an invoice or a newsletter when those are sent by different services. Don't treat one successful email as proof that every application is configured.

Step 7: use reports to decide whether to enforce a policy

The three principal DMARC policy values are:

These are domain-owner requests, not a guarantee of what every receiving server will do. DMARC participates in the receiving service's broader mail decision.

A crucial nuance in RFC 9989, section 7.4 : domains used by people who post to Internet mailing lists should not casually adopt `p=reject`. Forwarding and mailing-list modifications can interrupt authentication, even for legitimate messages. The RFC advises such domains considering rejection to monitor p=none for at least a month, then p=quarantine for a comparable period, and review the impact. It also specifies that domains choosing rejection must not rely solely on SPF for a DMARC pass; valid DKIM signing is essential for common forwarding paths.

For a dedicated one-way transactional subdomain, the trade-offs may be different. For a domain used by staff, mailing lists and diverse partners, they can be much more consequential. There is no universal switch-flipping schedule.

A 2026 DMARC change older tutorials may miss

In May 2026, the IETF published RFC 9989 for core DMARC behaviour, with RFC 9990 for aggregate reporting and RFC 9991 for failure reporting. Together they replace the older RFC 7489 material.

One practical change: the old pct= tag used in tutorials to apply enforcement to a percentage of failing messages was removed. The new t= testing signal has different, documented semantics; it is not a replacement that accepts numbers from 0 to 100. Do not copy a “pct=10 rollout” recipe into a new 2026 deployment. Keep the initial record simple, use reports, and plan changes against your actual message flows.

For owners of complex subdomains, RFC 9989 also specifies a DNS tree-walk method for policy discovery. Most small sites can focus on publishing a sound policy at their sending domain and checking any relevant subdomain policy, rather than implementing the discovery algorithm themselves.

Troubleshooting common failures

Does DMARC guarantee that spoofing stops?

No. It helps receivers assess unauthorised use of the actual From domain. It cannot stop lookalike domains, misleading display names, or a criminal who controls a legitimately authenticated account. It is also not a malware filter or inbox-delivery guarantee.

Should I add DMARC if I send very little email?

Yes, a monitored policy can still clarify how your domain is used, even if you have only a handful of transactional messages. Gmail's email sender guidelines require SPF or DKIM for ordinary senders to personal Gmail accounts, and both SPF and DKIM plus DMARC for senders sending more than 5,000 messages a day. A low volume does not remove the value of aligning and checking mail you do send.

The sensible finish line

Email authentication is properly set up when every real sending service is accounted for, its outgoing messages produce passing and aligned results, your DNS policy is valid, and you can recognise and investigate failures in reports. Publishing DNS records is a starting point, not the finish line.

If you only have time for one practical action today, send a message from each provider and inspect header.from, smtp.mailfrom and header.d together. That quick comparison often reveals the mismatch a DNS checklist misses.

Sources and further reading

• RFC 9989 — DMARC core standard (May 2026)
• RFC 9990 — DMARC aggregate reporting (May 2026)
• RFC 9991 — DMARC failure reporting (May 2026)
• RFC 7208 — SPF specification
• RFC 6376 — DKIM signatures
• Gmail email sender guidelines
• Microsoft 365 DKIM configuration

Technical guidance reflects standards and documentation available by 18 October 2026. Provider dashboards and requirements can change; verify the linked current instructions before making changes to a production mail domain.