SPF, DKIM and DMARC: every tag and switch explained

Most SPF, DKIM and DMARC records are copied from somewhere and never read again. That works until a new newsletter tool arrives, SPF hits its lookup limit, or DMARC goes to p=reject and the payslips stop arriving. This guide is the reference we use ourselves: every mechanism, tag and switch of the three standards, what it does, what the default is, and when you would change it. DMARC is covered as updated in May 2026 (RFC 9989, 9990 and 9991), including the new np, psd and t tags.

You can build every record in this guide with the generator below. It runs in your browser, counts SPF lookups, creates DKIM keys locally and explains what each part of your record means.

How the three fit together

An email has two sender addresses. The envelope sender (MAIL FROM, shown afterwards as Return-Path) is used by servers for bounces. The header From is what the recipient sees in Outlook. They are often different: a newsletter service sends with its own envelope address and your From address.

• SPF checks whether the sending server’s IP address is allowed to send for the envelope domain.
• DKIM checks a cryptographic signature in the message, made with the key of the domain in the signature’s d= tag.
• DMARC ties them to what the recipient sees: a message passes DMARC when SPF passes for a domain that aligns with the header From, or when DKIM passes with a d= that aligns with the header From. One of the two is enough.

That last point explains most real-world problems. SPF can pass for bounces.mailservice.example while your DMARC still fails, because that domain has nothing to do with yours. The fix is usually DKIM with your own domain, not a longer SPF record.

SPF

SPF (Sender Policy Framework, RFC 7208) is a TXT record on the envelope domain that lists who may send for it. Receivers evaluate the record from left to right and stop at the first mechanism that matches. The qualifier of that mechanism is the result.

Version

v=spf1 must be the first thing in the record, followed by a space. A domain name can have exactly one SPF record. Two TXT records that both start with v=spf1 give a permerror, and SPF then fails for all mail. The old SPF record type (type 99) is obsolete; use TXT.

Qualifiers

Every mechanism can have a qualifier in front of it. Without one, + applies.

Mechanisms

Modifiers

Receivers ignore modifiers they don’t know, so an SPF record with an unknown name=value is still valid.

Results

The limits that break SPF

• 10 DNS lookups. include, a, mx, ptr, exists and redirect count, including everything nested inside an include. ip4, ip6, all and exp don’t. Over ten gives permerror for all mail. The generator’s “Count all lookups” button resolves the includes and gives you the real number.
• 2 void lookups. A lookup that returns nothing (a removed include, a typo) counts as void; the third one gives permerror. Clean up includes of services you no longer use.
• 255 characters per string. A TXT record can hold several strings of up to 255 characters, which the receiver glues together without a space. Most DNS providers split long values for you; if yours doesn’t, split them yourself and keep the spaces inside the strings.

Macros

Macros let exists, include and redirect build a name from the message being checked. You will rarely write them yourself, but you may see them in a provider’s record.

SPF in Microsoft 365

For a domain that only sends through Exchange Online the record is v=spf1 include:spf.protection.outlook.com -all. You don’t need mx or a: your MX points to Microsoft, which the include already covers. For domains that never send mail, publish v=spf1 -all. Exchange Online itself evaluates inbound SPF as part of composite authentication (compauth in the Authentication-Results header); you can read those results with our header analyzer.

DKIM

DKIM (DomainKeys Identified Mail, RFC 6376) adds a DKIM-Signature header to every outgoing message. The receiver fetches the public key from DNS and checks that the signed headers and the body were not changed. Because the signature travels inside the message, DKIM usually survives forwarding, which SPF does not.

The key record

The public key lives at <selector>._domainkey.<domain>. The selector is a name you choose, so one domain can have several keys: one per service, and a new one for each rotation.

Key length: use 2048-bit RSA. 1024-bit keys are considered too weak for new use, and signatures made with keys shorter than 1024 bits are not accepted as valid (RFC 8301). A 2048-bit key is about 400 characters, so it spans two TXT strings. 4096-bit keys work in theory, but many DNS hosts and some receivers struggle with records that long.

The signature header

You don’t write the signature yourself, but reading it tells you who signed and why DKIM or DMARC failed. The header analyzer shows these fields for any message you paste.

DKIM in Microsoft 365

Microsoft signs every message with your onmicrosoft.com domain by default. That signature is valid, but it does not align with your own domain, so it doesn’t help DMARC. Enable DKIM per custom domain:

Connect-ExchangeOnline
New-DkimSigningConfig -DomainName contoso.nl -KeySize 2048 -Enabled $false
Get-DkimSigningConfig -Identity contoso.nl | Format-List Selector1CNAME, Selector2CNAME

Publish two CNAME records, selector1._domainkey and selector2._domainkey, pointing to the values shown. Since 2025 new targets end in dkim.mail.microsoft, with a part that differs per tenant, so always copy them rather than typing them from an example. Microsoft keeps the private keys; the second selector is for the next rotation. Then switch signing on and, later, rotate:

Set-DkimSigningConfig -Identity contoso.nl -Enabled $true
Rotate-DkimSigningConfig -Identity contoso.nl -KeySize 2048

Every other service that sends with your domain (newsletter, CRM, ticketing, invoicing) needs its own DKIM with d= your domain, usually through CNAME records the service gives you. For a mail server you run yourself, the generator can create the key pair in your browser.

DMARC

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a TXT record at _dmarc.<domain>. It tells receivers what to do with mail that fails alignment, and where to send reports. In May 2026 RFC 7489 was replaced by RFC 9989 (the protocol), RFC 9990 (aggregate reports) and RFC 9991 (failure reports). The version stays DMARC1 and existing records keep working.

Alignment

DMARC passes when at least one of these is true:

• SPF passes, and the envelope domain aligns with the header From domain;
• DKIM passes, and the signature’s d= aligns with the header From domain.

Relaxed alignment (the default) accepts any domain under the same organisational domain: news.contoso.nl aligns with contoso.nl. Strict alignment requires the exact same domain. RFC 9989 finds the organisational domain with a short walk up the DNS tree, looking for DMARC records, instead of the Public Suffix List that RFC 7489 relied on.

All DMARC tags

Reports to another domain

If rua or ruf points to an address on a different domain, for example a report service, that domain has to confirm it accepts reports for you. It does so with a TXT record contoso.nl._report._dmarc.reportservice.example containing v=DMARC1. Without it, receivers drop the reports. Report services publish this for their customers; the generator shows the record when you enter an external address.

Aggregate reports arrive as compressed XML files, dozens a day for a normal organisation. Nobody reads them by hand. In our experience DMARC Advisor is the best tool to receive and read them: it groups the reports per sending source, alerts you to new or failing sources and guides you step by step to p=reject.

Moving from none to reject

1. p=none with rua, and np=reject straight away. Read the reports for two to four weeks.
2. Fix every legitimate source that fails: DKIM with your domain first, SPF second.
3. p=quarantine, optionally with t=y for a week while you watch the reports.
4. p=reject, again optionally with t=y first. Then remove t=y.
5. Keep reading the reports. New tools that send as you appear every year.

DMARC in Microsoft 365

For outbound mail, Microsoft 365 needs DKIM on your custom domain; SPF alone rarely aligns for everything. Microsoft does not host your DMARC record: you publish it in your own DNS, also for the domains that never send mail. For inbound mail, Exchange Online Protection checks the sender’s DMARC. What happens to failing messages is set in the anti-phishing policy under Honor DMARC record policy when the message is detected as spoof, with separate actions for senders at p=quarantine and p=reject. Messages that fail show dmarc=fail and a compauth reason in their headers.

The other records around them

SPF, DKIM and DMARC protect your domain against spoofing. Three smaller standards complete the picture, and the generator builds them too.

Inbound protection of the connection itself comes from DNSSEC and DANE. For Exchange Online that means signing your zone and moving your MX to the DNSSEC-signed *.mx.microsoft endpoint; the legacy mail.protection.outlook.com endpoint has no DANE. If you run MTA-STS as well, list both endpoints while you move.

Checklist

• One SPF record per sending domain, under ten lookups, ending in -all (or ~all during the transition).
• No includes for services that don’t send with that exact envelope domain.
• DKIM with 2048-bit keys for Microsoft 365 and every other sender, with d= your domain.
• DMARC with rua, np=reject, and a plan from none to reject.
• Non-sending domains: v=spf1 -all, DMARC p=reject, and a null MX (0 .).
• TLS-RPT, then MTA-STS; DNSSEC and DANE when your DNS host supports DNSSEC.
• Check the result with our email security check.